[Tagging] [OSM-talk] emergency=*

David Earl david at frankieandshadow.com
Fri Jul 30 17:46:17 BST 2010


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



More information about the Tagging mailing list