On 30/07/2010 17:14, Ian Dees wrote:
The OSM ecosystem has always strongly favored ease of mapping (as
opposed to ease of data consumption), but now that more data consumers
are attempting to use our data maybe it's time to start thinking about
how we can firm things up a little bit to give the data consumers
something solid to work with.
http://www.frankieandshadow.com/sotm10/tagcentral.pdf
As well as telling people and programs about new tagging, this can also
tell people that one tagging is sufficiently similar to another you
could use the same tag for it, and similarly that it deprecates or is
deprecated by some other tag. A schema aware application would, in
principle, need no change were a tagging change like this to be made.
Not that I think that's a good reason to do it.
The main reason that has been cited for this change is that you can fall
back on a generic icon when the more specific one is not found. Things
can fall in lots of partitions of data though, this just focuses on one
(and one over which there is little agreement here apparently, not that
there ever is agreement on anything here).
Also, using tag => icon or even a simple rule based method is a very
blinkered way of seeing even rendering, and renderers aren't the only
consumers by any means. It assumes you always want a renderer which
always wants to draw every item in every class that you have an icon
for. Real world mapping isn't like that (which was the subject of my
other SOTM talk,
http://www.frankieandshadow.com/sotm10/real-map-real-paper-real-people-real-money.pdf
)
The main reason not to make this change is that currently it forces
every bit of producer and consumer software everywhere to change. And as
someone else said, even the smallest change leads to expensive
consequences in
And you have to be aware of the change. At the moment a lot of our
software is introspective, stuff that the community makes and supports.
But as it spreads, less and less will be like this, and making
gratuitous changes to support a minor convenience of one rendering
method just isn't sustainable.
If you are worried about simplifying renderering, there's hugely more
complex problems that changing or enhancing the data model would give
vastly more benefit from: understanding how parts of a dual carriageway
link together for example, of knowing what constitutes a street in a
less heuristic fashion than just contiguous similar names; knowing what
makes a bridge (as a parallel discussion was talking about) and so on.
Someone facetiously said "why not make everything thing=whatever?". Had
I designed it that's how I'd have done it: properties of items would
have a type (e.g. hospital) and then attributes with valuies to further
qualify, i.e. tags. It's also how relation tagging works (within the
constraints of tags having to have a LHS): relations have type=... and
then further qualifying tags.
If we'd done it that way, then among other benefits we'd have less of
this endless quibbling about the vocabulary of what are, essentially,
internal identifiers.
David
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
