User:Jojo4u/destination best practices
The destination key page says about the lane extension:
- Often the destinations of a road differ from lane to lane. To specify those for every lane, destination:lanes=* is used.
- The lanes extension tagging should be started directly after the signpost on the motorway.
In addition the german destination key page add the convention:
- A destination tag is overwritten on per-lane base by a non-empty destination:lanes tag (e.g.
destination=Berlin + destination:lanes=|Hamburgproduces
destination:lanesis not tagged on every way from the signpost to the exit. (-> Question 1)
destinationis not used.
All examples on the mentioned pages (including the destination details page) usually only use
destination even for exit signs on motorways. Only one
destination:lanes example is provided.
The lane assist example page:
destinationas "simple" tagging: This tagging variant is usually sufficient except on complex interchanges.
destination:laneshas the advantage of giving the positions of the signpost.
destinationshould also be used.
The tag suffers from two major problems:
- Value often becomes longer than the allowed 256 characters, especially if place name abbreviations are not used.
Possible remediation: Remodelling of tag to use one tag per lane.
- Duplication of information on many lanes and many ways which leads to harder editing and synchronization problems.
Possible remediation: Better tool support.
My conclusion: Because of those problems the usage of the tag should be limited to necessary scenarios.
Start of destination display
In the simplest router implementations the start of the destination display is at a router-predefined default distance.
For better implementations the start of the display of destinations should at the first signage:
- Assurance for user that the router has not lost track when signs appear early
- For important intersections the start of signage is earlier
Scenarios of usage
Displaying destinations without lane assist
If only the display of the destinations ("take the road with destinations X,Y") is needed, then
destination is preferable.
If the start of the destination display should be controlled there needs to be some 'start of signage' tag.
destination:lanes could be used, but the router would just discard the content and display the
destination value from the point where
destination:lanes starts. The best solution would be a new tag for this task.
destination is used the router needs assign destinations to lanes before the split. It needs a reverse logic used for
turn:lanes. This is only guaranteed to work if
[number of incoming lanes] = [number of outgoing lanes]. If other lane-related tagging is not used for the start of the destination display there needs to be a new 'start of signage' tag.
destination:lanes is used the router needs the same logic used for
turn:lanes in order to find the correct lane. This is only guaranteed to work if
[number of incoming lanes] = [number of outgoing lanes]. The start of the destination display is controllable here.
[number of incoming lanes] != [number of outgoing lanes], using both
destination:lanes and using the same destinations on both would allow a lane-assist router to assign the needed lane by string-comparison. It would also help to display the correct
turn(:lanes). This is only guaranteed to work if the signed destinations are the same from each direction. The start of the destination display is controllable here. A promising alternative for the need of using both destination tags would be the use of
Displaying per-lane signage without lane assist
Just displaying per-lane signage is not of any use for routing, and routing is what
destination(:lanes) was invented for. Displaying destinations without lane-assist is much more preferable.
Since the actual sign is a real feature, it could be tagged as node/way along/above the road nevertheless.
- The start of the signage is not explicitly set.
Possible fix: Combination with other lane-related tags
turn:lanes. But best solution is a new new 'start of signage' tag. This could be
destination(:forward/backward):start=yes, used on ways.
- Support for forking lanes and other situations where
[number of incoming lanes] != [number of outgoing lanes]without usage of both destination tags with excessive data duplication and error-prone string-comparison.
Possible fixes: A model of the lanes of the intersection needs to be computed by the usage of
- Support for situations where a second split comes closely after the first
Possible fixes: None found yet.
Question 1: Should destination:lanes=* be tagged on all ways from the signpost to the exit/fork?
Question 2: Is calculating the sum of incoming/outgoing lanes for
destination more problematic than for
destination:lanes? The latter uses the same logic as