Discussion on special cases for "turn instruction"

[EssBee59]

Hello, I found a situation where the generated turn instructions are not optimal in my opinion:

When after a junction the selected "goodWay" runs parallel to the "lowerBadWay" or the "higherBadWay", then the generated turn instruction is at least confusing, some times in error.

The corresponding use case is, a cycleway (or a track or a path) is defined in OSM parallel to an highway and the Brouter selects this cycleway for routing after the junction. In this case, the lowerBadWay or the lowerHighWay angles are "near" the goodWay angle, AND they have negativ influence on the generated turn instruction...

Some examples:

"Light right" is generated, I think "right" should be better

http://brouter.de/brouter-web/#map=17/49.96194/8.54830/osm-mapnik-german_style&lonlats=8.552599,49.961436;8.54863,49.963679

"straight" is generated, error as "left" were ok http://brouter.de/brouter-web/#map=17/49.96201/8.54664/osm-mapnik-german_style&lonlats=8.553114,49.961228;8.545538,49.961214

"slight right" is generated, form me right should be better http://brouter.de/brouter-web/#map=15/50.0068/8.6896/osm-mapnik-german_style&lonlats=8.690077,50.005228;8.689133,50.008756

I tested a modified Brouter version (where BadWay´s are not considered for the generation turn instuction, when their angle difference to the goodWay is < 15 degre), the results are "as expected" for me.

Discussion: Is what I expect right for you? Is the use case frequency high enough to think about a change?

[afischerdev]

@EssBee59 Thanks for the new Sources. Works for me for this sample.

But I found the opposite: bad way link right And please have a look on the other way. When we not catch it we become a 'C' = straight for this voice hint. I would expect 'keep right' here. Straight means for me in this situation: follow the main road.

So we have four test samples for highway 16.24952,47.785458;16.269679,47.794653&profile=car-fast 16.24952,47.785458;16.259763,47.796841&profile=car-fast 4.407956,51.192656;4.410936,51.19255&profile=car-fast 4.407956,51.192656;4.410936,51.192409&profile=car-fast

I made small changes on your code to get both sides and with the new voicehint.java we become pretty good results.

[afischerdev]

@EssBee59 Thanks for the report of this error. Double points should be removed. That was the plan. I'll have a look.

[EssBee59]

I do not follow.. "the other way" example is running by me (KR) "the bad way link right" is also running as in that case NO voiceHint should be generated (standard case, you do not expect a voicehint at each unused EXIT?)

[afischerdev]

@EssBee59 I agree, the standard is no voice hint on unused exits. But in these both cases the main road moves a little bit and the idea was to announce this by voice hint because the exits are in the straight direction.

[EssBee59]

But in these both cases the main road moves a little bit and the idea was to announce this by voice hint because the exits are in the straight direction.

Did you find a well working solution to this?

Yes, I had the same thougt, but on motorway / trunk, the driver has normaly to remain on the left lanes (by right driving). Only few exceptions to this rule exist, and this is the case above (trunk_link left!) (the angles slef are not important for the voicehint)

a further example:

map=15/48.6344/8.9162/osm-mapnik-german_style&lonlats=8.913517,48.625535;8.932242,48.64136&profile=car-fast

KR expected

/#map=15/48.6344/8.9162/osm-mapnik-german_style&lonlats=8.913517,48.625535;8.917053,48.638797&profile=car-fast TSLL expected

[afischerdev]

@EssBee59 Thanks for the new samples. On the first I have a different opinion: the main way goes straight on, so I would expect nothing. Only when you leave main way.

I'm away for a while now - outdoor testing. So please let us go on with discussion later on.

[EssBee59]

Hello! I come back from a 500km bike-tour with more experience on turn-instructions: I suggest to change the angle for TR / TL, as 70 degre is too high, I think 60 degre is much better!

2 lines in VoiceHint.java are affected: (new version is) if (cmdAngle > 110. ) {cmd = TSHR;} else if (cmdAngle < 60. ) {cmd = TSLR;} else {cmd = TR;} and if (cmdAngle < - 110. ) {cmd = TSHL;} else if (cmdAngle > -60. ) {cmd = TSLL;} else {cmd = TL;}

I also attach the new source Regards

VoiceHint.java.txt

[afischerdev]

For a discussion What is straight vs. keep right/left?

Three samples coming up as keep right looking more straight (all angles between 5 and 21): https://brouter.de/brouter-web/#map=16/51.0531/4.0038/osm-mapnik-german_style&lonlats=3.998143,51.056641;3.996104,51.053793 https://brouter.de/brouter-web/#map=19/51.06015/4.01277/osm-mapnik-german_style&lonlats=4.013577,51.060269;4.012231,51.060832 4.02194,51.054883;4.01988,51.057232

What do you think?

[poutnikl]

IMHO, straight means a road going more or less straight, without a risk confusing other roads as straight, going sharp/normal slight left/right.

Keep right/left does NOT mean slight turn right/left wrt the original direction, but relative direction of 2 roads of similar direction within the catching range, both going about straight. In reality – especially if mapped incorrectly or if changing direction near the crossing – both can go slightly left or right, or either of them being more straight than the other l.

Edit:In a way, Keep right/left = follow the right/left roadside.

[EssBee59]

I agrre with poutnikl!

==>see the current voiceHint for angles between -5 and +5 degre else if (cmdAngle < 5.f) { if (lowerBadWayAngle > -30. ) {cmd = KR;} else if ( higherBadWayAngle < 30. ) {cmd = KL;} else {cmd = C;}

[poutnikl]

P. S.: In a way, keep left/right is more general solution to turn slightly left/right as it fits more real situations. E.g. it bypasses confusions which of roads is the straight one, or where is the road to which I am supposed to turn slightly left??

[EssBee59]

I like to discuss the following use cases: good angle between 5 and 21 degre, no road with similar direction: The current turn instruction is "KR", but I think, this instruction can / should be replaced with "C" (no instruction) (similar logic with negativ angles)

This is the result of my bike-travels in the summer, if you agree, I put a new version below Regards VoiceHint.java.txt

[poutnikl]

KR = "keep right" in sense "keep the right roadside" would still make sense, as C could lead to confusion.

It is kind of universal solution of 2 road alternatives with unclear of confusing geometry, even if it is not typical 2 near straight road scenario.

[afischerdev]

@EssBee59 Thanks for the new source. I had a test and it produces all samples well. But I have an extra sample: https://brouter.de/brouter-web/#map=17/51.05943/4.00977/osm-mapnik-german_style&lonlats=4.01121,51.060821;4.006617,51.060361 This need a voice hint - I think - but it fails.

For now I moved back to the current source in main repository. Please see here. It is very simple and with the post check for KL/KR in VoiceHintProcessor.

What do you think? If alright I make a new update.

@poutnikl Yes, you are right. When cycling/hiking most time, lanes are not in focus. Do you have a sample for this, where we can work on?

[poutnikl]

@afischerdev I have not thought about lanes. I mean literal roadsides as road boundaries, following them optically, mentally pushing yourself toward left/right, along the proper trajectory within the roads.

KR/KL is IMHO just accidentally applicable to lanes, leaving via more right/left road. and to do so, keeping yourself accidentally also at the right/left lane.

[EssBee59]

Thanks for the new source. I had a test and it produces all samples well. But I have an extra sample:

Sorry for my "quick & durty change": Yes, you are absolutly right! The test on "badwayangle" in the version I sent previously was 15 degre, this was definitly too low... I would replace with a value > 30 degre, 45 as example!

(see new version with a "KR" when a badway exist on both sides) Regards

VoiceHint.java.txt

A new test case: #map=18/49.95903/8.50769/osm-mapnik-german_style&lonlats=8.508691,49.958077;8.505431,49.959763 with the new version KR is generated, I think it is the best command?

[afischerdev]

@EssBee59 Thanks for the new source. I'll add this.

But with the new sample I got a straight as result and that is suppressed. turnangle 18.398657 lowerBadWayAngle-33.23833 higherBadWayAngle54.347702

@poutnikl Ok, I understand

[EssBee59]

With the last last version (see above) I get: goodAngle=18.398657 higherBadWayAngle=54.347702 lowerBadWayAngle-33.23833 cmd=9 KR

(using an own MTB profile!)

[poutnikl]

P.S.: Voice hints often use for KR/KL the explicit lane context like "Stay in the left/right lane", what sounds very funny when being applied to a trail fork in a forest or mountains. KR/KL is generally applicable to trails as well as to laned motorroads.

[afischerdev]

@EssBee59 Hm, same angles but different results.

my test scenario: last 1.6.4 lib from avoid-peaks branch git clone -b avoid-peaks https://github.com/afischerdev/brouter.git brouter-test compile in brouter-test gradlew build 1.6.4 jar file is found in ../brouter-server/build/libs

With this jar I get a cmd=9 KR as well But when I use your last VoiceHint.java with it I get the suppressed C.

[EssBee59]

Hello, I suspect you are using an intermediate version... (sorry for that, I changed many times the code, first the angle then I added a new line..)

see ... else if (cmdAngle < -5.f) { if (lowerBadWayAngle < -100. && higherBadWayAngle < 45.) {cmd = TSLL;} else if (lowerBadWayAngle >= -100. && higherBadWayAngle < 45.) {cmd = KL;} // 26.09.2022 else {cmd = KL;} else {cmd = C;} // change EssBee

VoiceHint.java.txt

KR in that case is possibly not the best choice, but it is important for me to generate something when the situation is not simple. Turn instruction means, the navi-app will turn automatically the display ON as example 120 meters ahead, and this is what I need ...

[afischerdev]

@EssBee59 That was it. All my current samples are looking well I will do the update.

Turn instruction means, the navi-app will turn automatically the display ON as example 120 meters ahead, and this is what I need

Interesting feature, thanks for sharing it. I go with display always on but this means only around 50/60 km tours.

[EssBee59]

Interesting feature, thanks for sharing it. I go with display always on but this means only around 50/60 km tours.

I am using this option (display on/off for 10-15 seconds) with Osmand, by long travels (> 130 km) I additionally set "flying mode". With both options no problems till 170 km I am using this option (display on/off for 10-15 seconds) with Osmand, by long travels (> 130 km) I additionally set "flying mode". With both options no problems till 170 km

As explained, a perfect logic for turn instructions is necessary: -no unnecessary instructions (a flow of instruction is ennoying and cost batterie) -necessary instructions are used to reactivate the display for N seconds. In Osmand I can set the first announcement time (short / midle / late) ahead of the junction. This allows by need to have a look on the map/display

[poutnikl]

Aside of the flying mode, I use just voice commands, to safe battery and not to be distracted. Additionally, it is no fun to check the display under the direct Sun. I occasionally check map just in case of doubts or other interest.

[afischerdev]

@EssBee59 @poutnikl Thanks for the additional infos on that feature.

[EssBee59]

I occasionally check map just in case of doubts or other interest.

very good formulation! using the Brouter "voice hints" the cases of doubts are limited to special situations (many roads at a junction).

[afischerdev]

@EssBee59 Great. I'll add this when I'm back. But it will take a while - mid September.