From OpenStreetMap Wiki
Jump to: navigation, search
Available languages — Relation:destinationsign
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 bokmål norsk nynorsk occitan Oromoo oʻzbekcha/ўзбекча Plattdüütsch polski português português do Brasil 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 беларуская български қазақша македонски монгол русский тоҷикӣ українська Ελληνικά Հայերեն ქართული नेपाली मराठी हिन्दी অসমীয়া বাংলা ਪੰਜਾਬੀ ગુજરાતી ଓଡ଼ିଆ தமிழ் తెలుగు ಕನ್ನಡ മലയാളം සිංහල ไทย မြန်မာဘာသာ ລາວ ភាសាខ្មែរ ⵜⴰⵎⴰⵣⵉⵖⵜ አማርኛ 한국어 日本語 中文(简体)‎ 吴语 粵語 中文(繁體)‎ ייִדיש עברית اردو العربية پښتو سنڌي فارسی ދިވެހިބަސް
Public-images-osm logo.svg destinationsign
destination signs for various transport modes
  • Node - sign
  • Node - destination
  • NodeWay - from
  • Way - via
  • Way - to
Status: Unspecified

For another format that might be supported in navigation software, see Relation:destination_sign

This relation allows information about destination signs. Intended uses cover describing what signs to follow on a otherwise constructed route and visualizing the extent of the area with signs pointing to any particular destination.

Why not Relation:destination_sign?

The other "destination_sign" relations focus on the physical appearance of the signs and require one relation for every sign. Other users might be interested in the area covered by signs pointing to any particular destination, in other words the network of ways leading there.

For example of the signs pointing to central Helsinki Relation 169846 (XML, Potlatch2, iD, JOSM, history, analyze, manage, gpx).

To keep these from impeding any software understanding the other kind of destination sign relations, the type tag is intentionally different. Support for both types of relations is expected to be reasonably easy, if the other one is supported.


Key Value Example Required? Comment
type destinationsign destinationsign yes The type of relation.
note a descriptive name Pasila (kev.liikenne) no The destination as displayed to editors. Might include additional information, such as "(foot)".
label the label on the signs Pasila no Unwanted, unless the name is spelled differently than in the name tag of the destination node.

Also tag label:lg=* for names in different languages for multilingual signs, where lg can be any language code.

foot access value yes at least one of these transport modes indicated on the sign. (Optional)
bicycle access value yes transport modes indicated on the sign. (Optional)
any transport mode access value yes transport modes indicated on the sign. (Optional)

For multiple signs to one destination, only one relation will be needed when transport modes are equal.

For signs with multiple destinations multiple relations should be created.


Way or Node Role Recurrence? Description Comment
NodeWay destination exactly one The entity to which all the members guide to.
The following roles/members can be repeated as many times as necessary, but in this order:
Node sign one - optional The point where the sign is. This could be a node on the way approaching an intersection (overhead signs) or a point next to the road, before, after or next to the intersection. Such node is likely tagged with traffic_sign=destination or guidepost=destination.
NodeWay from one or many The node where, or the way at the end of which, one must choose the correct way.
Way via zero or many (optional) Any ways linking the from member to the to member. Probably unambiguous for any given transport mode, so mostly hardly any sense in adding them.
Way to one They way the sign points to. The way that (almost always) starts at the node indicated by the from role.


See Also

Competing proposals talk page for some older comments.

Notes to makers of routing software

As with the Relation:destination_sign, the originally intended purpose is rendering on navigators (like this - in the next intersection follow the sign "E4 Malmö") or in turn-by-turn descriptions when following an already made route - in the original intent this is not for aiding the creation of routes.

  1. Check for destinationsign-relations along the route (which is already made and we are about to follow).
  2. Keep all relations where the route passes the from member and then the to member of the same relation without having any other to members in between those members.

More notes about how to enhance the user experiance are at Relation:destination_sign#Notes to makers of routing software.