Strange turn instructions?

devemux86 commented 3 weeks ago

There is a report in Cruiser forum about wrong turn instructions by BRouter app with car profile:

https://github.com/devemux86/cruiser/discussions/622

Slight turn right instead of sharp turn right in image 1 with BRouter link.

Unnecessary (?) keep right in image 2 with BRouter link.

poutnikl commented 3 weeks ago

Turn Slight Right

I assume one of possible reasons may be that the reported light turn may be result of assigning the big portion of turning to arriving and departing roads, not to the crossing, especially if too small value of turnInstructionCatchingRange (default 40 m) is used, or if the crossing size overflows that value.

This is a danger of small turnInstructionCatchingRange values. The opposite, big values, may cause confusion if there is tight sequence of turns, possibly evaluated as just a single, summary turn. So turn left+right can be eveluated as go straight ahead, or tight left+right+left could be seen just as left. So the optimal turnInstructionCatchingRange is a kind of trade off.

Another factor is OSM mapping does not allow round road segment, which are emulating of series of short straight segments. If not all those segments are evaluates within turnInstructionCatchingRange, BRouter may evaluate the crossing turning angle smaller than it is.

For the Keep Right, it would be OK if all the road segments had the same priority classifier.

EssBee59 commented 3 weeks ago

I think, the turn instruction is not really wrong, the situation have to be considered: -The Brouter do not generate any turn instruction untill the point "Middle" is reached, as the first "right turn" of nearly 90 degre is by following the road. -Now, from this point a kind of "smooth" right turn is coming.

afischerdev commented 3 weeks ago

@devemux86 Thanks for the nice samples.

I could do a small research for this and I think at the moment both are 'errors' and should be reworked.

Slight right: We have an angle collector but this is limited by a contant value of 2m. In this case not very useful. When using a limit of 40m a result of 'turn right' is delivered. But this has be to checked against other rules (e.g. roundabouts).
Keep right: The error is in the variable hasSomethingMoreStraight, it is checked against minAbsAngeRaw but this is not always filled, so when I check this the expected result of 'no turn instruction' is delivered.

I can do more on this next week and will be back here.

afischerdev commented 1 week ago

Well, it is not as easy as I thought on the first view. I started with the second point - unnecessary keep right - and added a check for the hasSomethingMoreStraight variable. This removes some unneeded KL and KR but it also drops other things. So I had to change and add other rules:

no voicehint on a bad oneway (P669 is removed now)
no voicehint when badway coming from the back (P117 is removed now)

The first point - turn slight right: I reactivated the sumNonConsumedWithinCatchingRange routine with a small value of 10m (the 40m catching range produces to much errors). This works well for the announced problem but has some smaller side effects.

Point 90 was a right one now it works as a slight right.
Point 795 was a straight voicehint (and therefore was removed) now it is a slight left

Here are some files for comparison that contain most of the changes: testtrack0.trekking.1,7,7.gpx.txt testtrack0.trekking.723.gpx.txt

EssBee59 commented 1 week ago

Hello!, Great analysis and work afischerdev, and thank for your tests that show the complexity of turn announcements and will avoid suboptimal changes! At this place it would be interesting to get the exact expectation of the creator of this issue: "strange TU" do not really describe the expected behaviour? (for cruisers turn instructions based on the geometry could also be of interest. Many navi-app do so generally when the navigation has to follow a simple gpx -without turn inst-)

Open : Wich difference should remain between a real/normal turn and the "smooth" (long radius) turn in image 1? (both TL ?)

Is a change intended only for cars or also for bikers? (As explained above, for bike I prefered to keep "Turn slight right" in image 1) Will the change impact the turn costs?

afischerdev commented 1 week ago

Is a change intended only for cars or also for bikers? (As explained above, for bike I prefered to keep "Turn slight right" in image 1)

The change goes for all profiles. Angles are collected in the range of 10m

Will the change impact the turn costs?

I did an extra test, collected all comment lines and compared. They are equal to the current 1.7.7 version. Like:  The tests were carried out on around 60 different routes, which were compiled here from the discussions.

EssBee59 commented 1 week ago

Thank for the explanations and tests! If you can install the changes in the test-instance, it would be great Regard

afischerdev @.***> schrieb am Mi., 4. Sept. 2024, 14:11:

Is a change intended only for cars or also for bikers? (As explained above, for bike I prefered to keep "Turn slight right" in image 1)

The change goes for all profiles. Angles are collected in the range of 10m

Will the change impact the turn costs?

I did an extra test, collected all comment lines and compared. They are equal to the current 1.7.7 version. Like:

The tests were carried out on around 60 different routes, which were compiled here from the discussions.

— Reply to this email directly, view it on GitHub https://github.com/abrensch/brouter/issues/723#issuecomment-2328806104, or unsubscribe https://github.com/notifications/unsubscribe-auth/AL75PSEWG7JTFXJQ6G6OPEDZU32FXAVCNFSM6AAAAABMVGRPP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRYHAYDMMJQGQ . You are receiving this because you commented.Message ID: @.***>

afischerdev commented 1 week ago

@EssBee59 Test server runs with this library.

abrensch / brouter

Strange turn instructions? #723