Relation:destinationsign

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 169846 169846.

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.

Tags

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:XX=* for names in different languages for multilingual signs, where XX 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.

Members

Way or Node	Role	Recurrence?	Description	Comment
	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:
	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.
	from	one or many	The node where, or the way at the end of which, one must choose the correct 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.
	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.
• destination:wikidata=* and destination:ref:wikidata=* are used more frequently than destination to refer to the destination unambiguously

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.