search

osmandapp / OsmAnd

OsmAnd
https://osmand.net
Other
4.66k stars 1.02k forks source link

Turn instructions show turn right instead of straight on #21055

Open scaidermern opened 2 weeks ago

scaidermern commented 2 weeks ago

Routing engine

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)

Your Environment

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

Anything else?

No response

scaidermern commented 2 weeks ago

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 commented 1 week ago

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 commented 1 week ago

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: image

This would also make left turn really left.

scaidermern commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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.

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

vmicho commented 1 week ago

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 commented 1 week ago

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 commented 3 days ago

@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 commented 1 day ago

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 commented 1 day ago

Osm file: right_turn.osm.zip

scaidermern commented 1 day ago

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 commented 1 day ago

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 commented 1 day ago

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

scaidermern commented 1 day ago

@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 commented 1 day ago

Possible fix of the problem first commit: https://github.com/osmandapp/OsmAnd/pull/21190 Failing tests. Test 62: 5384d66bf0e54b91fdb3412aafd551c2a6112d38 - 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 - https://github.com/osmandapp/OsmAnd/issues/19343 Test 50. Fix provided https://github.com/osmandapp/OsmAnd/issues/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: