[Openstreetmap] Re: Naming segments using applet

Kendall Sears krsears at starband.net
Fri Dec 16 18:15:45 GMT 2005

> > The current schema is highly road/street paradigm dependant.
> Great, because we're building street maps!
> Sure, we're occasionally guilty of not-made-here syndrome, but equally
> we're not precious about what already exists - if it's not working out,
> and someone proposes a better solution, it will get junked (see our first
> attempts at XML formats, the original over-architected key/value system,
> the applet rewrite, etc.) - nobody here is afraid to rewrite things if
> necessary.

Already, there are instances with streetmaps where I can see problems.
For instance, in the US and Canada (I am not sure about across the pond)
there are many roadways that "change" monikers or function as part of 2
or more routes.  These may diverge into multiple separate paths,
converge from others, or even "jump" to another road.  There is no
facility for this in the current db.  Also, interstate highway systems
don't seem to be a strong point either as their associated
entryways/exits, viaways, overpasses, and the like aren't symbolized.

I've not faulted the willingness of the community to change.  To the
contrary, the only reason I'm involving myself at this point is BECAUSE
of this virtue.

> >
> > Before people start digitizing features other than roads/streets it
> > would be advisable to move to a true GIS schema.  Either enable the GIS
> > extensions to MySQL or switch to PostGIS before too much occurs or there
> > will be a real mess.  "Tags" alone just won't cut it, please believe me.
> > There are too many associated attributes for multi-feature GIS data to
> > handle in this fashion.
> >
> BUT...
> You aren't the first person to offer advice and plead for a move to a
> "true GIS schema".  Thing is, most of us don't have an idea of what that
> would look like, but OSM's code works *now* and does lots of things we're
> interested in.  There are clear incremental paths of progression for OSM
> to do lots more things we're interested in, and the biggest limit on us is
> coding time, not bandwidth, resources, money, or what the database can
> express.

I realize that I'm not the first.  I've been lurking around the OSM for
quite a while.  I've read all of the entries in the Mailing Lists.  I've
even sent a few probing email messages that never got through earlier
this year.  I didn't participate until recently because the OSM seemed
to be Eurocentric in it's concerns and I was watching another project
that was based off of the US Census Bureau's TIGER data and "fixing" the
accuracy using GPS data.

I would recommend moving to the OGC (Open GIS Consortium) schemas as
these are usable by many GIS packages already.  Not to insult the great
work that's been done, but can one really say that it _works_ now?  It
is usable for sure.  But there's no way that I'm going to put the
several million points contained in my datasets into the OSM set with
the current facilities; it just takes too much effort and time.  And the
entry accuracy is just not available, I'm collecting sub-meter accurate
differentially corrected GPS points only to have the entry applet make
me manually click to create a node that is way outside of the collected
accuracy range.  If I could use my current tool set then your collection
would be flush with lots of data from North America containing much more
information than just the location of the pavement.

Since you say time is the issue, consider this:  using either MySQL's
GIS set or PostGIS (both OGC compatible) one can import data directly
from shapefiles, CSV, and many other formats.  Let's also not forget
using JDBC from GIS packages.  From there the data can be served from
any of about a dozen WMS/WFS servers available as open-source.  These
are tested and (for the most part) production quality _now_.  How's that
for time savings :-)

> > I've been a professional GIS technology consultant for over 8 years and
> > have run into MANY instances exactly like this.  The resulting work to
> > fix the problems was more than a little outrageous.
> >
> Can you point us in the direction of some of the MANY instances you're
> thinking of?  And what were the lessons learned?  "Use PostGIS" isn't a
> lesson.

:-)  Considering that the majority of my clients use ESRI or Oracle
Payware that isn't one of the lessons.

Let me get something clear.  I don't really have a "dog in this fight"
as I'm really just looking to help out where I can.  I really like the
idea of open data availability, which in the US and Canada really isn't
a problem.  NA has a few "somewhat" (within 20M) accurate public-domain
vector sets available for anyone to grab.  However, an accurate world
wide surface level data set has an appeal.

With that being said:  As long as a data set contains only a single type
of feature the format/schema really doesn't matter.  Look at the
"standard" ESRI shapefile as an example.  However, once one starts
varying the types of data it rarely stops.  First it's railroads, then
bicycle paths, then rivers, then canals, then streams.  Then someone
says, "we need to have depth measurements on the rivers/canals to keep
boats from shoring".  All of a sudden what seemed to be just a simple
"line-feature" data set becomes a true spatial set.  Take a look at the
"bus-stop" discussion here recently.

What invariably occurs is that "extensions" keep being made to the
"simple" database.  Call them "tags" or "labels" or whatever, it's still
the same old mess.  Eventually the data are too unwieldy to be handled
in a "simple" data set and too inconsistent to easily be converted to a
"standards" data set.  This almost always leads to extraction of a small
subset of the data and re-entry of the rest, if funds are available, or
abandonment of the data if not.

The lesson learned is to over-engineer your schema; if it is easily
done, and to rely on the work of others; if available.  A schema is
available from the OGC and is manifest in either MySQL or PostGIS on the
free side.  Once you've got that you can capitalize upon the many OGC
compatible GIS packages available anywhere for data entry and
maintenance, either Open-Source or commercial.  You might even want to
look as the UMN Mapserver project for WMS serving, or the GeoTools
project for their server.  Once one can remove the software
development/maintenance headaches one can focus on the truly important
part:  the data.

> Are you sure they were making wiki-style street maps?  We're not trying to
> map the universe at 1:1 scale here, just map a few streets.  If canals and
> stuff drop out of that for nearly-free, then all the better for waterway
> enthusiasts, but I disagree that accomodating a few other 'street-like'
> representations puts us on a slippery slope where the only solution is an
> 'industry standard' GIS database.  I think you misunderstand the scope and
> focus of the project if you think the database situation is that bad.

There's nothing special about 'wiki'-ing with GIS data.  The maps are
visualized at the client end.  The database controls the changes.  Been
doing that for a very long time.

As far as misunderstanding the scope:  I've watched these type of
projects evolve since the early 1980's.  The scope _always_ starts
small.  So far, from reading ALL of the archives, this project has
followed the same old script EXACTLY to the letter.  This is what
prompted me to comment.  So far, the only thing that has surprised me
about this particular project is the reticence to accept data and
assistance by the members of the community.

> Best,
> Tom.

Thanks for your time.

Kendall Sears <krsears at starband.net>

More information about the talk mailing list