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.
There have been (very rare) incidents in the past.
After many consecutive reroutings (which the rider ignored) no further reroutings were triggered any more.
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.
What option is selected in “Settings | Routing | Routing service”?
What option is selected in “Settings | Navigation | Rerouting mode”?
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)
What option is selected in “Settings | Routing | Routing service”?
Kurviger(Online)
BRouter(Offline)
What option is selected in “Settings | Navigation | Rerouting mode”?
Nearest Waypoint
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. Deviation: Only after + 17x recalculation msg’s a new fwd alternative path is suggested. Crazy…
Update. After an auto recalculation, if you than add an obstruction (500m) while you’re still moving, the blocking is automatically positioned onto the recalculated (return) path, such than results into an extra new recalculation that so automatically offers you a fwd alternative.
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.
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.
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.
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.
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.
