Turn instructions show turn right instead of straight on

[scaidermern]

Routing engine

• OsmAnd's in-app offline routing
• Any online routing provider (YOURS, openrouteservice, OSRM, etc.)

Routing Profile

Car

Start and end points

Start: 51.10898, 13.77396
End: 51.11233, 13.77967

https://osmand.net/map/?start=51.108982%2C13.773956&end=51.112331%2C13.779673&profile=car#17/51.111008/13.776660

Actual route

The route goes almost straight on but OsmAnd displays "turn right" and highlights the "turn right" arrow in the lane widget:

Turning right at this point (onto the white road) will lead into the wrong direction. Driving straight on (onto the yellow road) is the correct instruction.

The road has three lanes (lanes=3) in total. The first two lanes lead to the left. The third lane goes straight and to the right (turn:lanes=left|left|through;right):
https://www.openstreetmap.org/way/384592167
https://www.openstreetmap.org/way/414711400

Maybe this is caused by the raw road geometry of the intersection in OSM:

The route is highlighted in red (coming from south west and going to north east). According to the raw road geometry the right turn is about 48 degrees although in reality it is almost straight (blue arrow).

What I would have imagined: OsmAnd sees the road to the right road (white in the first screenshot, gray in the second) and deduces that "turn right" can't be the correct instruction. "turn right" would be the correct instruction for this white/gray road but this road should not be taken. So the only value that is left from the turn:lanes tag is to go straight.

Expected route

Show and highlight "straight on".

Maps you used (online or offline)

• Offline maps offered within the OsmAnd app for download.
• Online (tile / raster) maps

Your Environment

OsmAnd Version: 4.9.0
Android version: Android 13
Device model: Fairphone 4

Anything else?

No response

[scaidermern]

Maybe related to #11177, maybe not.
But for #11177 the same strategy could help. Ignore/remove the roads that should not be taken from the set of available turn lanes. Only then check which of the remaining turn instructions will fit the best.

[yuriiurshuliak]

The bug has been reproduced. The route incorrectly shows a "turn right" direction at an intersection where the road is essentially straight. The correct instruction should be to continue straight.

You can view the route in the web version via this link: Route Example.

[vmicho]

Well, the turn is quite sharp and the turn lane is combined right+straight so it will be a right turn for any navigation.
Redrawing a bit the geometry just before the junction like this for example might help:

This would also make left turn really left.

[scaidermern]

I've never seen such a geometry in OSM and it will create a too sharp angle for the left turn.

Better fix the code to ignore the right turn since the turn to the right leads to the wrong road.

[vmicho]

Nope, there is nothing wrong in correcting the geometry. I've done this several times.

My example is a bit exaggerated and can be done a bit better. The fact is currently even ID editor shows left+right+right turns. On the 'corrected' example above it already shows left+straight+right. It's just about sharpening the joining angle from the road from SW.
Another correction possibility would be adding a separate 'through' way or doubling the ways a bit beyond the crossroad but this will add complexity and you will need to assert all allowed/forbidden turns. The separate bus way does not simplify things here neither and it also incorrectly shows 'right' instead of through.

I've read on a separate documentation of Waze that they also suggest fixing geometry if it is a simple action, instead of adding manoeuvres (which are not supported by nearly any routers) (see https://wiki.openstreetmap.org/wiki/Relation:manoeuvre )

[scaidermern]

Nope, there is nothing wrong in correcting the geometry. I've done this several times.

I fail to understand why this is necessary. I fail to understand why the geometry even matters here.

We are coming from a road with lanes=3 and turn:lanes=left|left|through;right.

• There are four outgoing roads. The first to the left must be ignored due to a turn restriction.
• Three roads remain, matching exactly the three available turn instructions. The second road from the left has lanes:forward=2 and should not be taken. So the two left turns left|left belong to this road are removed from the available turn instructions.
• Two roads remain, the turn instructions throuth;right remains. The next road (when looking from the left) should be taken, the remaining road to the right should not be taken.
• Therefore choose the first of the two remaining turn instructions through and drop the remaining instruction right.

The resulting solution is correct. No geometry is involved here, all required information is present in the OSM tags. No misunderstanding is possible.

[vmicho]

For me it sound complicated to calculate by software correctly for every case - remember there can be more crossroads like this and even more complicated.
Here the most obvious problem is the straight+right lane where both destinations turn (geometrically) right. This most probably cannot be interpreted correctly by any software. And a fix here could potentially break hundreds of other crossroad navigation.

I've checked the 3 routers from OSM on this crossroad with straight route (SW->NE) and with the left turn, and the results are horribly inconsistent and mostly wrong.
I'd really fix geometry here.

[scaidermern]

Here the most obvious problem is the straight+right lane where both destinations turn (geometrically) right. This most probably cannot be interpreted correctly by any software.

Well, I just explained how to solve this algorithmically. That's why we have the lanes and turn:lanes tag. So that we don't have to guess.

[vshcherb]

@scaidermern you are technically right - https://www.openstreetmap.org/relation/5720844. There are 3 allowed roads, we will double check but it's probably some angles are hard coded and https://www.openstreetmap.org/way/110419891 is considered as only C not Turn Left possible.

[ivanPyrohivskyi]

In OsmAnd code turns that biggest than 45 degrees always are the left or the right. Full list of turns present in TurnType class.
After in getActiveTurnType a active lane is changing to main type of turn. In this issue we have turn in -45.56 degrees.
So enough to fix geometry of the intersection for fix this issue.

I am also viewed this intersection in Google Street View and can see more "straight" geometry.

Instruction with new geometry TL|TL|+C,TR (+C mean active straight on):

[ivanPyrohivskyi]

Osm file:
right_turn.osm.zip

[scaidermern]

Can you explain why OsmAnd "guesses" the turn instruction although it could use the lanes and turn:lanes tags to choose the correct one?

[ivanPyrohivskyi]

Can you explain why OsmAnd "guesses" the turn instruction although it could use the lanes and turn:lanes tags to choose the correct one?

These are other 91 cases why OsmAnd "guesses" the turn instruction. Fo example turn:lanes=none|through|right where "none" can mean straight on and left turn.
Where in case 67 turn:lanes=through|through|through;right meant active turn slightly right instruction and right inactive.

The users are edit map as is. So OsmAnd need some strict internal rules for turn lanes for make "gold" solution. The 45 degree is on of them.

[vshcherb]

@scaidermern https://github.com/osmandapp/OsmAnd/pull/new/fix_16752

[scaidermern]

@scaidermern https://github.com/osmandapp/OsmAnd/pull/new/fix_16752

I can't really review this change but great to know that there is a possible fix! :)

[vshcherb]

Possible fix of the problem first commit: #21190
Failing tests.
Test 62: 5384d66 - Fix but requires introducing None type which is needed long time ago
Test 79.2: Incorrect mapping https://www.openstreetmap.org/way/1049870350 as it allows to turn right but states turn:lanes=left|through|through|through - #19343
Test 50. Fix provided #12933
Test 32. Test could be adjusted instead <[[MUTE] C:TL|TL|+]C,TR> but was:<[KL:TL|+TL|]C,TR>

---

So in the end it's test 79.2 which conflicts with current change. Or geometry could be changed here

---

To do / to think:

• Disable or find alternative solution for 79.2 test
• Proper Introduce TurnType.None - on UI for example and in other places
• Looks buggy and weird why hasAllowedLanes works only with TurnType.getPrimaryTurn

if (hasAllowedLanes(oldTurnType.getValue(), oneActiveLane, 0, 0)) {
					tp = TurnType.getPrimaryTurn(lanes[k]);
				}