Namespace

A namespace is a prefix, suffix or infix to a key. It can be used in special cases to group closely related keys, or as an additional qualifier for keys. The colon character (':') is used as separator of namespaces in key names. The possible benefits of introducing namespaced keys must be weighed against their disadvantages.

Grouping of closely related keys in namespaces helps to separate this group of keys, avoiding naming clashes and provides a higher level context to a particular key.

Namespaces as qualifiers are used when an attribute (such as language code) is applicable for a wide range of unrelated main keys.

Technically both concepts are treated to a large extent the same – key names containing a colon separator are strings of characters just like any other key.

Storing a value in a manner, similar to a namespace syntax i.e. where suffix equals to some variable value, not serving a grouping purpose, does not mean that namespace concept is utilized here. It's just a colon-delimited suffix.

Example namespace uses

• addr:*=* tags to contain part of an address
• The suffix :conditional is used for keys with conditional restrictions values
• contact:*=* tags
• Date namespace — A date namespace suffix has been suggested (in Comparison of life cycle concepts) to specify temporal validity of tags, eg "amenity:1835-1965 = school", "name:1933-1945 = Adolf-Hitler-Straße". The suffix comes as last part of the key (eg after language code suffix). Warning: this syntax is relatively common, but it is just a part of a proposal, while, technically, it is not a proper namespace.
• generator:output=* to provide information about the power output of an electricity power generating plant.
• is_in=* old namespace that is still present in database
• :lanes suffix to add lane-specific information.
• Lifecycle prefix — It has been suggested (in Comparison of life cycle concepts) to use a prefix such as "proposed:", "construction:", "disused:", "abandoned:" or "demolished:" to tag features in a special state, eg "construction:aerialway=gondola". For highways and railways a different tagging is de facto standard, eg "highway=construction + construction=motorway". See Comparison of life cycle concepts.
• Multilingual names — code suffixes are in use for many keys such as "name:ro=..." indicating the Romanian name of a feature. See Map internationalization and Multilingual names for some uses. The suffix comes immediately after the main key.
• parking:left=*, parking:right=* or parking:both=* to provide information about parking lanes for highway=*
• source=* to indicate source of all tags or only specific tag
• traffic:hourly=* indicate traffic density and can be used as namespace.
• Forward & backward, left & right suffixes to indicate that tag only applies in the some direction or side for the Way.
• More examples as a table:

Nomenclature

• namespace describes the whole concept (i.e. this page). When used as a prefix namespace, the word prefix is often omitted.
• prefix is the usage of a namespace in front of a key (used in Tags, Lifecycle_prefix, addr).
• suffix is the usage of a qualifier after a key (used in Tags, Conditional_restrictions, Key:name, Lanes).
• subkey is used in two contexts
  • as an additional key which further describes a Feature (used in Key:waste, Key:motorboat)
  • for describing a suffix (used in Lanes, Key:phone, Key:addr, Class:bicycle and Template:Tag/doc).
• infix is used very rarely (Tags, Talk right/left)

This wiki's software is also using the concept of namespaces but this is unrelated to the concept of "namespaces" in keys and tags used in the OpenStreetMap database.

Consuming namespaces

At a basic level within the system, a key with a namespace will just be stored and treated as any other free-form text string (a string which just happens to have a colon character).

Many consumers of OSM data will treat keys like this. Consuming applications often match on keys they are interested in, and any unrecognised keys are ignored. This may indeed be the desired effect of a namespace. Namespaces can be used to separate out certain types of specialist information, side-lining this data away from the 'core' map data, to make it clearer that only more specialist consumers will be interested in it.

Over-namespacing

Namespacing is a great way to structure the data scheme, but it can also cause troubles for some data consumers, they call it over-namespacing.

• project related namespace: it can be tempting sometimes to just namespace a key to avoid clashing with other data instead of trying to integrate existing schemes, this is bad habit. OSM is a multi-scheme database, which means that every tag relates to more than one scheme, more than one use of the data, and so it's important to integrate with other schemes already used to maximise the curation of the data

• over-namespacing leads to inconsistency in the database: if we have projectfoobar:name=xxx and name=xxx, in many cases one will be updated and not the other. The simpler and more generic is the key, the more used it will be, the more curated it will be.

• over-namespacing leads to a disseminated data scheme: for example, someone interested in VHF channels data will have to look for harbour:VHF_channel key, plus seamark:habour:VHF_channel, plus VHF_channel, plus lock:VHF_channel, plus vhf to collect the data... Using only the vhf key should be enough to know that this data relates to the harbour or the lock or what else is the OSM object we are tagging.

For the most frequent Map Features (i.e. the most regular tags which new mappers will use most often) simple keys (without any namespaces) are prevalent.

When not use

In some cases, it still possible to use generic notation without clashes. For example, model=* vs. siren:model=*. Both keys indicates a model, but model=* is shorter and applicable to any relevant feature, not only sirens.

See also

• Homonymous keys – keys that serve a different purpose or have a different data type depending on the primary tag of the element. In other cases, a homonymous key may have different semantics when tagged on a node versus a way.
• Sophox query for the most deeply nested subkeys
• Wiki namespaces
• Order of key parts