User:Jojo4u/destination best practices

From OpenStreetMap Wiki
Jump to: navigation, search

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.

Different properties

destination:lanes

  • is unnecessary if signed destination does not differ per lane

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. The start of the destination display is at a router-predefined default distance.

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. A new tag should be invented for this task, it should be tagged on the way to use :forward/backward suffix.

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 the start of the destination display should be controlled by using only destination there needs to be some 'start of signage' tag. A new tag should be invented for this task, it should be tagged on the way to use :forward/backward suffix.

If only destination:lanes is used the router needs the same logic used for turn(:lanes) in order to find the right 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.

Displaying per-lane signage without lane assist

Just displaying per-lane signage signage is not of any use for routing, and this was 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 the road nevertheless, probably with traffic_sign=*.


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