[OSM-dev] A consistent format for the multipolygon relation

Tels nospam-abuse at bloodgate.com
Tue Jun 16 19:10:37 BST 2009


On Tue 16/06/09 10:45 , Andreas Kalsch andreaskalsch at gmx.de sent:
> I don't like this way of discussion. It leads to nowhere ...

While you are right about the tone that seems to have developed, I think it is
actually a very useful and important discussion.

Sorry for intruding here, I wanted to reply to Wolfgang directly, but thanx to
the crappy webmail interface I can't find his email so I am replying to this
email instead :)

> The point I wanted to demonstrate was to start an initiative to get 
> multipolygons into the right format because the quality of OSM data is 
> crucial for all projects which use it. To get a more consistent 
> definition of multipolygons is an important step to make it easier for 
> everyone (including the map renderers) to build on top of the data. I 
> don't want any silver plates, too, but bite-sized data.
> 
> Pretty easy, huh?

That is a very noble goal, and I fully support it. Unfortunately, it seems that
OSm is heading into the opposite direction :(

Instead of getting more consistent and easy-to-interpret-and-use data, all we get
is more and more garbage, duplicated information (attribution="blah" on every
node!), badly designed data structures (multipolygons, I look at you!) and
inconsistencies (fuzzy logic like "true, false, 0, 1, -1, maybe, yes, not today")
and so on with every passing week.

I might be biased because I am a "user" of the OSM data (see
http://bloodgate.com/wiki/map) and I am not happy about the current state of
affairs when I see what is all in the DB. However, I am *also* a mapper and I am
not happy about the current editing/tagging helps, either. 

You never really know how to tag something right (the map features wiki pages is
highly incomplete and sometimes outright conflicts with the real world usage), it
always takes time to find out sometimes even simple things, and everytime I map,
I just cry when I see the mistakes of others, then wondering, should I correct
them? Or better not? What if I accidentily destroy something?

"Making it easy for mappers" is certainly not a reality on OSM, unless you are
already an experienced mapper. People who are new to OSM struggle even more. 

Also, letting the mappers design the data structures only leads to the situation
where "data entry" is easy, but "data extraction" is hard. Since "data entry"
happens only once, and "data extraction" multiple times, this is exact the
opposite on what you would design around!

If we follow this train of thought to the end, we better create a "write-only"
OSM editor, so mappers have it absolutely easy, and no-one needs to worry about
making something out  of the data later :) Sure, without mappers there is no
data, but without any applications using that data there are no users, and
without users, the entire project becomes a moot point, anyway.

Anyway, in closing I think that the OSM data representation and structures as
well as their documentation leave a lot to be desired and improving them would be
benefit us all, mappers, coders and most importantly, users (as in "using the map
to find places") alike.

And now I am back to programming :)

Tels




More information about the dev mailing list