[Openstreetmap] Re: Naming segments using applet

Tom Carden tom at tom-carden.co.uk
Sat Dec 17 15:12:30 GMT 2005


Kendall,

First let me say thanks for expanding on a lot of your points, it's much 
appreciated. 

I probably don't need to  point this out but I should say that I really 
don't speak for the whole of OpenStreetMap - I try to represent 
consensus where I see it, but the following opinions are all my own.  
Deep breath...

Kendall Sears wrote:
> 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.  

I personally have issues with how the current 'tags' implementation is 
actually just a badly-validated arbitrary key/value system, but I think 
it can express the situation you describe above.  There's nothing to 
stop a particular street segment being designated as part of several 
different routes using tags.  If I'm mistaken, this needs picking up 
right now, so please correct me if I'm wrong.

> 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.
>   

Just a matter of time, and again something I imagine will be expressed 
with tags on nodes and line segments.  We're imagining that client 
implementations will settle on a way to represent certain types. Nick 
has already led the way with the importing of his freemap data (points 
of interest and footpaths, etc), and the applet and tile drawing code 
have some catching up to do to deal with displaying those tags 
correctly.  I imagine that when we import TIGER we will settle on a lot 
of tag names very quickly, and then again update the viewer and editor 
to match.  At that point we will have a core list of suggested tags and 
ways to designate certain types of features,  which client developers 
will implement if they want their changes to be compatible with 
openstreetmap.org's maps but they will be free to implement things 
differently if they want.

> 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.
>   

Cool, understood.

>> 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.  

To the list, or individuals?  If there's a problem with the list then 
that needs fixing.

> 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.
>   

Is that project open, and do you think we should be working together?

> 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.  

The bits I care about work.  There is an end-to-end solution for 
uploading GPS data, tracing it over aerial photography, annotating the 
street names and viewing it on the web.  There are lots of things which 
are barely adequate, but it all works.  It goes! For some value of 
works. Yes.

> 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.

It is planned that node creation will snap to the nearest GPS track 
point if one is available, and there are plans to allow importing of 
waypoints etc directly, with areas and points of interest to follow.  
What format is your data in, and what kind of data is it?  Perhaps we 
could write a script to import it into the database directly, and 
maintain the accuracy?

With the assistance of GPS and aerial photography, the bar is currently 
really low for making vector street maps and distributing them under 
Free licenses.  That's all that OpenStreetMap is aiming for, at least 
for the moment.  One reason OpenStreetMap exists is that we don't *need* 
sub-meter accuracy to be useful.

>   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.
>   

Cool.  What do you need?

> 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 :-)
>   

But they don't support the versioning and wiki-style rollback features 
we cherish, do they?

>> 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.
>   

I really hope you can find somewhere to help.  With respect, it sounds 
like your "dog in this fight" is accuracy, and a database that supports 
the formats of your existing data (preferably using OGC schema).  Those 
aren't unreasonable goals, but they're not ones I care for - you 
certainly shouldn't take my opinion as representative of the OSM 
community as a whole though.  I'm just quite active on this list... I 
don't do lurking :)

> 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.  

Understood, really.  My own focus is streets and will be for the 
foreseeable future.  Others have their itches to scratch, and if someone 
writes code that uses the OpenStreetMap database to map waterways or 
footpaths or whatever, then so long as they tag the data in a way that 
means I can ignore it when drawing streets, then I don't care.

> Take a look at the
> "bus-stop" discussion here recently.
>   

People are somewhat blinkered in their eagerness to use the tools we 
already have - bus stops are, I think, trivial to implement as points of 
interest.  We just haven't done it yet.

> 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.
>   

Wise words of warning, but I don't really agree.  We're seeing examples 
all over the web where allowing thousands of people the ability to tag 
and manipulate things in free-form ways creates a data set which is 
'good enough'.  I believe that every extra thing which is added to 
OpenStreetMap will increase the complexity, and that as the complexity 
increases we will lose contributors.  OpenStreetMap doesn't need to 
cater to GIS professionals (though of course it needs to heed their 
advice!), it needs to cater to ordinary folks, like the millions of 
people getting satnav devices for Christmas this year who might want to 
help make simple maps of their local area, for its own sake.  (That's a 
total pipe dream, I'm sure, but it's worth pointing out).

> 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.  

Personally, every time I look at the OGC web documentation, god kills a 
kitten.

http://www.opengeospatial.org/ is an impenetrable mess of jargon and 
standards wanking of the highest order.  If you have the patience to 
wade through that and find the bits that are pertinent to OpenStreetMap 
then please do, and please point out the bits we should be aware of.

I really don't understand what the OGC standards and tools have to 
offer, but more importantly I don't see the need to understand them 
either.  They definitely don't speak to me or my issues, and they don't 
speak a language I understand.  I understand OpenStreetMap though. When 
Steve first introduced me to the OpenStreetMap project, the aims and 
scope were so modest it was quick to write tools which used what was 
already there, and as a bonafide cartographic lay-person I could 
immediately understand what he was getting at - I didn't need to read a 
318 page XML specification to get started.
(definitely worth pointing out this is my opinion and not the OSM 
community's consensus view, if there is one)

> Once one can remove the software
> development/maintenance headaches one can focus on the truly important
> part:  the data.
>
>   

Amen to that. 

Except that software development and maintenance is fun!  And I wouldn't 
like to replace it with the installation and maintenance of software 
packages which I perceive to be bloated and over-engineered and where 
90% of what they do is superfluous to OSM's needs.

>> 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.
>   

With hundreds/thousands of essentially anonymous contributors?  I'd be 
really interested in your experience with that.  In particular how did 
the systems you're familiar with deal with the problems we anticipate 
OSM will face imminently (vandalism, editing conflicts, 
authority/reliability of data, etc)?

> 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.  

Heavens, if we're so predictable can you tell us how it all ends and 
save us the bother?

(And, really, how did people run "these type of projects" in the 80's?  
Excuse me if I'm an irritating combination of arrogant, ignorant and 
naive today but I find myself unable to see through your "I'm sorry, but 
I must intervene, this is madness, madness I tell you" attitude and find 
any real insight).

> 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.
>   

If I understand what you mean about data, then you're right.  We have 
lots of offers of data, and as far as I know we haven't taken any of 
it.  I think we need an entry in the FAQ that explains the position.

Q.  I have N megabytes/sq km/CDs of high resolution geo-referenced 
aerial photography/satellite images of {some place}, how can I get these 
to you and can they be added to the dataset?
A.  Yes, please, if they are free of copyright restrictions for 
derivations, or you are the copyright holder and can grant us the 
relevant rights, we'd love to use your photographs.  Unfortunately we 
don't have a clean and simple way to add extra imagery yet, but once we 
do we'll be in touch.

The situation is the same for shape files.

As for offers of assistance, I can't think of any offers that the 
community has been reticent about accepting.  Most offers of coding 
assistance are met with a subversion account, and some of these have 
proved fruitful. We get occasional offers for hosting, but whilst our 
current hosting arrangement holds (we know it's flaky, but it's being 
dealt with) I don't personally think it makes sense to switch it around 
too much.  There are occasional fund-raising ideas (paypal tip jar and 
so on) but I think that Steve is reluctant to run the project this way 
because it leads to people (reasonably) expecting a certain amount of 
service in return.  I can't speak for Steve though.

Best,

Tom.






More information about the talk mailing list