Namespace

From OpenStreetMap Wiki
(Redirected from Subkey)
Jump to navigation Jump to search

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. key:suffix=value 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

Namespace Description List overview of distribution
capacity: Describes the capacity a facility is suitable for. taginfo capacity:*

Nomenclature

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