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 produces destination: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 tags lanes and 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 transit: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).