Relation:destination_sign

For road signs signaling destination-only access restrictions, see motor_vehicle=destination § Sign text.

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 tag destinations using a destination_sign relation or directly on ways?

The destination_sign relation can be used in situations where destinations specified on signs differ, depending upon which direction you are arriving from. This can happen at roundabouts and intersections involving two-way roadways. In these cases, a destination_sign relation provides 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. They provide a full picture of the situation: where the sign is, from where it can be read, where to turn and where to go to.

In contrast, destination=* keys tagged on the road leaving the intersection towards the signposted destination do only provide the "where to" piece of information. Additionally, destination:lanes=* can be used to tag turn lanes leading to the intersection with their respective destination to add "from where" information.

This makes destination=* keys and subkeys on ways a popular choice among editors for the typical highways and intersections where indicated destinations are identical from all perspectives.

Please note that the destination_sign relation, the keys destination=* and destination:lanes=* are different concepts to support the announcement of signposted destinations, which can be differently evaluated by the navigation software. As they do not conflict, all approaches can co-exist on a particular road. Support in current tools is much better for destination=* compared to the more detailed destination_sign relation.

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. In all cases, multiple destinations can be tagged as semicolon-separated values.

Tags

Key	Value	Example	Comment
type=destination_sign			The type of relation. (Mandatory)
destination=*	a name	ÖSTERSTAD	The destination as it says on the sign. Distance not included. (Necessary)
distance=*	a number km or mi	16 km	The distance reported on the sign (Optional)
time=*	hh:mm	03:15	The time reported on the sign/guidepost (Optional, needs a specified transportation mode like foot=* / bicycle=* to be meaningful)
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.
destination:street=*	street name	Main Street	The destination street name as indicated on the sign. (Optional, only if explicitly stated on the sign)
destination:symbol=*	a symbol	train_station	A symbol or icon present on the sign, check the tags' wiki entry for an extensive list of possible symbols
osmc:symbol=*	a way marker symbol	:red:white_bar	If the sign contains a symbol of a route, usually a basic geometric shape, sometimes with few characters
foot=* / bicycle=* / ...	yes/no		If the destination sign is intended for a certain group of users (Optional, only if explicitly stated on the sign)

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, time or reference numbers, one destination_sign relation per destination can be created. Alternatively a semicolon separated list can be used as well, but must contain the same number of entries as the 'destination' field.

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 it's mostly sufficient to specify a basic colour by name, e.g. black, white, red, blue, green, brown, or yellow. See colour=* for possible values.

There might be rare cases without a destination=* tag if the sign can be fully described by the other tags.

Members

Way or Node	Role	Recurrence?	Comment
	to	exactly one	A way/node (typically but not necessarily the first one) on the way after the junction.
	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.
	intersection	one - optional	The node of the intersection. Either this or from must be given
	sign	one or many - optional	The point where the sign is. This could be an intersection or a point before it. Some of them are tagged as traffic_sign=destination
	via		Not part of the original proposal, but sometimes found in the wild. 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.

destination_sign does not support empty role members; a role as specified above must be added to each relation member.

Examples

The destination sign example page holds a variety of tagging examples for destinations, including some which use this scheme. Concrete examples for this tagging scheme are:

• A hiking guidepost (with walking time)
• Suburban destination signage with refs
• Highway destination signage with multiple signs

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).
• traffic_sign=*

Tip

• 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

• You may use CheckAutopista to inspect mapping quality (see also the github project)

Support by software

This schema is supported by the following software:

• No navigation software known to date
• There is a map showing destination signs and rendering them based on this tagging scheme: OSM Destination Signs.
• Waymarked Trails has markers for guideposts that contain destination information.