Use turn lanes in guidance instructions

[chaupow]

Currently OSRM generates instructions such as right or left by identifying left or right turns based on the geometry.

Interpreting geometries correctly is difficult and often we do not interpret it correctly. Example: This should turn left

Fixing guidance and geometry identification is a bigger lift, what we this issue proposes is to use turn lanes information to annotate turn types as a "fallback" or "quick fix":

If, for example, there are turn lanes saying left|right at an intersection, we should annotate the turns as left and right accordingly and not annotate them straight and right even if we might conclude that with the geometry.

Unfortunately, the OSM database does not have a lot of turn lanes, so we definitely cannot base our guidance solely on turn lanes and disregard geometry identification. There are still reasons why we would want this fix:

• If the geometry is difficult, it is an easy fallback to fix this
• If there is a turn-lane in the data, we can have high confidence in the data that the resulting instructions is correct (especially at T-intersections)

[chaupow]

Possible first steps

• [ ] write failing tests that capture scenarios similar the one described
• [ ] add an additional turn-lane-handler here https://github.com/Project-OSRM/osrm-backend/blob/master/src/guidance/turn_analysis.cpp#L40
• [ ] use the turn handler to (over-)write turn assignments

[coxchapman]

@oxidase @chaupow does this mean that turn-lane data would be the primary source for turn identification where it is present? That seems fairly brittle and prone to mistagging or vandalism. On the other hand, the idea is a good one -- turn lanes are good input into the turn type. Can we limit this somehow so the turn lanes function as an input rather than the primary classifier?

[1ec5]

does this mean that turn-lane data would be the primary source for turn identification where it is present? That seems fairly brittle and prone to mistagging or vandalism.

Turn lane tags aren’t any more fragile than name, destination, ref, or highway tags. Those tags affect guidance in more profound ways, and they’re far more open-ended than turn lane tags.

Can we limit this somehow so the turn lanes function as an input rather than the primary classifier?

OSRM already discards turn lane indications it thinks are nonsensical. In fact, there are plenty of examples (see below) where OSRM is too aggressive in discarding turn lane indications. When OSRM encounters a counterintuitive cardinal direction or maneuver relation, it honors it. I don’t see why turn lane tags should be any different, given that these tags are almost always based on verifiable imagery or groundtruthing.

Five-way stop at the foot of an off-ramp (4th and Bryant, San Francisco)

Imagine you’re looking out the windshield at this and hear that [you need to turn left or slightly left](http://map.project-osrm.org/?z=18¢er=37.779647%2C-122.397743&loc=37.779161%2C-122.399443&loc=37.780340%2C-122.397094&hl=en&alt=0). You’re in a through lane (based on the arrow on the pavement), so you move to the leftmost lane: [](https://openstreetcam.org/details/12016/4500/track-info) You keep going and prepare to make a left turn from the left lane: [](https://openstreetcam.org/details/10065/4888) But wait – what about the No Left Turn sign on the left side there? If you didn’t see it, you might end up going the wrong way on 4th Street, or at least be forced to pull into the gas station. Due to the shape of this intersection, OSRM’s turn classification is going to call it a left turn based on the turn angle, but the lane tags would ensure a “Continue straight” instruction, which would be consistent with all the other cues you’d see as you keep your eyes on the road. [](https://www.openstreetmap.org/edit#map=20/37.77956/-122.39816) (Actually, [the way in question](https://www.openstreetmap.org/way/31560837) has been edited to have left turn lanes instead of through lanes. That’s unsupported by the available satellite and street level imagery, so that change would have to be undone in order for OSRM to produce the correct guidance.)

Staggered intersection (Cooper and Wayne, Lockland, Ohio)

You can tell this is a staggered intersection because all approaches share a single set of traffic lights and a single set of crosswalks. You can also tell because westbound Cooper Avenue’s right lane is marked for going straight through: [](https://www.openstreetmap.org/#map=19/39.22387/-84.46118) Heading westbound on Cooper Avenue through Wayne Avenue should be considered a straight maneuver, and OSRM should recommend the right lane to make that maneuver. Yet instead OSRM says it’s [a right turn followed shortly by a left turn](http://map.project-osrm.org/?z=18¢er=39.223957%2C-84.460638&loc=39.223867%2C-84.459919&loc=39.223859%2C-84.462097&hl=en&alt=0). The intersection’s split distance is a bit too great for OSRM to consider it a staggered intersection. The threshold for a staggered intersection may be set too low, but there isn’t a good single value anyways, because another intersection of this size may indeed be two intersections, especially if it isn’t signalized. The split distance matters, but so too does the presence of a through lane.

Staggered intersection (Eggleston/Broadway/Court, Cincinnati)

The approaches to this staggered intersection are bent so severely that turn angle classification falls apart completely: [](https://www.openstreetmap.org/edit#map=19/39.10715/-84.50764) OSRM thinks going northbound from Broadway Street to Court Street entails [turning left then right](http://map.project-osrm.org/?z=19¢er=39.106897%2C-84.506965&loc=39.106079%2C-84.507458&loc=39.107332%2C-84.506750&hl=en&alt=0). But imagine you’re looking at the pavement here, trying to decide which lane to take:  If you listen to OSRM and take the left lane to turn left, you’ll end up on westbound Eggleston Avenue due to lane change restrictions. It’s really the middle lane you want. There’s no way a router would get this right given the topology here, so [this `manoeuvre` relation](https://www.openstreetmap.org/relation/8100842) will force OSRM to consider it a straight maneuver (once #5004 makes it into a release). Still, it would be nice if a maneuver relation weren’t necessary, since it’s somewhat redundant to the turn lane indications.

[oxidase]

Related to #3365 and missing instruction at http://map.project-osrm.org/?z=18&center=49.487491%2C8.476472&loc=49.487747%2C8.477073&loc=49.487218%2C8.475899&hl=en&alt=0

[github-actions[bot]]

This issue seems to be stale. It will be closed in 30 days if no further activity occurs.