From OpenStreetMap Wiki
Jump to: navigation, search

The Problem

The current tagging methods produce data which does not contain very obvious contextual information since the object type and object attributes are mixed together. For example, consider the following two ways:

  • natural=cliff, rock=limestone, height=25
  • climbing=route, rock=limestone, height=25

Are both these objects of the same type (rock=limestone), or is one describing a cliff and one describing a climbing route? Without prior knowledge of the tags used, it is impossible to tell which tags are describing the object type, and which are merely describing attributes of the object.

Additionally, a tag does not necessarily have a single globally defined meaning, which means you must know the context in order to understand it. This is especially important when doing things like looking up the meaning of tags in the wiki.

It causes even bigger problem for database queries, such as using Overpass API, because in some cases, the only way to query objects with desired properties is to include very complex context definition in query, such as geometry conditions (say, "nodes only") and key list conditions. It affects the performance of query pretty much.

Possible Solutions


One option is to prefix tags with some context information (so called "namespacing"). For example, you could have:

  • climbing=crag, climbing:crag:name=Great Tor
  • climbing=route, climbing:rock=limestone, climbing:height=25
  • piste=lift, piste:lift:occupancy=5

This means that each tag will have a single defined meaning rather than being dependent on the context in which it is used.


  • The tag name contains all the context data you need, making searching for a specific tag easier.
  • Software for viewing/editing the data can "fold away" groups of tags which the user has no interest in - e.g. for a building, the user probably cares about tags such as building:name= but not the architectural information in building:architecture:*=.


  • More typing (although auto-completion on the editors mitigates this to some extent).

A type= Tag

Another option is to define a tag which always describes the object type for every object. e.g.:

  • type=climbing:crag, name=Great Tor
  • type=climbing:route, rock=limestone, height=25
  • type=piste:lift, occupancy=5

The value of the "type" tag would identify the schema of all tags on the object. As in the example, above, some kind of namespacing within the value of the type tag may be beneficial since it can make the tag more descriptive and groups together related data.


  • Tag names are short
  • Relations already tend to use a "type" tag, so this fits in with those.


  • Similar to the old class system used in OSM's infancy - this was eventually replaced with the current system, although I am not clear on the reasons why (maybe someone could write an explanation?)

A Hybrid Solution

A third option is to combine the above ideas: have a "type" tag and keep the important attributes un-namespaced. Less important attributes can be grouped into namespaces to allow the viewers/editors to fold them away. For example, information about a building's architecture can be put in tags prefixed with "architecture:".


  • Common tag names are short whilst allowing less important data to be grouped together and "folded away" by viewers/editors.

Technically correct solution

Namespace is not just a prefix - it's a tool of abstraction. The most profitable case for it is in new tagging schemes, when we proposing not only a single tag, but system of tags. In this case, we could use namespace for isolation of keys within a single scheme (or several specific schemes).

For example, there is usage=* tag, which has completely different meaning in several schemes (see Taginfo for it). There is no any sense in querying objects by this tag only, because in terms of abstraction, it describes several different classes. To avoid situations like that, we still can introduce this tag in any new scheme, but we have to use namespace for it. So, it will look like newscheme:usage=*

In the same time, as it described above, it's important to avoid excessive use of namespace, when new key describes similar properties as it did before.

For example, it would be completely wrong to propose "newscheme:operator=*" - operator=* key has pretty universal meaning. Therefore, it must not be isolated within new scheme.


I currently consider the hybrid option to be the best idea, but let the discussion commence :) -- Steve Hill 19:45, 16 May 2008 (UTC)

I like the namespacing idea but the type-tag idea has the problem that you would often have to create the same object several times if it belongs to more then one "type", and to avoid a lot of duplicate entries you would then need to regroup these objects, e.g. with relations. The hybrid concept would IMHO lead to endless discussions which tags are "important" and which are better kept in namespaces. I'd go for prefixes (we already do this) -- Dieterdreist 23:25, 13 January 2011 (UTC)
I do like the prefix method. I found this page after publishing this mail:

Since I updated the Dutch Feature Page I analyzed the tagging system and found out a typically evolution in the way OSM is tagging map objects.

1) <Key>=<Value>: Simple tagging system. Every new Tag has to be created. Every Tag and every value has to be documented. You vcan not be creative in making new combinations.

2) <Key>=<Value>, <Key> : <Subkey> = <Value>: Advanced tagging system. Besides the old fashion Key=value tags different Sub Keys are approved. Those subkeys are Telling something about the value of the main tag. In our feature list a lot of sub keys already defined, mostly unknowing it was in fact a subkey.


  • Main Key’s: Highway, waterway, Historic, Traffic_calming, shop
    • Highway=unclassified
    • cycleway=lane
  • Sub key: maxspeed, right, left, surface, width
    • Highway:surface=asphalt
    • cycleway:surface=paving_stones
    • cycleway:right=fanced

In advanced tagging there is a specific difference between main and sub tags and therefor can solve problems like:

  • Telling something about the right and left lane of the road.
  • Telling something about night and day time access rules.

These are just two examples.

By introducing "NameSpacing" / "Advanced Tagging" more different elements of the object are taggable. --ZMWandelaar 06:51, 14 January 2011 (UTC)

noun order is a mess

Okay, so what is the order? <key>:<subkey>, you say, right?

How do you tag a seasonal barrier, like a huge bush?

Is the seasonality the subkey of the barrier? Or is the barrier is one subcase of seasonality?

Oh, I see you have an answer. So does it match abandoned:shop=*,source:maxspeed=* or access:bicycle=*? Enlighten me. ;-) --grin 12:04, 5 July 2014 (UTC)

Technically, namespace is always a prefix, giving a context for key. And it's not key and subkey, it's namespace and key. Say, we are going to propose two imaginary tagging schemes with same "type" key. These two "types" have completely different meaning and values. So, we should use scheme1:type=* and scheme2:type=* respectively. Namespace is a technical term from XML technology. See namespace tutorial at W3Schools for details.--BushmanK (talk) 20:21, 14 December 2014 (UTC)

This is not about XML namespaces. Namespaces in OSM keys can be prefix or infix and not always easy to decide which one it should be. For a few established namespaces it has already been established by convention. RicoZ (talk) 12:33, 27 March 2015 (UTC)

Nomenclature/" infix is used only once in Tags."

Anyone recalls what this was supposed to say? RicoZ (talk) 21:25, 2 August 2015 (UTC)

Is it clearer now?--Jojo4u (talk) 19:41, 4 August 2015 (UTC)
Yes, that is clear. Not sure if it is true and if it makes sense to make the postfix/infix distinction. Isn't it so that every suffix could end up as an infix if there are 2 or more suffixes useful/required to describe a special situation? RicoZ (talk) 09:33, 5 August 2015 (UTC)