|destination signs for various transport modes|
|Tools for this tag|
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.
|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|
|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.|
- 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.
- Check for destinationsign-relations along the route (which is already made and we are about to follow).
- 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.