Navigation stops after several rerouting attempts

Discussion Android App
21

You left the route shortly after WP6; so “nearest waypoint” is WP6 for quite some time of the detour.
Consequently rerouting wants you guide towards WP6

… I think, in most situations “Next Waypoint” (=Nächster Wegpunkt) is a better choice than “Nearest Waypoint”
I guess that then rerouting would have switched earlier to the actual driven route.

2 Likes
23

Example with the Kurviger online router. See video.

Demo.

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.

24

Automatic rerouting is overrated and can produce strange results in all navigators.

Exit / enter route anywhere and manual rerouting remain the optimal way to drive.

GraphHopper cannot work with Android SAF. Its focus is more on online routing.

BRouter profiles and customization are unmatched by all known routing engines.
(and is the only offline routing service available at this time)

1 Like
26

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

  1. The most optimal: The barrier in Pfaffenhofen is indicated in osm. (Is not)
  2. Manually indicate the blocking while you are still on the route, this where the detour starts at the L1110/L1103. (Didn’t happen).
  3. 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 .
1 Like
27

BRouter supports nogo areas.

GraphHopper plans to deprecate the block_area:
(also used in “Avoid roadblock” feature)

28

Hi 0709,
It is not always possible to find a spot where you can safely park your bike. Currently i add an electroconductive thread to my gloves to do this operation quickly.
Thanks for the support.

29

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.

30

Could you post both routes so we can reproduce the example:

  • the url of your original route example
  • the the url of the preferred detour (=“boss” route)

What setting have you in Settings | Navigation | recalculation mode?

Apart from that, I think it is very difficult to create an algorithm that does 2 contradictory things at the same time:

  1. keep the original route as good as possible
  2. switch to an alternative route (=detour) as quick as possible
1 Like
31

Hi Manfred.

Recalculate route - Next Waypoint - Fast to route: Unset

Local circuit attached:
Design route as .kurviger. Detour as gpx.
Lo_Lo.kurviger (1.3 KB) Zeveneken omleiding.gpx (23.8 KB)
Simulate by the Lockito app. Set @ 50kmh.

Favorable for the local detour. Third recalculate = Fwd. However, does not help for the Guglingen detour.

After second recalculation: Trigger set obstruction 500m.
That way you say: I don’t want to go back!
Notice:
I report this as 180° turns, as the app does not report the try to return action to do.

32

Navigation / voice guidance works with the route / turn instructions calculated by the routing service.

Navigation can not announce artificial instructions.
Like “Make a u-turn” when u-turns are not allowed.

Only routing service knows the road network and produce the turn instructions.

Routing service must first (re)calculate a valid route, produce the turn instructions
and then they can be used in navigation.

34

Please avoid the many edits for questions.
Edits do not send notifications and are lost.

35

A post was merged into an existing topic: Navigation announcement incorrect when driving the wrong way

36

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.

Test Goal:
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

Principle:

  • 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!)

37

Please wait for next version that will not have the automatic 1st voice announcement
and then we can check the whole situation again.

In any case, creating artificial road blocks is not a safe solution,
as the only road network known to navigation is the route itself.

38

Sure will do :wink:

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.

39

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 ?

40

The application understands that user moved away from the calculated route.
It requests from routing service a new route, passing user location + heading.

If routing service calculates a backward route that fails to navigate, what next?

I have explained above that navigation is (advanced) mathematics.
Human perception and fuzzy solutions do not work with computers.

1 Like
41

GraphHopper routing API (and Kurviger) support heading directions.

If I remember correctly BRouter does not support heading directions?
(so the preferred starting direction of the route can be any)

Please check carefully the calculated (re)routes
and reproduce them in Kurviger / BRouter sites.

If a routing service insists calculating a route,
the app can receive and use it or ask a new one.

42

Is just a report Emux :wink: 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.

43

No problem, the interesting part is to turn all this into mathematics. :slightly_smiling_face:
(using the available tools)