Route loops left and U-turns, should bear right

[lunkhub]

Describe the routing engine used (required)

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

Describe your routing Profile (required)

Car, fuel-efficient, no toll-roads, no motorways.

Describe your start and end points (required)

Example, approximate
Start: 35.39894, -80.60776
End: 35.40181, -80.60878
Can start farther south, and end farther north.

Describe the actual route (required)

Says turn left then U-turn.

Describe the expected route (required)

Should slight turn right or bear to right or almost stay straight, not turn left and U-turn.

Describe what Maps you used (online or offline) (required)

• Offline maps offered within the OsmAnd app for download. North Carolina USA June 1, 2024, or previous, with weekly updates
• Online (tile / raster) maps

Your Environment (required)

OsmAnd Version: 4.7.17 from F-Droid Main
Android/iOS version: 14 (CalyxOS)
Device model: Pixel 6a

Anything else? (optional)

Looked at openstreet map, but did not find error to correct.

[yuriiurshuliak]

The bug has been reproduced. To reproduce it, follow these steps:

• Build the navigation route using the provided coordinates with the fuel-efficient option disabled.
• Then, enable the fuel-efficient option and build the route again.

When the fuel-efficient option is enabled, the resulting route includes a detour.

You can view the example here: web version link

The fuel-efficient way option is disabled	The fuel-efficient way option is enabled

[0709wiwiwi]

Strange is that even the graphHopper router as shown in openstreet results in the same yet very weird route result.
https://www.openstreetmap.org/directions?engine=graphhopper_car&route=35.39872%2C-80.60771%3B35.40399%2C-80.60951#map=17/35.40136/-80.60861

This could possibly be optimised ? This by tagging the highway junction as well as the next merge in osm as: Tag:highway=motorway_junction
A local osm mapper should eventually perform this and after the routing data is updated then check this result again.

https://www.openstreetmap.org/edit#map=17/35.39977/-80.60772
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway_junction
https://wiki.openstreetmap.org/wiki/Key:highway#Link_roads

[lunkhub]

This could possibly be optimised ? This by tagging the highway junction as well as the next merge in osm as: Tag:highway=motorway_junction
A local osm mapper should eventually perform this and after the routing data is updated then check this result again.

Suggested map change has been made. After waiting and map live update, no change in routing is seen.

[0709wiwiwi]

Patience.
The data of the route service providers is not immediately updated. It can take a few days before an osm change has effect.

If you don't know the ‘sensitivity’ of the router engines, it is better not to change everything around a problem zone all at once but to test with smaller changes (truthfully). This way, you can notice what has the right effect and later on, in case of similar problems, you can then also recognise this more quickly. Routing sometimes points you to osm problems that would otherwise remain hidden. Osm edits should always be and remain very truthful of course.

Strange, through the online GH router without motorways restriction, the result is strangely idem.

Through the GH router, you can enforce this connection by an extra Via point but that is obviously not the desired solution.
https://graphhopper.com/maps/?point=35.398776%2C-80.607718&point=35.400061%2C-80.608163&point=35.40181%2C-80.60878_35.40181%2C+-80.60878&profile=car&layer=Omniscale

[vshcherb]

We need to retest after results changed

[0709wiwiwi]

As for GraphHopper, I checked this out in the GH forum.

https://discuss.graphhopper.com/t/strange-routing-result/8736

https://www.google.com/maps/@35.3990386,-80.607798,3a,37.5y,344.5h,87.59t/am=t/data=!3m7!1e1!3m5!1sgyxdm46VSEtv9lprRGxRig!2e0!6shttps:%2F%2Fstreetviewpixels-pa.googleapis.com%2Fv1%2Fthumbnail%3Fpanoid%3Dgyxdm46VSEtv9lprRGxRig%26cb_client%3Dmaps_sv.share%26w%3D900%26h%3D600%26yaw%3D344.49953254796486%26pitch%3D2.4148570659140205%26thumbfov%3D90!7i16384!8i8192?coh=205410&entry=ttu