Navigation stops after several rerouting attempts

[RHoffner]

Scenario :

• closed route and i have to leave the planned route
• the part of the closed route does not contain any routing points.
• it was not possible to stop to operate with kurviger
• Rerouting was done in offline mode
• after 15-20 unsuccessfulI rerouting attempts navigation stops and hangs
• it was not possible to activate navigation again, only restarting of the app helps
  Suggestions:
  Would it be possible to stop rerouting after several attempts and wait until either a manual rerouting is done or back on route.
  And rerouting in offline mode should not cause the application to hang

[linux-user]

Could you please post a link of your route an inform us where you left the route?

@RHoffner

Rerouting was done in offline mode

What exact settings had you in: settings routing | Routing-Service?

@RHoffner

it was not possible to activate navigation again

What steps have you tried?
Have you been on the route or off the route (=the blue line)?

[devemux86]

Thanks for the report.

More information would be useful, so that everyone can understand clearly the report.
Please post a route example, the rerouting location and routing & navigation settings.

(Re)routing can succeed only when the two waypoints are connected by road network.
Regarding offline routing, have you downloaded all your area offline routing data files?

Navigation can be enabled when there is a route and GPS location.
So it cannot simply stop or “hang” when these 2 prerequisites exist.

There were not any cases of any app or navigation stop or “hang”
and it is really difficult to understand any of that without more info.

[devemux86]

You can also disable the automatic rerouting,
in the navigation settings or by pressing the upper left navigation panel.

And use the manual rerouting by pressing the warning sign.

See the documentation for more details:

How and why can I navigate with manual rerouting?

[linux-user]

There have been (very rare) incidents in the past.
After many consecutive reroutings (which the rider ignored) no further reroutings were triggered any more.

Sometimes (rarely) navigation stops working

On rare occasions navigation stops working and no recalculation is triggered any more. This week i had a similar issue as described here but with new phone Kurviger had navigated me to munich, then throughout the day other apps had been used. The way back home: routing | actions | turn route Start navigation (automatic recalculation on ) I took another route as calculated by Kurviger. So virtually on every intersection through munich, a recalculation was executed. Then after 10-20 recalcul…

[devemux86]

@linux-user

There have been (very rare) incidents in the past.

These are more than 2 years ago.

Application and navigation are no longer the same,
so we can not compare with that time.

(only latest version is supported)

[RHoffner]

Original route : https://kurv.gr/xsEEV
Between Waypoint 6 and Shaping Point 7 the road was closed.
Driven Route : https://kurv.gr/GnQdD
I would not say that the app hangs, but no navigation occurs. As said above no recalculation occurs and no navigation was done even when back on the original route.

And I updated BRouter maps just before starting my trip.

Is there a possibility to say that rerouting should not use uturns or stop using u turns after let me say 5 attempts?
This would help a lot instead of trying u turns over and over again.

Is this enough of information for you?

[devemux86]

@RHoffner

As said above no recalculation occurs and no navigation was done even when back on the original route.

What option is selected in “Settings | Routing | Routing service”?

What option is selected in “Settings | Navigation | Rerouting mode”?

@RHoffner

Is there a possibility to say that rerouting should not use uturns or stop using u turns after let me say 5 attempts?

The routing is calculated in Kurviger server or via Brouter app.
Kurviger app can only use the available options provided by the selected routing services.

You need to provide a route example to understand what you mean with u-turns.
(placing waypoints on locations with u-turns, like here, then it cannot be avoided)

See also:

Avoiding U-turns

Hi. Me and my buddies don’t have any problem with that, but all the girls I know hate U-turns. For the sake of motorized girls (but of course not only!) please consider introducing such a restriction on the Website and in the Application. I rarely get lost in navi, but I often consciously enter a different route than suggested by navigation because this is my whim (but sometimes a necessity). In that case, a U-turns avoiding would also be useful to me.

[RHoffner]

What option is selected in “Settings | Routing | Routing service”?
Kurviger(Online)
BRouter(Offline)
What option is selected in “Settings | Navigation | Rerouting mode”?
Nearest Waypoint

[0709]

Keeps “whining” and calculating backwards without a real clear U-turn command? Sounds BRouter.

Ansage bei brouter Offline Neuberechnung nervt zu oft

Hi Emux. Kurviger GH offline is (was)friendly nice as GH prefers fwd drive rerouting. The alternative B-router rerouting does have a very annoying drawback. Very annoying and seems probably not preventable by Brouter profile change. Using a Brouter away from main roads profile this is even more of a problem. Possible by Kurviger App? (Re)routing by Brouter. To know. Brouter default nogo radius is 20m. A. First Out of track trigger @ + 40m > Beep Alert 1 + Add temp nogo 1 Add nogo 1 tri…

Hangs? That sounds like a lot of switching from online to offline (B)routing. Data coverage optimal ?

I simulated at 50 kmh by the recorded track & using the Lockito app.
Simulate path deviation by a shortened gpx record. (attached)
Import the Kurviger file> calculate & coverage.
(Eventually + import the recorded track by coverage for best overview)
Set autorecalculate rerouting to BRouter only.
(Can’t simulate the local data coverage situation)
Start Navigation & Start Lockito simulation for a test.
Deviation: Only after 17x recalculation msg’s new fwd path is suggested.
Crazy…
Kraichgau_100_omleiding.gpx (57.7 KB)

Update. If you place an obstruction (500m = Kurviger minimum offered) while moving, of course in reality it is better not to do so for safety, the calculation is forward.
Could it be automated as suggested in the link above?

[RHoffner]

Thank your for doing the simulation. In this area you have a poor cell reception, so i guess the navigation switches often from BRouter to Kurviger for recalculation. This can cause my issue, but it is a rare case.
However 17 recalculation messages are too much. I am not sure if it is possible to stop for U-Turns after a while.
And even if it is not BRouter Kurviger(online) also wants to do U-Turns unless the next waypoint is nearer with the Fwd Path.
Here i would suggest to stop U-Turns after a while( Amount or Distance).

[devemux86]

@RHoffner

What option is selected in “Settings | Navigation | Rerouting mode”?
Nearest Waypoint

@RHoffner

And even if it is not BRouter Kurviger(online) also wants to do U-Turns unless the next waypoint is nearer with the Fwd Path.

Then you can select the “Next waypoint” option in “Settings | Navigation | Rerouting mode”.

[0709]

It seems the Kurviger_router obstruction implementation is different than in Locus_Brouter

In Kurviger (So is GH) you report that the further route is blocked for a certain distance.
After which a new navigation proposal follows. Simple.
Locus_BRouter triggers a recalculation and creates a circular blocking zone.
You can leave this zone, but once outside it, a reentry is blocked. Not that simple.

So what I found so far…but this should be confirmed by more tests or testers.
By recalculation trigger 1: Brouter (mostly will) suggest a 180° return route navigation path. (OK)
If now an obstruction is set up than an (non 180° returning) alternative path is recalculated.
Q: Could (a) next recalculation in a row auto trigger and set up the obstruction? (20m zone)
@Emux…I did test with next waypoint set. (Anyway is a complex exercise to simulate correctly)

[devemux86]

@0709

Anyway is a complex exercise to simulate correctly

I implemented and use my own Navigation Simulator.
It is a separate advanced system powered by Cruiser.

[Tom]

@RHoffner

Thank your for doing the simulation. In this area you have a poor cell reception, so i guess the navigation switches often from BRouter to Kurviger for recalculation. This can cause my issue, but it is a rare case.
However 17 recalculation messages are too much. I am not sure if it is possible to stop for U-Turns after a while.
And even if it is not BRouter Kurviger(online) also wants to do U-Turns unless the next waypoint is nearer with the Fwd Path.
Here i would suggest to stop U-Turns after a while( Amount or Distance).

I had the same issue last sunday. Only difference in my settings is that I have set strict navigation.
I have reported the problem various time in the past. It didn’t change: It takes too long until the switch to offline routing happens, especially when there is low bandwith. I proposed in the past, when a route can’t be calculated after several trials, for example after 3 attempts, then hard switch to offline re-routing, at least temporarily to the next waypoint. Don’t know if this is useful, but any kind of hard switch to offline routing may help. If you just proceed your route for several minutes until internet bandwith is ok again, then mostly the route gets calculated somewhen.

[devemux86]

@Tom

any kind of hard switch to offline routing may help

You can select BRouter (offline) in “Settings | Routing | Routing service” before navigation.

[Tom]

@devemux86

You can select BRouter (offline) in “Settings | Routing | Routing service” before navigation.

This doesn’t really help since Brouter doesn’t calculate the nice curvy routes or did this change somehow?

[devemux86]

@Tom

This doesn’t really help since Brouter doesn’t calculate the nice curvy routes or did this change somehow?

What else does everyone expect the app to do?
The lack of offline Kurviger routing can not be solved magically.

App provides routing service combinations and partial offline rerouting.
These features exceed the normal requirements of any navigation app.
Navigators typically perform complete reroutings with 1 routing service.

• Kurviger routing needs internet
• Or customize BRouter profiles
• Or ask Kurviger to work offline

Integrate Kurviger routing algorithm into offline BRouter / GraphHopper

Robin, Is there a chance we get the same routing behavior in one of the offline routing engines (brouter or graphhopper)? Thanks, Tom

[0709]

Makes sense ? (Pse…is just free brainstorming)

• There is a design, a kurvig design or not. You end up on a detour. So you have to leave the design. The detour is marked, so follow it.
• A region with poor data connection? Resolutely opt for OFFLINE navigation assistance, or maybe you select no autorerouting and just read the map ?
• At some point you will reconnect to the design, then choose whether to return to missed reference Shaping or Via points or simply continue the original route forward.

By no strict navigation set. The reported problem.
Offline Brouter has been nagging for too long to keep returning through 180 ° turns, without offering any alternative.
BRouter does not even report such 180 ° turns as a U-turn this in contrast to GH. Annoying.
Solution ?
Place a blocker that prevents 180 ° returns as early as the second consecutive recalculation trigger. If you continue driving, Brouter will still propose some alternative recurring routes, but that will be much more limited. By the way, you are following the official diversion, right? After a while, BRouter will also understand, and you will then navigate further toward the original design. A return to missed Shaping or Via Points or just continue the original design? You determine that on the spot. If you choose to continue, Kurviger understands this quickly and from here you navigate back with the original (kurvig) design.

[Tom]

@devemux86

What else does everyone expect the app to do?

Don’t misunderstand. I don’t expect something. It is just a thought how it theoretically could work. I can’t estimate how complex a change is or if it has other disadvantages. So absolutely ok like it is. The current routing features are sufficient. I just recognize that under some situations the switch between online and offline routing is not working. No problem. I assume it is due to a low bandwith where internet connection is not completely lost. Don’t worry, I can live very good with the currrent routing options. The app is retrying the routing after a while and when there is a good internet bandwith some kilometers further, it works again. No need to change something.

The only thing which I would enjoy is the already discussed switch like “ignore reported closures” (similar to a planning mode that ignores ALL reported blockages in the maps and which could also be used for navigation by just activating the switch). This is something I would very much appreciate in Kurviger Web and Kurviger App.