[Tagging] Super-keys are evil

Kurt Blunt k.blunt at inbox.com
Mon Feb 23 01:43:20 UTC 2015


In a previous thread on this mailing list, someone proposed amenity=reception_desk. Someone else observed that the amenity key is where you put a new tag when you don't know where else to put it. I think this is a symptom of a bigger problem with tags on OSM.

Right now, tags serve two distinct purposes. There are attribute tags like name=Wall Street, and there are category tags like amenity=parking or aeroway=helipad. Categories are represented as values of a few "super-keys": highway, amenity, building, aerialway, aeroway, and a few others. When you create a new category, you're expected to shove it under the most appropriate super-key. This is not easy. I sympathize with contributors who propose new tags.

When you want to tag the same point with multiple categories, those categories must share the same tag and be separated by a semicolon e.g. shop=convenience;alcohol. That is, unless the two categories are under two different super-keys, in which case the object will have a separate tag for each category. This is inconsistent.

But nevermind the inconsistency. More importantly, this key-value tag hierarchy makes it unnecessarily difficult for contributors to remember tags. More specifically, it's difficult to remember under which super-key the category is located. Is it building=shrine or amenity=shrine? Is it barrier=city_wall or historic=city_wall? What about city_gate?

Many tags don't even make sense. What does highway=track mean? Is it a highway that acts as a track? A track is clearly not a type of highway. A track is just a track. A contributor is left to feel like an idiot for not understanding the logic behind this system.

For these reasons, I believe there is a case to be made for an overhaul of category tags. My personal opinion is that we should get rid of super-keys altogether and instead promote all categories to keys with empty values:
"amenity"="reception_desk" becomes "reception_desk"="",
"highway"="track" becomes "track"="",
"aerialway"="gondola" becomes "gondola"="",
"barrier"="city_wall" becomes "city_wall"="",
"historic"="city_gate" becomes "city_gate"="",
"sport"="volleyball" becomes "volleyball"="",
etc.

Attribute tags would remain as they are now.

This solution would make all the problems I mentioned above go away. Also, it would be pretty easy for current contributors to learn the new tags since we're essentially just removing super-keys, not adding anything.

Now, I don't actually think such an overhaul is currently feasible given the massive burden it would put on the database system. However, it might be something to think about for the future.

____________________________________________________________
TRY FREE IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if5
Capture screenshots, upload images, edit and send them to your friends
through IMs, post on Twitter®, Facebook®, MySpace™, LinkedIn® – FAST!





More information about the Tagging mailing list