Example with the Kurviger online router. See video.
When you arrive at the junction with the L1103, follow the diversion to the L1110. The false moving direction is shown by the increasing turn distance indicator. So you now get 3 consecutive 180 ° turns that you refuse. Immediately after the third 180° turn in a single row add an obstruction. (Now a job to do manually - automatic trigger possible?) This causes a new recalculation and a fwd drive proposal further toward the L1110. The rider later changes his mind and still want to enter the L1103 anyway. So turn on the next roundabout and have a return. You now again get 3 consecutive 180 ° turns that you refuse. Immediately after the third 180° turn in a single row add an obstruction. (Now a job to do manually - automatic trigger possible?) You will then receive the renewed proposal toward the L1103.
NOT implemented in the Kurviger app ! - Detect a false opposite travel direction by the steadily increasing distance indicator to next turn. - As long the travel direction is the opposite of the calculated route direction, add the msg 'Try to return". - If the user keeps ignoring the “Try to return” request the app should block the return path by add obstruction.
When an identical case happens you again, you could try to halt multiple annoying recalculate messages as indicated in the demo video by a manual action. The price to pay is you should halt your bike for safety reason, put out the gloves, tap the screen to add the obstruction, before a ready to go again. What I want to show is that after 2 ignored 180° turns at the 3 e recalculate attempt the app would already understand and add an obstruction automatically. Anyway other ideas welcome.
The barrier of the L1103 to Pfaffenhofen.
In order of preference.
The most optimal: The barrier in Pfaffenhofen is indicated in osm. (Is not)
Manually indicate the blocking while you are still on the route, this where the detour starts at the L1110/L1103. (Didn’t happen).
Follow the detour and either manually or automatically as suggested you place a block on the returning L1110 route back toward the missed L1103.
You will get an alternative but you have to be very attentive because it may well be that an alternative will just bring you back to the still unblocked L1103.
Placing an automatic blocking on the L1110 where you do not want to roll back do prevent the multiple almost identical recaclulate commands .
I tested a local real deviation circuit. Kurviger online had 12 x recalculate msg’s before a usefull new route was calculated and offline BRouter had 11 x recalculate msg’s (Fast to route: set)
It would be nice if Kurviger automatically accepted the “boss” road preference a little faster.
I further checked the idea by some more slow speed (bicycle) tests.
Mostly did use the offline BRouter @ a non high (medium) density road network.
No city streets, where a smaller block area maybe could be more optimal.
Does the method do the job as expected ? = OK
Is the method flexible ? (Changing mind) = OK
No extra issues, no non escape loops, nor unexpected stop ? = OK
Moving in the forward route direction decreases the turn distance indication.
Moving in the opposite route direction increases the distance indication.
AFTER each recalculation, the app than checks the route distance change.
(Manual simulated test was safely possible whilst moving @ slow speed)
If the distance increases then generate an additional TTS msg: **“Try to Return”.
In case the distance increases (2) 3 times AFTER EACH OTHER, generate an obstruction.
This way, without halting, you enforce an alternative after (200 a 300m) 300 to 400m.
Escape so out of multiple identical recalculate msg’s whilst you keep further moving.
**(See therefore also the previous video inclusive subtitles!)
So far did not find any negative in producing a block like that as the road block toggling change technique used by the Kurviger app is unexpectedly very flexible.
Must say I was surprised to observe that, as this is very different as I was used too by that other app where all (multiple) such generated blocks are kept in memory for a certain time spam.
Anyway it would be very usefull of course if also another person would test and confirm my findings.
Virtual test by V 1.14.15.
Test track Güglingen. Simulated the redirection as described by RHoffner.
Talks a little less now, but if you just keep driving, still repeats 22 x Route recalculation.
Only the 22nd time you do get the long-awaited forward alternative. (Kurviger online)
Lets wait for real user experience reports ?
Is just a report Emux as you probably do expect by Beta tests and this inclusive some of my own findings. Nothing more. And yes I do know this subject is certainly not an easy task for you the developper. Courage.