Strange turn instructions?

[devemux86]

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

• BRouter (offline) turn instruction improvements devemux86/cruiser#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]

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]

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]

@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.

1. 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).
2. 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]

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]

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]

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:
<!-- track-length = 59670 filtered ascend = 137 plain-ascend = -22 cost=61418 energy=.3kwh time=2h 57m 46s -->
The tests were carried out on around 60 different routes, which were compiled here from the discussions.

[EssBee59]

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: <!-- track-length = 59670 filtered ascend = 137 plain-ascend = -22 cost=61418 energy=.3kwh time=2h 57m 46s --> 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 <#723 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL75PSEWG7JTFXJQ6G6OPEDZU32FXAVCNFSM6AAAAABMVGRPP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRYHAYDMMJQGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[afischerdev]

@EssBee59
Test server runs with this library.

[EssBee59]

Hello!

Sorry to answer very late, now I found time to start a small regression test:

My test:

a-The current routing
https://brouter.de/brouter-web/#map=15/49.8758/8.3952/osm-mapnik-german_style&lonlats=8.378153,49.872566;8.392697,49.879121&profile=racebike-verylowtraffic

(turn instructions are generated with Osmand type)
==> see brouter-web.gpx
brouter-web.gpx.txt

b-test on the test-instance (using the same profile as above)
https://brouter.de/brouter-test/#map=15/49.8758/8.3952/osm-mapnik-german_style&lonlats=8.378153,49.872566;8.392697,49.879121&profile=racebike-verylowtraffic

(turn instructions are generated with Osmand type)
==> brouter-test.gpx
brouter-test.gpx.txt

My first remark:

• On the test instance, much more turn instructions are generated as currently in production, it seems the test-instance do not consider the "priority-classifier" as defined in the profile?
  (See points B, C, D)

To start further tests I prefered to get the same behaviour on test and production

regards

[afischerdev]

@EssBee59
Thanks for the nice sample
It has problems with angle calculation. This is changed back in #726

The test server has the new lib already.

[afischerdev]

Closed with PR #726. Feel free to reopen when there are still issues.