EssBee59 commented 2 years ago

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 commented 2 years ago

Great investigation. And yes, I would like to see a change.

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.

Where did you place it?

EssBee59 commented 2 years ago

I only work / modify on local installation, so I attache the modified programm regards VoiceHint.java.txt

vodie commented 2 years ago

A pull request can be done in the web browser, just go to the file you want to change: https://github.com/abrensch/brouter/blob/master/brouter-core/src/main/java/btools/router/VoiceHint.java There you can find a button to edit the file. This will create with a few clicks your fork on github where you can edit the file (or upload your changed text) and then make a pull request.

EssBee59 commented 2 years ago

Vodie,

Thank you very much for your help, I will try to learn / use github ASAP. But my code is just good enough to build a prototype and start some tests; Is it ok to put such a pull request now in this state?

(BTW, all tests I started were sucessfull)

vodie commented 2 years ago

A pull request can be changed or corrected if needed or the maintainer can do changes.

afischerdev commented 2 years ago

Please give some more time for testing. The 3rd sample is still 'slight right' for me.

EssBee59 commented 2 years ago

I agree, the 3rd example is ok!

It seems, the wrong "straight" turn instruction is most generated, here some new examples: Straight vs. left http://brouter.de/brouter-web/#map=17/50.00620/8.68836/osm-mapnik-german_style&lonlats=8.688877,50.004126;8.68731,50.006374

http://brouter.de/brouter-web/#map=15/49.8379/8.5658/osm-mapnik-german_style&lonlats=8.562856,49.84551;8.561697,49.837069

http://brouter.de/brouter-web/#map=16/49.9284/8.5748/osm-mapnik-german_style&lonlats=8.570409,49.928116;8.567232,49.929815

Sharp right vs. right http://brouter.de/brouter-web/#map=15/49.8452/8.5643/osm-mapnik-german_style&lonlats=8.551483,49.84432;8.560667,49.840306

straight vs. Left http://brouter.de/brouter-web/#map=15/49.8140/8.5768/osm-mapnik-german_style&lonlats=8.565989,49.81545;8.569727,49.81849

straight vs. Right http://brouter.de/brouter-web/#map=16/49.9286/8.5716/osm-mapnik-german_style&lonlats=8.570409,49.928116;8.573285,49.929534

I think, the "straight" instruction is due to this programm statement: (but not really sure)

if ( lowerBadWayAngle > angle || higherBadWayAngle < angle )

and this change solves the problem:

if ( lowerBadWayAngle > (angle +1) || higherBadWayAngle < (angle -1)  )

afischerdev commented 2 years ago

@EssBee59 Great collection of tests and a lot of variants.

But only the first two samples work in new way. All others carry the old wrong direction.

What do you think? Should we normalize our testing equipment a bit?

Download rd5 from 18.12.2021
brouter-1.6.2-all.jar from ZIP file (see Action tab) last generation f0853ad 18.11.
And your VoiceHint.java (I add a println to see on output that your class is used)

Just not to give other problems a chance.

EssBee59 commented 2 years ago

Hello, normalization is a good idea (I had problems/errors with the rd5 files from 16.12 on my local instance..have to clarify this)

But the real problem seems, the situations are really complex... I tested again case 5 and discovered that the result was ok using my profile (turnInstructionCatchingRange=8) and remains in error with turnInstructionCatchingRange=40

So, I think I need more time for analysis...

To come back to the first important change ( if ( lowerBadWayAngle > (angle +1) || higherBadWayAngle < (angle -1) ): This is a fast (possibly dirty?) change, but it corresponds to the situation: A "badWay" is parallel to the goodWay, this only indicates that the angles are very very near... BUT not exactly EQUAL ... As example in this special case, lowerBadWay could be "a little bit" higher as goodWay. Any idea for a better change to consider this sitaution?

afischerdev commented 2 years ago

@EssBee59 thanks for the update

turnInstructionCatchingRange=8

Does the trick for me as well.

So, I think I need more time for analysis...

Yes I think we do.

Any idea for a better change to consider this sitaution?

No, nothing yet, but we have a lot of samples, that's fine and will help to find a way. Only thing I notice is we have e.g. the 'straight' command before the 'good' left.

EssBee59 commented 2 years ago

Hello,

I had again a look at the example above showing the impact of "turnInstructionCatchingRange": I think now, the catching leads to the wrong turn instructions... As the angles are added by catching, the new angle becomes "inconsistent"... but I think only apparently?

I prepared a new version which works in any of my test-cases, I also started regression-tests and found no problem.

My new tests-cases:

slight right vs. right 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 vs, left http://brouter.de/brouter-web/#map=17/49.96201/8.54664/osm-mapnik-german_style&lonlats=8.553114,49.961228;8.545538,49.961214

http://brouter.de/brouter-web/#map=17/50.00620/8.68836/osm-mapnik-german_style&lonlats=8.688877,50.004126;8.68731,50.006374 http://brouter.de/brouter-web/#map=15/49.8379/8.5658/osm-mapnik-german_style&lonlats=8.562856,49.84551;8.561697,49.837069 http://brouter.de/brouter-web/#map=16/49.9284/8.5748/osm-mapnik-german_style&lonlats=8.570409,49.928116;8.567232,49.929815

http://brouter.de/brouter-web/#map=15/49.8140/8.5768/osm-mapnik-german_style&lonlats=8.565989,49.81545;8.569727,49.81849 straight vs. right http://brouter.de/brouter-web/#map=16/49.9286/8.5716/osm-mapnik-german_style&lonlats=8.570409,49.928116;8.573285,49.929534

The frequency of the error is low, so a change is not urgent and we have time for a change and the tests

VoiceHint_1912.java.txt

afischerdev commented 2 years ago

@EssBee59

The frequency of the error is low, so a change is not urgent and we have time for a change and the tests

Yes, I think we go with this into the next version.

The new tests run with better results. But one interesting thing, the new voice hint went one step back (where the straight hint was before).

EssBee59 commented 2 years ago

Hello, I learned a lot by trying to solve the encountered problems and came to the following decision: From now, I will use "turnInstructionCatingRange=4 in my bike-profiles (I used 8 till yesterday)!

As explained, I could make a change which leads to acceptable results in most of the test-cases (described above)
But I found new test-cases where the result are not perfect / not right, and I think, there is no generic perfect solution for covering the catching of turn instruction.

http://brouter.de/brouter-web/#map=18/49.96703/8.52864/osm-mapnik-german_style&lonlats=8.52751,49.967322;8.526448,49.966735

http://brouter.de/brouter-web/#map=17/49.94395/8.45576/osm-mapnik-german_style&lonlats=8.453636,49.944666;8.452627,49.943713

http://brouter.de/brouter-web/#map=17/49.97611/8.55776/osm-mapnik-german_style&lonlats=8.556312,49.976603;8.557975,49.976527

My last test programm: (a test / debug version!)

VoiceHint_2112.java.txt

By changing as example the Catching range from 40 to 4, only 1 or 2 % additional turn instructions are generated and the quality of the instructions is much better! (you should compare the intructions on the test-cases by using 40 and 4 meters)

If you want to get all the right turn instructions (as I expect on tour) I recommend to reduce this "Catching" parameter in every bike-profile! (using "turnInstructionCatchingRange=4", no change is necessary in the code, only the profiles have to be modified)

(Feel free to close this issue )

afischerdev commented 2 years ago

The last days we have made control sessions around the command calculation in VoiceHint. I'd like to bring the focus to the whole generation of the voice hints. I made some additional outputs and test it with the last test. Output like this:

hint 1: 3 0 unknown command: 0 188557198_139976742 dist=61 prio=6 turn=89.49981 | dist=35 prio=6 turn=-89.19807 1 r false
hint 1: 2 0 unknown command: 0 188557012_139976455 dist=35 prio=6 turn=-89.19807 | dist=44 prio=6 turn=0.019756308 2 r false
hint 1: 1 0 unknown command: 0 188556449_139976601 dist=44 prio=6 turn=0.019756308 | dist=10 prio=6 turn=0.0 1 r false
hint 1: 0 0 unknown command: 0 188556329_139976631 dist=10 prio=6 turn=0.0 | dist=0 prio=0 turn=0.0 0 r false
hint process 1: 3 9 KR 188557198_139976742 dist=61 prio=6 turn=89.49981 | dist=35 prio=6 turn=-89.19807 1 r false
hint process 1: 2 8 KL 188557012_139976455 dist=35 prio=6 turn=-89.19807 | dist=44 prio=6 turn=0.019756308 2 r false
hint process 1: 1 8 KL 188556449_139976601 dist=44 prio=6 turn=0.019756308 | dist=10 prio=6 turn=0.0 1 r false
hint process 2: 1 8 KL 188556449_139976601 dist=44 prio=6 turn=0.019756308 | dist=10 prio=6 turn=0.0 1 r false
hint process 2: 2 2 TL 188557012_139976455 dist=35 prio=6 turn=-89.19807 | dist=44 prio=6 turn=0.019756308 2 r false
hint process 2: 3 5 TR 188557198_139976742 dist=61 prio=6 turn=89.49981 | dist=35 prio=6 turn=-89.19807 1 r false
hint 2: 1 8 KL 188556449_139976601 dist=44 prio=6 turn=0.019756308 | dist=10 prio=6 turn=0.0 1  6(0)6 (36)6 r false
hint 2: 2 2 TL 188557012_139976455 dist=35 prio=6 turn=-89.19807 | dist=44 prio=6 turn=0.019756308 2  6(-88)6 (0)6 (91)6 r false
hint 2: 3 5 TR 188557198_139976742 dist=61 prio=6 turn=89.49981 | dist=35 prio=6 turn=-89.19807 1  6(89)6 (0)6 r false

You see the hint generation, first and second processing and the result. On first process you will notice the steps are backward and come with 'wrong commands'. This is replaced in step 2. All this is done with turnInstructionCatchingRange=2

When you shift to turnInstructionCatchingRange=40 you'll have back the wrong results as before.

What I think about it is we have two different tasks here (hint generation and reduce hint list size) and we mix them up - try to do it in one task. And this brings the wrong results.

What about start hint generation with hard coded 2 meters and do a post processing with catching range to reduce the list size? Or even better: we leave the problem of displaying to the clients that use BRouter.

I compared the idea with an other sample which has commands very near to each other.

hint process 1: 2 9 KR 188570275_139929995 dist=8 prio=6 turn=109.44071 | dist=10 prio=4 turn=1.7877675 2 r false
hint process 1: 1 1 C 188570277_139929907 dist=10 prio=4 turn=1.7877675 | dist=200 prio=4 turn=0.0 2 r false
hint process 2: 1 1 C 188570277_139929907 dist=10 prio=4 turn=1.7877675 | dist=200 prio=4 turn=0.0 2 r false
hint process 2: 2 5 TR 188570275_139929995 dist=8 prio=6 turn=109.44071 | dist=10 prio=4 turn=1.7877675 2 r false

The distance in the first sample was 35m, ok for displaying, but here we have only 8m. What the other do:

I made a branch on afischerdev/voicehint-problem to play with. The samples were generated with current version. But it also contains the EssBee59 VoiceHint variations. I spend a function public String getCommandString(int c) not the end in an exception when testing commands to early.

Happy testing.

EssBee59 commented 2 years ago

What about start hint generation with hard coded 2 meters and do a post processing with catching range to reduce the list size?

Good idea! In this special case, "C" could be as example eliminated if it is less than N meters before or after another turn instruction... But, is it really necessary to reduce the list size? I tested with 40 and 4 meters, 4 meters produces nearly 3% more instructions as 40 meters, and the "C" turn instructions are for me very helpfull: they tell me as example "not to turn" on the highway=secondary, but even 4 meters later on the cycleway / path / track. (Using Osmand I get spoken something like "in 50 meters "C" then after 4 meters turn left": the perfect voice guinde for me! And again in the turn place)

poutnikl commented 2 years ago

Have you tested it in LocusMap, with focus on possible confusion in case of spoken hint spatial/temporal delays? (systematic delays, not GNSS position errors)

There are cases the delay is comparable to subsequent junction distance, e.g. 30 m. It happens to me all the time that Locus says the crossroad is farther then it really is.

The reason may be they are said too late, respectively their generation may have too short leading time.

Perhaps when it starts saying it is 50m ahead it is 50m ahead, but when fifty is said it may be just 20.

EssBee59 commented 2 years ago

Hello poutnikl,

Thank for your help in this discussion, I did not know about the problem you described above!

I am only using Osmand and do not know LocusMap enough to start a test...sorry! I recorded under Osmand one of the test-cases above using tuninstructionCatchingRange=5 (old value of my MTB profile) and try to attach the mp4 here. The test-case: http://brouter.de/brouter-web/#map=17/50.00607/8.68762/osm-mapnik-german_style&lonlats=8.688805,50.004073;8.68848,50.005891

(In Osmand I configured the parameter "announcement time" to "early" in order to get the turn announced early / nearly 15 meters before the turn)

https://user-images.githubusercontent.com/50321352/147466290-b1668a34-3159-4cd8-a41b-f0d4b8c53722.mp4

I also recorded another situation showing the occuracy / perfect guiding of Brouter

https://user-images.githubusercontent.com/50321352/147466589-32314884-8131-4924-88db-453d2dd567d4.mp4

The problem you described is not clear for me: Is this a Locus problem? Or are the voice messages too long / announced too slowly? Or a message-queueing problem? Is your smartphone too slow (old)?

Can you start a short test with another navi-app?

As I think, the problem is not due to the Brouter turn instructions, it should be better to find a solution in the navi-app rather than building a work-arround in Brouter that introduces errors and decreases the occurray of the voice-guiding

poutnikl commented 2 years ago

I suppose it may be Locus specific voice hint timing problem, where it says it at wrong time = wrong place. I agree it is not Brouter problem, rather problem of implementation in target application. (I have relatively recent 8-core 6 GB RAM device ).

But there can be random cases of true location problem with bad GNSS signal.

I still think a larger catching range is a feature, not workaround, involving via the acoustic API the external biological neuronal AI with autonomous realtime visual sensors. :-)

afischerdev commented 2 years ago

I made an update on afischerdev/voicehint-problem. First I add a small check angle (5°) before keep left/right logic. Please see my favorite sample from EssBee59. Frist hint is dropped now. Voice process runs now on 2m catching range. Next I add a postProcess function to reduce list. At the moment it drops only hints going forward in an angle of 45° (22.5° each side). And it only checks for two voicehints in range, didn't found a samle with more points in one check range.

And it still has this problem sharp / turn right: http://brouter.de/brouter-web/#map=15/49.8452/8.5643/osm-mapnik-german_style&lonlats=8.551483,49.84432;8.560667,49.840306

EssBee59 commented 2 years ago

Hello afischerdev,

Great work! I made a build with your new code and restarted some tests:

Till now, No error found!!
List reduction is Ok, only the "C" instructions are eliminated!

Your example ( sharp right ) is for me ok, have a look at the "lowerBadWay" (17 degre), the allgorithm produces TSHR in this case!

sharp_right

So, this new version of "CatchingRange" is much better as the old version that was really not error free!!!!!!!

I think now, only the decision about the default value of turnInstrucrionCatchingRange could be discussed / observed: -a CatchingRange of 40 decreases a bit the occuracy of the voice guinding -But it seems to leads to problems when using LocusMap

For me, no problem as I am using own profiles. What is the best value for the mass of the users (who do not modify the standard profiles)?

I hope Poutnikl will find the cause of his voice problems, in order to be able to decrease the value in future. Anyway, the new version is a very good progress!

afischerdev commented 2 years ago

Good morning EssBee 59, many thanks for the testing. You did the way I would recommend. I like the command line with additional output. ;-) And you are able to rename e.g. VoiceHint to use one of your own tests, rebuild and see direct what it brings.

Anyway if you prefer an APK I build one from this new test version. BRouter_current contains signed apks (different key).

EssBee59 commented 2 years ago

Hello!

I think, we learned from this discussion.. that should be closed soon, as I do not await new facts. Just before closing it, liked to clarify what are the next steps:

@poutnikl the proposed implementation of "turnInstructionCatchingRange" differs a bit from the old version but it eliminates bugs: Is the new version ok for you ? (BTW, could you solved your problems using Locusmap ?)

@afischerdev Do you plan to use the new version in future release? The default value of turnInstructionCatchingRange is currently 40 meters, can it be decreased in biking profiles? Regards

afischerdev commented 2 years ago

I'm sorry for the delay. I'm still behind the corner problem in this sample

When I see the angles we use I think it diffs from that what the user would expect, a turn right should have a turn right sign:

angle

I changed the angles a little bit, the middle is still more present then the others. Not sure if it's better to use 45, 90, 135 angles - most clients do that I think. And I unabled the check on bad way angles. I think it could be a way to leave these problem to the client apps. We deliver all neaded info. You see original BRouter routing hint and display angle.

Griesheim_angle

I made the changes on git/voicehint-problem. The command line output has a marker when old version and simple version are different.

EssBee59 commented 2 years ago

Hello, Not sure I understood your change above: Within the BRouter a turn hint did not only depend on the turn angle, the lowerBadWay and higerBadWay impacts the instruction. As explained above, in the "sample" where you see a problem, a "lowerBadWay" with 17 degrees exist (See my gif above), and this leads to the new turn: without "lowerBadWay" the turn would be TR But, due to this "lowerBadWay" the turn (till last version) was changed to TSHR (sharp right)

As you write, the check on BadWay is now disabled...but in some cases, it was a very good help? I will try to deliver examples later

afischerdev commented 2 years ago

The intention is to ignore the bad way angles. Or we find samples where it is required to ask the badways for a correction.

In this sample it brings a sharp right vs turn right. On a sharp right you have to reduce your speed a little bit more than on a 90 degree right.

EssBee59 commented 2 years ago

Yes, it is difficult to find quickly the right example.... But I think these cases could be an example (not sure): http://brouter.de/brouter-web/#map=18/49.86994/8.57573/osm-mapnik-german_style&lonlats=8.575757,49.8705;8.576562,49.870241 http://brouter.de/brouter-web/#map=18/49.86994/8.57573/osm-mapnik-german_style&lonlats=8.575757,49.8705;8.576632,49.87002

Changing the angles as suggested is not the problem, I just like to dicuss the "check badWays" feature. I am not the author of the allgorithm using BadWays, but I think (beleaved) it is a good idea:

Consider this case (theoretical situation, I know it occurs not often): badLowerWay -181 goodWay -115 badHigherWay -70 In that case, if you do not check the badLowerWay and use the suggested new angles (between -60 and -120 degre, TL is generated), then TL is generated for the goodWay AND also if you selected the badLowerWay as route! ==> the turn instruction do not reach to find the way you want to follow ("sharp left" is, as in the current version, much better in that case!)

I agree, in the old logic the impact of the badWays is a bit TOO HIGH:

In your example above, TR is repaced with TSHR due to this instruction: else if ( lowerBadWayAngle > 15. && lowerBadWayAngle < 90. && higherBadWayAngle > 180. )

I agree, 15 is too low, but a check with a lowerBadWay value between 30 and 60 could/should remain? By using the new angles you suggested, I would just change it to something like this: else if ( lowerBadWayAngle > 30. && higherBadWayAngle > 180. )

I think, a similar minor change in the further checks could reach instead changing the programm logic?

afischerdev commented 2 years ago

Great samples, very helpful. In the first one I got this output

---->  angle -91.116585 cmd 3 TSLL / 2 TL
hint process 2: 1 3 TSLL 188575831_139869984 dist=58 prio=4 turn=-91.116585 | dist=58 prio=4 turn=0.0 4 r false
hint 2: 1 3 TSLL 188575831_139869984 dist=58 prio=4 turn=-91.116585 | dist=58 prio=4 turn=0.0 4  4(-90)4 (-115)4 (101)4 (6)4 (61)4 r false

It shows the different results of both ways ----> first is original, second is simple angle version. And its not the -115 degree angle as you expected in the second sample its a 90 degree angle and this is moved to a TSLL

Second sample has this output:

hint process 2: 1 2 TL 188575831_139869984 dist=60 prio=4 turn=-115.50209 | dist=58 prio=4 turn=0.0 4 r false
hint 2: 1 2 TL 188575831_139869984 dist=60 prio=4 turn=-115.50209 | dist=58 prio=4 turn=0.0 4  4(-115)4 (-90)4 (101)4 (6)4 (61)4 r false

It shows no different in old/new version. But this is what you expected: an angle of -115 could bring a TSHL instead of a TL.

I think in this both samples the output should go this way angle _2 1 - should bring TSHL, this is nearer on the angle border 2 - TL

May be we need 'moving' borders (ranges) on this samples .

Or a different logic in output like Turn left on first/second way But I guess we will not find many friend (apps) on that.

EssBee59 commented 2 years ago

Or a different logic in output like Turn left on first/second way But I guess we will not find many friend (apps) on that.

I agree, "news tipps" are not often welcomed (you know the spoke "don´t try to teach old dogs ...") I come back to the origin of your "problem sample" above and will consider the java-code (I think it is easier as discussing 1000 test-cases)

The problem (sharp right instead your preference for right) is due to this instruction in combination with a higherBadWay of 17 degre: else if ( lowerBadWayAngle > 15. && lowerBadWayAngle < 90. && higherBadWayAngle > 180. )

1-I suggest to change 15 with 30 2-further, I do not understand the condition "&& lowerBadWayAngle < 90." and eliminated it in my local Brouter-version 2 years ago... (I expect "sharp left" in this case: http://brouter.de/brouter-web/#map=18/49.86994/8.57573/osm-mapnik-german_style&lonlats=8.575778,49.870421;8.576465,49.870213

See the old "higherBadWayAngle > -90. " that I also eliminated to get "shapr left" instead "left" )

In other words, my "dream" voiceHint.java ist the following: VoiceHint.java.txt

As test-cases I suggest these ones: http://brouter.de/brouter-web/#map=18/49.86994/8.57573/osm-mapnik-german_style&lonlats=8.575778,49.870421;8.576465,49.870213 http://brouter.de/brouter-web/#map=18/49.86994/8.57573/osm-mapnik-german_style&lonlats=8.575778,49.870421;8.576637,49.870013 http://brouter.de/brouter-web/#map=18/49.86998/8.57579/osm-mapnik-german_style&lonlats=8.575778,49.870421;8.575806,49.869408 http://brouter.de/brouter-web/#map=18/49.86998/8.57579/osm-mapnik-german_style&lonlats=8.575778,49.870421;8.574931,49.869615 http://brouter.de/brouter-web/#map=18/49.86998/8.57579/osm-mapnik-german_style&lonlats=8.575778,49.870421;8.574706,49.870072

Note: As in your "calcSimpleCommand" I introduces new KR and KL, and this generates nearly 15% more turn instructions... (to be discussed if necessary)

Regards

afischerdev commented 2 years ago

Good idea with the test cases. I collected it like this clockwise

Sample 1 (-115°) - BRouter alt: TL - Expected: TSHL --- BR-Web --- graphhopper - TSHL --- OSRM - TSHL
Sample 2 (-91°) - BRouter alt: TSLL - Expected: ??? --- BR-Web --- graphhopper - TL --- OSRM - TL
Sample 3 (5°) - BRouter alt: no hint - Expected: ??? --- BR-Web --- graphhopper - no hint --- OSRM - no hint
Sample 4 (61°) - BRouter alt: TR - Expected: ??? --- BR-Web --- graphhopper - TR --- OSRM - TSLR
Sample 5 (101°) - BRouter alt: TSHR - Expected: ??? --- BR-Web-- - graphhopper - TR --- OSRM - TR

We should define what we expect.

What can a client app do when it works with routing hints?

Use the angle and draw it, but the voice hint must still normalized or
Use a pointer set like this one. This is based on a 45 degree rule and I think user would expect angles in this range

I made a 45 degree pic angle _3

But this ignores the KL/KR 'directions'. Or is it better to ignore and use it only for highways with more lanes when an exit is near?

@EssBee59 I have to add you new voicehint, coming soon.

EssBee59 commented 2 years ago

I expect the following "cmd" results ("cmmd" would be the results of the logic you suggested above some days ago)

Test sample 1 goodAngle=-115.50209 higherBadWayAngle=-91.116585 lowerBadWayAngle-181.0 cmd=4 TSHL cmmd=2 TL

Test sample 2 goodAngle=-91.116585 higherBadWayAngle=5.7096133 lowerBadWayAngle-115.50209 cmd=2 TL cmmd=2 TL

Test sample 3 goodAngle=5.7096133 higherBadWayAngle=61.345135 lowerBadWayAngle-91.116585 cmd=9 KR (OPTIONAL!!!) cmmd=9 KR

Test sample 4 goodAngle=61.345135 higherBadWayAngle=101.18727 lowerBadWayAngle5.7096133 cmd=6 TSLR cmmd=5 TR

Test sample 5 goodAngle=101.18727 higherBadWayAngle=181.0 lowerBadWayAngle61.345135 cmd=7 TSHR cmmd=5 TR

I think, without checking the "BadWay" angles, the result is not acheavable? Here the last programm I used to get these results: VoiceHint_1301.java.txt

(A light change in the angles I am using should be ok)

And some new samples.. I think the best illustration of the advantage offered by the „BadWay“ checks! Sample 6 ../#map=16/50.0053/8.5445/osm-mapnik-german_style&lonlats=8.543114,50.005023;8.539617,50.005767 TSLL

Sample 7 ../#map=16/50.0053/8.5445/osm-mapnik-german_style&lonlats=8.543114,50.005023;8.539724,50.006346 TSHL

Sample 8 ../#map=16/50.0053/8.5445/osm-mapnik-german_style&lonlats=8.54217,50.007655;8.539703,50.005767 TSLR

Sample 9 ../#map=16/50.0053/8.5445/osm-mapnik-german_style&lonlats=8.54217,50.007655;8.539639,50.006374 TSHR

afischerdev commented 2 years ago

@EssBee59 Add your last update to git voicehint-problem.

EssBee59 commented 2 years ago

Hello afischerdev,

Sorry, I am not expert with the github tools and do not know where/how to add the last update to the branch. The samples I delivered are really "special" situations, it should only be "nice to have" the results as I expect them... Regards Ess Bee

afischerdev commented 2 years ago

@EssBee59 There is nothing to do for you. I only added you voicehint.java. And you already have it.

it should only be "nice to have"

Not only, there are several irritations about the voice hints. Let us have more private testing. Then I'll clean our code and start a pull request.

EssBee59 commented 2 years ago

Let us have more private testing. Then I'll clean our code and start a pull request.

Thank for your response. perfect to proceed this way!

afischerdev commented 2 years ago

@EssBee59 @0709wiwiwi My results of the 0709wiwiwi track sample Trekking_trk_0.50km_rte_ticks.gpx.txt.

I have three points that are not as expected:

junction 2: 4.752863,50.800937;4.75213,50.80074 out: goodAngle=132.5071 higherBadWayAngle=181.0 lowerBadWayAngle=-32.98681 out: cmd=5 TR

junction 3: 4.74857,50.80373;4.748103,50.804655 was sharp left before is now left. out: goodAngle=-50.19359 higherBadWayAngle=92.80089 lowerBadWayAngle=-181.0 out: cmd=2 TL

junction 47: 4.725817,50.759602;4.722807,50.759035 was sharp left before is now left. out: goodAngle=-134.74637 higherBadWayAngle=30.249405 lowerBadWayAngle=-181.0 out: cmd=2 TL

frame_0002 frame_0003 frame_0047

EssBee59 commented 2 years ago

Hello afisherdev!

Thank for the tests: I understand your comments, for me TL as example was in a normal junction (without near badways) ok between -45 and -135..

I agree, we can change that... It is very simple to change the beaviour in the case where no "badway" impact the result:

The change that: (example: TL between -70 and -110 instead -45 / -135) replace with -60 and -120 if you prefer!

Change 1

// {cmd = TL;} // new 18.07 modulate the turn instruction if (cmdAngle < - 110. ) {cmd = TSHL;} else if (cmdAngle > -70. ) {cmd = TSLL;} else {cmd = TL;} // end change }

else if (cmdAngle < -21.)

Change 2

{cmd = TSHR;} 
else

// {cmd = TR;} // new 18.07 modulate the turn instruction if (cmdAngle > 110. ) {cmd = TSHR;} else if (cmdAngle < 70. ) {cmd = TSLR;} else {cmd = TR;} // end change }

else if (cmdAngle < 159.)

I tried today to generate the current 1.6.4 but I got errors... Could you please give again some short instructions to download the current source? (compile wit "gradlew build?)

afischerdev commented 2 years ago

@EssBee59 Thanks for your corrections. I'm not sure if I understand it right and where to put the changes. You don't use the badway values anymore. (the samples all have badways). Or should I replace only the {cmd = TL;} / {cmd = TR;} part?

EssBee59 commented 2 years ago

Only replace the TL and TR! See cod VoiceHint.java.txt e

afischerdev commented 2 years ago

@EssBee59 Did some changes on this in new lib.

I tried today to generate the current 1.6.4 but I got errors... Could you please give again some short instructions to download the current source? (compile wit "gradlew build?)

Yes, I compile with gradlew on windows. The download can be done by zip file from repository avoid-peaks or using git by git clone --branch avoid-peaks https://github.com/afischerdev/brouter.git Or you use the lib direct from last BRouter action ZIP

EssBee59 commented 2 years ago

Hello,

Thank for the links, I could download and compile without errors. My retest of the voiceHint´s on a 300 km route was successfull !

afischerdev commented 2 years ago

Coming from #453 with a more tricky problem:

BRouter Web with only the problem in it.

The highway=trunk makes a small angle to right and has a trunk_link on left side. I see two solutions:

we are rethinking the link situation
we change the angle for a straight situation e.g. 10deg

Code on VoiceHintProcessor

What do you think?

EssBee59 commented 2 years ago

You mean this place and using a "car" profile?

(the trunk_link is right?)

No voice hint is generated here... I think it is ok,,,

EssBee59 commented 2 years ago

I had a further look in 453...

Die geplante Route war von Leobersdorf - Knoten Wr. Neustadt - S4 Richtung Mattersburg - Abfahrt Neudörfl. Beim Knoten Wr. Neustadt zweigt die S4 nach Mattersburg ab. Es gab keine Anweisung, beim Knoten nach rechts auf die S4 abzubiegen

==> yes, in the old version "straight" was generated, possibly filtered by Osmand? But in the new version, a "slight right" is generated!!!!

EssBee59 commented 2 years ago

and now I understand the initial question...

No voicehint is generated, because the priority of trunk is 28, priority of trunk_link is 27 !!! If you set both to 28, you get

goodAngle=3.9405136 higherBadWayAngle=181.0 lowerBadWayAngle-1.6930294 cmd=1 C

of course, we can use the lowerBadWayAngle to generate a "slight right" in that case!

(I only see a solution by considering the lowerBadWayAngle. Will have a look in the next days on the code, this is not a minor change)

afischerdev commented 2 years ago

@EssBee59 Thanks for the test. You are right, this is also a discussable part. But I was focused on another situation a little bit forward: wien

it is always hard, when points of problems are not addressed well.

EssBee59 commented 2 years ago

But my last post above is Wtr.Neustadt-Ost with as goodway the trunk slight right and the badway trunk_link straight! I think, this is what you consider ?

Two changes are necessary:

1-Consider the "badways" for voicehint generation also by small angles See attached a new voicehint.java VoiceHint.java.txt

2-The generation of a voicehint have to be triggered at this place Three solutions:

a-set the priority of trunk_link idetical to trunk (same by motorway) But as side effect, each not used exit will trigger a voicehint… nogo !

b- set an unconditional triggger when a badway is a link and the link is more straight as the goodway to be tested (possible side effects, certainly not perfect !!!!)

c-set an unconditional trigger when a badway is a link and this link is left of the goodway apply only in countries with right driving

Do you see an other / a better trigger ?

afischerdev commented 2 years ago

@EssBee59 No, no idea at the moment. I'll try the new voicehint tomorrow. But we need a unconditional trigger otherwise no voice hint is generated.

EssBee59 commented 2 years ago

Hello,

Due to the following test case I changed a bit the voicehint.java:

map=17/50.05932/8.64934/osm-mapnik-german_style&lonlats=8.653,50.060024;8.645751,50.059469

Further I implemeted the unconditional trigger "isBadwayLinkLeft" (a Badway exists left and is a link!) in VoiceHintProcessor.java

It works in my first tests, but as explained above, it is only valid in countries with "right driving", a problem or not???? VoiceHint.java.txt VoiceHintProcessor.java.txt

EssBee59 commented 2 years ago

I had to restrict the unconditional trigger (badway is not badoneway, and badturn is > -100) VoiceHintProcessor.java,txt

EssBee59 commented 2 years ago

PROBLEM: using 1.6.4 (also with your version without the discussed change for car) I have the following problem:

When a turn comes after a first turn with distamce < "catching range", the second turn is generated twice! example:

map=19/49.32547/8.55747/osm-mapnik-german_style&lonlats=8.557463,49.325805;8.55688,49.325104&profile=fastbike-lowtraffic

(kook at the second turn, TSLR is generated twice !)

abrensch / brouter

Discussion on special cases for "turn instruction" #375

Change 1

Change 2

map=17/50.05932/8.64934/osm-mapnik-german_style&lonlats=8.653,50.060024;8.645751,50.059469

map=19/49.32547/8.55747/osm-mapnik-german_style&lonlats=8.557463,49.325805;8.55688,49.325104&profile=fastbike-lowtraffic