Subexits are treated as forks in the road

[1ec5]

This route takes exit 1A by way of a collector-distributor lane shared between exits 1A and 1B. A driver would expect it to contain:

1. an off ramp maneuver to get onto the initial shared exit at this point
2. an off ramp maneuver at this point where exits 1A and 1B split

However, OSRM produces:

1. an off ramp maneuver to get onto the initial shared exit at this point
2. a fork slight right maneuver at this point where exit 1C branches off
3. another fork slight right maneuver at this point where exits 1A and 1B split

It appears that OSRM only issues an off ramp maneuver to leave a highway=motorway way but not to leave a highway=motorway_link way.

/ref #4222 (comment)
/cc @daniel-j-h @MoKob @freenerd @willwhite

[MoKob]

@1ec5 can you elaborate why you would expect 2.? From looking at the satellite imagery, I would expect a fork to be perfectly reasonable, since the road has two lanes coming to the intersection (although not mapped) and each of these lanes continues as it's own exit.

From my understanding, a ramp would be an actual turn, as in 1. where we initially exit or like at the branch of 1C when we would turn off the initial exit.

The main problem in situations like this is, that I don't see any data here that would support finding out about what is an exit and what not with the current set of data available to OSRM.

The only solutions I would see is to:

• use current tagging situation and:
  • parse motorway_junction tag and store information for nodes
  • use the parsed motorway junction to identify exits on motorway ramps
• update tagging for lanes
  • identify lanes splitting off the highway (e.g. 1c: 2 lanes -> 1 lane | 2 lanes and 1a/1b 2 lanes -> 1 lane | 1 lane)
  • assume new lanes will be an exit

We cannot use the ref/destination information, as this information doesn't seem to line up with the expected behaviour. At least I couldn't find any connection at the collector-distributor lane you pointed out.

[1ec5]

can you elaborate why you would expect 2.? From looking at the satellite imagery, I would expect a fork to be perfectly reasonable, since the road has two lanes coming to the intersection (although not mapped) and each of these lanes continues as it's own exit.

A fork instruction is fine, so long as it comes with an exit number, as proposed in Project-OSRM/osrm-text-instructions#128. The larger problem is the fork slight right instruction at this node, which is intended to keep the user on the collector-distributor lane instead of taking left exit 1C.

A longer express lane tagged as a highway=motorway_link way could have several exits along it. OSRM would redundantly say “keep left at the fork” over and over again as the user heads down the express lane.

The main problem in situations like this is, that I don't see any data here that would support finding out about what is an exit and what not with the current set of data available to OSRM.

You’re right, this is an unfortunate ambiguity arising from a very common tagging style in OSM. A mapper in this case might assume that because the 1C ramp branches off from the node but the collector-distributor way continues on, unsplit, no instruction would be emitted. But of course that isn’t a reliable assumption, because the way may be split for reasons such as the lane count, speed limit, or height clearance changing.

identify lanes splitting off the highway (e.g. 1c: 2 lanes -> 1 lane | 2 lanes and 1a/1b 2 lanes -> 1 lane | 1 lane)

This could be a solution, although in that case I wonder if we could also consider the more informative destination:lanes and destination:ref:lanes tags, as I mentioned in #4222.

[MoKob]

@1ec5 I guess you are right regarding the destination:lanes thing.... Sadly this is just a completely new feature for OSRM and not easily added. I will try and make some initial studies on what it would take to add these.

[daniel-j-h]

Relevant client workaround Project-OSRM/osrm-text-instructions#128