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

[Matt Amos]

On Tue, Jun 16, 2009 at 7:10 PM, Tels<nospam-abuse at bloodgate.com> wrote:
> 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.

yep... mappers and their tagging ideas are OSM's biggest problem. or
it's biggest advantage, depending on your point-of-view.

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

welcome to the "map features is definitive" vs "map features should be
descriptive" debate.

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

contact the user, correct it - it's a wiki and we keep the version
history. even if you destroy something, someone can revert it.

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

as you say below; without easy data entry there is no data. we can all
agree that data entry isn't exactly intuitive at the moment, but it is
getting better. more tools and better editors will be developed.

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

following the opposite train of thought to the end, we create a
"read-only" OSM editor, so mappers find it difficult to enter data but
extraction of the data is very easy. that wouldn't be any good either,
so we clearly need some sort of balance.

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

absolutely, OSM is an organic, evolving project - the tagging scheme
was specifically designed to support emergent ontologies
("folksonomies"). mappers tag the way which advantages them the most.
for example, using relations for cycle routes because then it renders
on the cyclemap. there are no standards because the standards emerge
between the suppliers and consumers of the data.

cheers,

matt