There is a strange error in routing. I am using version 1.11 with Google location on on an Android 9 (API 28), samsung SM-G955F.
The automatic recalculation is active. I just entered a destination from actual position and I didn’t drive as planned and often changed the direction so that recalculation was used. The software created automatically additional waypoints and I coulnd’t delete them with the skip waypoints functions. It just didn’t delete any waypoint of the additional created ones. You see the many waypoints set within a small distance, I didn’t create them. They were created by Kurviger while driving and recalculating. I have used the skip waypoint function many times in order to delete them again, but it looks as if it created waypoints instead of deleting them.
To everyone like we have mentioned already many times and exists in reports template:
Please provide route link examples when make reports and also detailed instructions where exit / enter or make any route actions. Or else it’s impossible for anyone to actually invest time to understand just the images / text (though they’re needed too) and check any reports.
Skip next waypoint should do what its name declares, skip the one (next) waypoint ahead of user location.
Rerouting may create one extra waypoint while navigating and have enabled “Nearest point on route” in settings or when begin navigation away and select “Start” in rerouting dialog.
If be on a road where route goes forward / backward, then strange things can happen, specially if GPS sensor declares that vehicle snaps in the opposite direction.
That’s a fundamental issue that all navigators have and obviously is more prominent in non usual round trips, since most people tend to use more the common AB routing.
I also think "Nearest point on route” was enabled. I think with this option enabled, rerouting always tries to navigate back to exactly the position wehre you left the original route
“Nearest point on route” on rerouting tries to find the nearest point on route from user location at each time a rerouting is calculated. While moving away from route and a rerouting can happen at any time (automatically or by user), the nearest point is calculated at that exact time of rerouting and can be basically any point on route path.
The app started to create waypoints. Even when I was near the original route again, the automaticaly generated waypoints weren’t deleted any more. The app continued to navigate back to exactly the position, where I left the original route for the first time:
Have explained above about new waypoints in rerouting, as depend on rerouting options. If after rerouting location remains away from route, then new rerouting can happen again.
There isn’t any original route after a rerouting, only the new calculated route.
And obviously cannot delete any waypoints automatically, users can do that.
Can change the rerouting option if want a different navigation behavior or use manual rerouting.
Like the “Next unvisited waypoint” rerouting option which is the recommended default anyway.
Ok, but then also the app shouldn’t create any waypoints automatically. All the waypoints 1 to 7 in my screenshot above were created automatically by the app when leaving the route. With this behavior “nearest point on route” doesn’t make any sense in my opinion.
Then how the routing is supposed to calculate a new route with “Nearest point on route” rerouting option, if cannot estimate a nearest point, set a waypoint on it, so can force the routing towards it?
Routing needs waypoints for route calculation: start / via points / end.
That’s how this option works and why are available other options too.
What you described nicely above is a complicated rerouting case, where there were consecutive reroutings (because GPS reported be away from route?) with the “Nearest point on route” option.
sorry, didn’t have time any more to follow the discussion and also can’t upload the link anymore, but obviously I am not alone with this problem. My problem occured with setting “Next unvisited waypoint” which is my default.
It could be that the internet connection was very poor and the app permanently recalculated while I tried to use the function “skip next waypoint”. Potentially this deletion of next waypoint is not working while recalculation? It maybe requires a new calculated route before next waypoint can be skipped? My intuitive behaviour would be that the next waypoint is deleted when I use this function, then the recalculation starts again. For sure I have used the skip next waypoint function more times than the number of waypoints had been automatically created so I guess the deletion doesn’t work in this case.
The examples above demonstrate that rerouting towards “Nearest point on route” does not work very nice. As @grua suspected, the algorithm has a tendency to guide you back to the place where you just have left the route.
This is also true for the “beeline like” direction arrow. Usually this is not what users want (and the reason I don’t use the option “nearest point on route”)
Maybe the practical behaviour could be improved if you add some bias to the “nearest point on route”?
What would be the result, if you use a point ~500m closer towards the End, instead of the exact nearest point on route?
It works as designed to work: nearest point on route. Whatever that “nearest” point can be, backward, beside, forward, etc. There is no “next” in its description (if mean that).
ok then this is the explanation why the waypoints didn’t disappear
“Next unvisited waypoint” cannot add new waypoints.
It uses user location as start and all existing unvisited waypoints in new route calculation.
How do you then explain the many waypoints in a small distance on my screenshot above? For sure I didn’t create them and for sure I had “next unvisited waypoint” active since I don’t like the automatic deletion of waypoints.
What I originally expected from “nearest point on route” was something completely different: I had expected that with this option, the old original route always remains stored in the background and the app always tries to return to this original old route by shortest way.
But I think that behaviour can be approached by increasing the number of waypoints on the route and using the option “next unvisited waypoint” instead of “nearest point on route”.