[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"="",

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