DE:Namespace
Ein Namensraum ist ein Vorsatz oder Namensanhang innerhalb eines Schlüssels. Namensräume werden entweder für die Gruppierung eng verwandter Tags oder als zusätzliche Qualifikation für Schlüsselwörter verwendet. Die akzeptierte Methode ist es, einen Doppelpunkt (':') als Trennzeichen in Schlüsselwörtern zu verwenden.
Beispiele
| Namensraum | Beschreibung | Listenübersicht der Verbreitung |
|---|---|---|
| addr: | Attribute, die einen Teil einer Adresse enthalten | taginfo addr:* |
| contact: | Kontaktmöglichkeiten | taginfo contact:* |
| generator:output: | Art der Energieerzeugung und Nennleistung eines Generators | taginfo generator:output:* |
| toilets: | Eigenschaften von Toiletten | taginfo toilets:* |
| :lanes | Beschreibung einzelner Spuren einer Straße zusammen mit ihren individuellen Eigenschaften | taginfo *:lanes |
| parking:lane: | Parkstreifen an Straßen | taginfo parking:lane:* |
| disused: | Objekte, die zur Zeit nicht mehr in Betrieb, stillgelegt oder verlassen sind. | taginfo disused:* |
| abandoned: | Objekte, die vom Besitzer aufgegeben wurden und nicht länger instand gehalten werden | taginfo abandoned:* |
| proposed: | Objekte, die noch in Planung sind | taginfo proposed:* |
| construction: | Objekte, die noch im Bau sind | taginfo construction:* |
| demolished: (en) | Objekte, die abgerissen sind | taginfo demolished:* |
| removed: | Objekte, die nicht mehr existieren | taginfo removed:* |
| source: | zur Kenntlichmachung der Quelle | taginfo source:* / taginfo *:source |
| :conditional | Attributierung von bedingten Beschränkungen | taginfo *:conditional |
| :forward | Wegeigenschaften die sich auf die Richtung vorwärts beziehen | taginfo *:forward |
| :backward | Wegeigenschaften die sich auf die Richtung rückwärts beziehen | taginfo *:backward |
| :left | Wegeigenschaften die sich linksseitig befinden | taginfo *:left |
| :right | Wegeigenschaften die sich rechtsseitig befinden | taginfo *:right |
| :symbol | Eigenschaften die sich in irgendeiner Weise auf Symbole beziehen (häufig auf Wegweisern) | taginfo *:symbol |
| capacity: | Gibt die Kapazität einer Einrichtung an | taginfo capacity:* |
| :type | Der Schlüssel type wird für die genauere Definition einer Variante einer Eigenschaft verwendet. | taginfo *:type |
| *:both_ways=* | Der Schlüssel both_ways wird verwendet, um Eigenschaften für Fahrspuren oder ähnliche Merkmale anzugeben, die in beide Richtungen einer Fahrbahn verlaufen. | taginfo *:both_ways |
Sprachkürzel-Nachsilbe
Sprachkürzel werden für viele Schlüssel wie z.B. "name:de=..." als Anhang benutzt. Siehe Map internationalization und Multilingual names als Anwendungen.
Status des Lebenzyklus
Es wird empfohlen einen Vorsatz wie "proposed:", "construction:", "disused:", "abandoned:" oder "demolished:" vor den Tag zu setzen, um den Status eines Objektes anzuzeigen (siehe Comparison of life cycle concepts). z.B "disused:amenity=pub". Dadurch kann erreicht werden, dass das Objekt nicht mehr in der Standardkarte angezeigt wird.
Für Straßen und Eisenbahnen wird ein anderes Schema benutzt, z.B "highway=construction + construction=motorway"
Datumsräume
Ein Datumsraum-Anhang wird für zeitliche Einschränkungen empfohlen (siehe Comparison of life cycle concepts). z.B. "name:1933-1945 = Adolf-Hitler-Straße".
Seiten oder Richtungs-Nachsilbe
Beim Kartieren von Wegen können bestimmte Eigenschaften seiten- oder richtungsabhängig eingetragen werden (siehe forward & backward, left & right). z.B. maxspeed:forward, cycleway:left, parking:lane:right
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 be source of data devaluation. We call this over-namespacing, and here are some case of namespacing abuse:
- 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.
Namespaces are not used within the majority of tags for representing the most prevalent
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.
Wiki-Seiten erstellen
Um im Wiki den link auf den prefix zu lenken schreibt man statt
- ':'
- '|:='
| Editor-Wiki | Wikiseite | |
|---|---|---|
| ohne | {{tag|disused:shop|clothes}} | disused:shop=clothes |
| mit Sonderzeichen | {{tag|disused|:=shop|clothes}} | disused:shop=clothes |