User:Jojo4u/destination best practices
The interaction between destination=* and the lanes-extension destination:lanes=* is currently not well documented.
Current documentation
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=|Hamburg
producesdestination:lanes=Berlin|Hamburg
).
On the general lanes extension and the turn key pages the motorway tagging example has the following properties
destination:lanes
is not tagged on every way from the signpost to the exit. (-> Question 1)destination
is 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:
- Describes
destination
as "simple" tagging: This tagging variant is usually sufficient except on complex interchanges. destination:lanes
has the advantage of giving the positions of the signpost.- If
destination:lanes
is used,destination
should also be used.
Problems of destination:lanes
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.
Lane assist
If only 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.
If only 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.
If [number of incoming lanes] != [number of outgoing lanes]
, using both destination
and 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 transit:lanes
.
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.
Fixes to destination
- The start of the signage is not explicitly set.
Possible fix: Combination with other lane-related tagslanes
andturn:lanes
. But best solution is a new new 'start of signage' tag. This could bedestination(: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 oftransit:lanes
.
- Support for situations where a second split comes closely after the first
Possible fixes: None found yet.
Questions
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 turn(:lanes)
.