Vary instructions by lane based on destination:lanes

[1ec5]

A route step’s instruction and destinations should account for the destination:lanes and destination:ref:lanes tags when present. Consider the following scenario:

with this collector-distributor way:

destination=Dearborn Street;James Street;Madison Street;Spokane
destination:lanes=Dearborn Street;James Street;Madison Street|Spokane
destination:ref=I 90 East
destination:ref:lanes=|I 90 East

If the route travels to Dearborn Street, then the route step representing the collector-distributor way should have a destinations of Dearborn Street;James Street;Madison Street and an instruction mentioning Dearborn Street. On the other hand, if the route travels towards Spokane on eastbound I-90, then that same route step should have a destinations of I 90 East: Spokane and an instruction that mentions Spokane.

#2553 (comment) suggests that destination:lanes could help deduce the correct lane to take.

/ref mapbox/mapping#308 Project-OSRM/osrm-text-instructions#30
/cc @freenerd @daniel-j-h

[1ec5]

In the United States, collector-distributor lanes are common in urban areas and at interchanges between freeways. These are often critical junctions where missing a turn could mean a 10-minute detour. OSRM’s current behavior of observing destination and destination:ref but not destination:lanes or destination:ref:lanes can cause clients such as the Mapbox Navigation SDK for iOS to display mismatched UI.

For example, here’s an exit in which the left two lanes (out of five) share a single exit and split shortly thereafter (from Mapillary):

The way shared between exits 1B and 1A is tagged:

destination=2nd Street;Downtown;Riverfront
destination:ref=I 71 North;US 50 East
destination:lanes=|2nd Street;Downtown;Riverfront
destination:ref:lanes=I 71 North;US 50 East|
destination:to=I 471;US 52 East
destination:ref:to:lanes=I 471;US 52 East|
junction:ref=1B;1A
junction:ref:lanes=1B|1A

This route would first take the shared 1B-1A exit, then exit 1A towards 2nd Street (as opposed to I-71). OSRM returns an exits of 1B;1A and a destination of I 71 North, US 50 East: 2nd Street, Downtown, Riverfront, which looks like this in a typical client:

This is a problem, because the label suggests one subexit and the shield suggests another. The expected behavior would be a destination of just 2nd Street, Downtown, Riverfront, based on the right side of destination:lanes and the right side of destination:ref:lanes (the empty string).

The way in question probably should be tagged with lanes=2, but I wonder if the number of lanes could be inferred from destination:lanes.

/cc @willwhite @ericrwolfe

[1ec5]

In this same interchange, a route leading to 2nd Street (exit 1A) ends up saying “take exit 1B” and never says “take exit 1A”. This is due to a combination of factors:

• The highway=motorway_link way shared between the two exits is tagged junction:ref=1B;1A, but OSRM Text Instructions discards all but the first exit number, saying only 1B. Until this issue is resolved, OSRM Text Instructions should include all the available exit numbers. If an exit number like 30A;30B;30C would be too verbose, perhaps we can perform an abbreviation like “exit 30A–C” (which is often how such exits are signposted).
• The subsequent highway=motorway_junction node where exits 1B and 1A split is treated as a fork in the road by OSRM (“Keep right at the fork”), rather than a highway exit, even though the individual highway=motorway_link ways after that are tagged with the correct junction:ref tags.

I filed Project-OSRM/osrm-text-instructions#127 for the first issue and #4295 for the second issue.

[1ec5]

Perhaps OSRM Text Instructions could be responsible for varying the instructions based on destination:lanes and destination:ref:lanes. The backend would need to expose those tags’ values in the Intersection objects; beyond that, it should be straightforward for OSRM Text Instructions to match a lane destination with a lane indication, assuming there are lane indications in the first place.

[MoKob]

@1ec5 when exposing destination:lanes, I would kind of expect a connection to turn:lanes as provided in the lanes field of our response. Do you imagine such a relation, or would it be Ok to just return these destination:lanes as we do in destination?
In case we need to to destination:lanes as lanes, exposing these would become way more complicated, since we would need name IDs for on lane basis, for which I cannot even guess how much work that would be right now.

[1ec5]

I think OSRM Text Instructions could make use of a raw destination:lanes value that includes all the lanes, provided that lane indications are available for that same intersection. Suppose a way has the following tags:

destination:lanes=SR 4 North|SR 4 North;SR 4 South
turn:lanes=through|through;right

If both lanes are valid, as indicated in the Intersection object, then OSRM Text Instructions could pick SR 4 North from destination:lanes to use in place of destination. If the route uses the right lane only, then it could pick out SR 4 South the same way.

[willwhite]

Here's a case of a collector-distributor where adding lanes wouldn't help:

• Should be toward San Francisco - instead says San Jose
• Correctly says toward San Jose

I'm not sure this was proposed as such, but this wouldn't be an alternative for Project-OSRM/osrm-text-instructions#30.

[1ec5]

I'm not sure this was proposed as such, but this wouldn't be an alternative for Project-OSRM/osrm-text-instructions#30.

I agree, Project-OSRM/osrm-text-instructions#30 would be desirable for precisely the situation you describe. This issue tracks a related but distinct feature, in which we not only include the most relevant ref and destination but also vary the suggested lanes, which will affect the instruction as well (“Use the second lane from the right to take the ramp…”).

[1ec5]

As an alternative to implementing the proposed logic in OSRM-backend, the destination:lanes, destination:street:lanes, and destination:ref:lanes values could be added to Intersection objects alongside the existing turn:lanes values. A client of OSRM could then implement the disambiguation logic itself.

/ref #3281 (comment)