FR:Espaces de noms

From OpenStreetMap Wiki
(Redirected from FR:Namespace)
Jump to: navigation, search
Langues disponibles — Namespace
Afrikaans Alemannisch aragonés asturianu azərbaycanca Bahasa Indonesia Bahasa Melayu Bân-lâm-gú Basa Jawa Baso Minangkabau bosanski brezhoneg català čeština dansk Deutsch eesti English español Esperanto estremeñu euskara français Frysk Gaeilge Gàidhlig galego Hausa hrvatski Igbo interlingua Interlingue isiXhosa isiZulu íslenska italiano Kiswahili Kreyòl ayisyen kréyòl gwadloupéyen kurdî latviešu Lëtzebuergesch lietuvių magyar Malagasy Malti Nederlands Nedersaksies norsk norsk nynorsk occitan Oromoo oʻzbekcha/ўзбекча Plattdüütsch polski português română shqip slovenčina slovenščina Soomaaliga suomi svenska Tiếng Việt Türkçe Vahcuengh vèneto Wolof Yorùbá Zazaki српски / srpski беларуская български қазақша македонски монгол русский тоҷикӣ українська Ελληνικά Հայերեն ქართული नेपाली मराठी हिन्दी অসমীয়া বাংলা ਪੰਜਾਬੀ ગુજરાતી ଓଡ଼ିଆ தமிழ் తెలుగు ಕನ್ನಡ മലയാളം සිංහල ไทย မြန်မာဘာသာ ລາວ ភាសាខ្មែរ ⵜⴰⵎⴰⵣⵉⵖⵜ አማርኛ 한국어 日本語 中文(简体)‎ 吴语 粵語 中文(繁體)‎ ייִדיש עברית اردو العربية پښتو سنڌي فارسی ދިވެހިބަސް

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

  • addr=* tags to contain part of an address
  • 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:lane=* and parking:condition=* 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.


This wiki's software is also using the concept of namespaces but this is unrelated to OSM namespaces.

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.


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.

Currently not displayed at some maps

Feel free to improve rendering of namespaced features for 'standard' map style appearing on the front page.