From OpenStreetMap Wiki
Jump to navigation Jump to search
Public-images-osm logo.svg destination_sign
Destination signs at or before intersections Edit or translate this description.
Group: Properties

  • node - sign
  • node - intersection
  • nodeway - from
  • nodeway - to
Status: approvedPage for proposal

This relation allows information about destination signs at crossroads to be entered into OSM. When using a routing software as navigational aid, it is very helpful to be shown the signs to follow. E.g. instead of just saying "Turn left in 200m" a routing software also could say "Follow the sign to Österstad".

Note: The originally intended purpose is rendering on navigators 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.

 Should I use a destination_sign relation or destination=* keys?

The destination_sign relation must be used in situations where destinations specified on signs differ, depending upon which direction you are arriving from. This is most common at roundabouts and intersections involving two-way roadways. In these cases, a destination_sign relation must be used to provide unambiguous guidance, in the form of multiple destination_sign relations. Even so, destination_sign relations can still be used at intersections where all signs in all directions are identical.

destination_sign relations assume that the intersection node is the turning decision point for a driver. If you wish to indicate destinations before the junction on a per-lane basis, destination_sign relations are not capable of holding this information. For those, destination=* keys (specifically, those explained in Lanes), must be used on the ways instead.

In contrast, destination=* keys work when all inbound ways into a junction point indicate the same outbound destinations. This makes destination=* keys and subkeys a popular choice among editors for: motorways and other one-way type highways; on waterway relations (waterways are by definition are one-way, their direction of flow); and for simple intersections where indicated destinations are identical from all directions.

To map the position of signs on hiking/cycling/skiing routes, use information=guidepost. The destination_sign relation can still be used for a complete representation of the content of the sign.


Key Value Example Comment
type destination_sign destination_sign The type of relation.
destination a name ÖSTERSTAD The destination as it says on the sign. Distance not included.
distance a number km or mi 16 km The distance reported on the sign (Optional)
time hh:mm 3:15 The time reported on the sign/guidepost (Optional and for trekking)
colour:back a colour blue The background colour of the sign. (Optional)
colour:text a colour white The text colour of the sign. (Optional)
colour:arrow a colour white The border/arrow colour of the sign. (Optional)
destination:ref a reference A 16 East The reference as indicated on the sign. (Optional) See Destination details.

For signs pointing to a feature use the normal tag(s) for that feature, for example a sign having a hospital icon and no name can simply be tagged (type=destination_sign + amenity=hospital) or (type=destination_sign + aeroway=aerodrome), to give two examples. Alternatively, the tag destination:symbol=* could be used.

For signs with multiple destinations, one destination_sign relation should be created per indicated direction. (When multiple destinations are indicated per direction, these can be listed in the relation's 'destination' field separated by semicolons. If supplementary information must be provided, like distance or time, one destination_sign relation per destination should be created).

Colours should default to some (preferably national standard) presets if omitted. This is handled by the routing/map showing software. Since shades of yellow are probably not interesting, we don't see a need to specify an RGB-colour. Colours could (should?) be chosen from a set list e.g. black, white, red, blue, green, brown, and yellow. See colour=* for possible values.



Way or Node Role Recurrence? Comment
nodeway to exactly one A way/node (typically but not necessarily the first one) on the way after the junction.
nodeway from one or many - optional A node/way (typically but not necessarily the last one) before coming to the junction.

Unnecessary when destination signs are the same from all "non-to" directions.

node intersection one - optional The node of the intersection. Either this or from must be given
node sign one or many - optional The point where the sign is. This could be an intersection or a point before it.

Not approved, but exists in the wild

Way or Node Role Comment
nodeway (none) destination_sign does not support empty role members; a role as specified above must be added to each relation member.

(When found, an empty destination_sign role member is never correct.)

way via Not part of the approved proposal.

When used, via is used on ways to fill the same role as an 'intersection' node.

It makes no sense on a node, because the 'intersection' role already fills this role.


See Also

  • Original proposal
  • destination=* – a different solution for mapping the text and effects of destination signs (but not the signs themselves as positional objects or sign design).


  • If you are using JOSM, check the style "Lane and road attributes" from Martin Vonwald. It shows the attributes lanes, turn, destination and Relation:destination_sign.

Notes to makers of routing software

Once again: 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 destination_sign-relations along the route (which is already made and we are about to follow).
  2. Keep all relations where the route passes the intersection or from member and then the to member of the same relation.
  3. Remove all relations that have from member(s) but no from member is being passed through by the route.
  4. If necessary (e.g. on devices with small screens) remove relations (in a smart way) so there are fewer relations shown in each intersection.
    • A good routing software would look ahead and see what destinations are shown further down the road and minimize the number of different destinations shown. One of the better ways to reduce signs is to follow signs with the same destination for as long as possible. E.g. if I'm going to Timrå I should follow the sign "E 4 Sundsvall", but I could also follow the sign "Umeå" and then "Örnsköldsvik" and then "Sundsvall" and I would still be following the exact same route. It's just a little more convenient to follow the Sundsvall-sign from the beginning.
  5. Show to the user a sign (possibly with specified colours) with the name from the destination-tag.

Quality tool

Support by navigation software

This schema is supported by the following software:

  • None known to date
  • There is a map showing destination signs and rendering them based on this tagging scheme: [1]