[Tagging] Super-keys are evil

Pieren pieren3 at gmail.com
Tue Feb 24 14:55:35 UTC 2015

On Mon, Feb 23, 2015 at 2:43 AM, Kurt Blunt <k.blunt at inbox.com> wrote:

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

We have other options than the semicolon e.g. "shop=convenience" +
"alcohol=yes". We have noticed that excepted some rare exceptions
(like multi-refs or opening hours), semicolons should be avoided in
OSM because data consumers don't like them.

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

Editors are supposed to provide some help tools like the presets where
you type "city wall" and the editor finds the correct tag for you.
Otherwise you can open the infamous wiki "Map features" page and use
your browser "search" function.

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

English is not my native language but I learned with OSM that
"highway" has a modern meaning for main (inter-cities) roads but also
an older meaning for any public road
(http://dictionary.reference.com/browse/highway?s=t). I hope you feel
less like an idiot now...

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

A key with an empty value doesn't save much. And it can be worse and
lead to misunderstandings. When you write "track=""", is it for cars
or for trains ? Then you need a subkey again... I know one example
following your idea: the "bus=yes" which can be used with
"public_transport" or "access" keys but with different meanings (and
no possibility to combine on the same element).
In addition, you create much more work for the data consumers. The
first example is the renderer who can render all buildings or all
barriers in the same style, using a single rendering rule for all
types of buildings or barriers which wouldn't be possible with your
I'm not saying the current system is perfect, we made mistakes (like
the "tourism" category imho) but it's a compromise. And things can be
changed (see "highway=ford" or "aed") although it's not easy and
really needs good and valid reasons.

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

I think that after 10+ years of discussions, you are not the first who
came with this idea.


More information about the Tagging mailing list