normally I would expect that the route is re-calculated to the next waypoint in the planned route when the Button “Skip next waypoint” is used.
Yesterday I had a strange effect when skipping waypoints: I have Skipped all waypoints in Order to get a new route to my planned Destination. But the route was calculated back to the previous planned route, even of there were NO WAYPOINTS any more. I don’t understand why because in this Situation the route should get calculated new and if there ist no more waypoint, then to the Destination.
I wouldn’t call this behaviour rerouting changes the planned route
Maybe your waypoints weren’t necessary, and Kurviger would have taken that route anyway.
But If you don’t want to share your route we can’t know.
Can reproduce the route at home and describe later with *.kurviger files and images what happened. e.g. @SchlesiM’s examples
With just text it’s impossible for us to understand any workflow.
yes that’s generally ok to follow strictly the waypoints (especially when the blue arrow is used). But on Tuesday I had the effect I used the menu to skip waypoints, in fact I had used this several times successively until I had only the destination to go, but the re-calculation was done as if I had not deleted (skipped) the waypoints… that was the weird situation.
sorry, can’t do this because I don’t know any more where it exactly was while this happened. I had another route as the road captain and wanted to have a new calculation to the destination because I had permanenty the message “route missed” or was off the route. So I used the menu to skip all my waypoints, but it didn’t recognize this. It wanted to drive me back to my originally planned route. This is all what I can say. If this is not enough to guess what could happened, then just forget it. I can’t simulate it too. I can just descibe the behaviour the best I can.
Android (thought this would be more precise). Yes, Kalman filter is always enabled.
good, but difficult question, since I don’t know exactly any more where it was, but it was on the way back, could be this area. When GPS lacks can lead to this route missed, I guess this was the reason then for not recalculating the best way to the destination after having skipped all waypoints.
I first tried to find manually a another way, but there were also road stoppages. I had to make a bigger detour. Because it was difficult to identify in which direction the gps showed and I couldn’t bring it in line with the reality, I used the skip next waypoint function to get a new calculated route around this. I even stopped and made new waypoints too. Nothing helped, I didn’t get calculated a correct route back to my destination.
In the screenshot you can see that the gps recording didn’t happen for quite a while. There are many lacks in between, but the gps signal was not lost, it was active on the screen all the time and moved correctly.
The usage of skipping waypoints some times more then resulted in the exchange of my destination from Oberkochen to Monheim. I wasn’t aware of this while driving, just saw this after the tour. I had to stop using kurviger at this time and used my other app Navigon Cruiser to easily find my way home, because I was bugged out by this behaviour and didn’t want to lose more time to guess what happened.
The movement of the destination to antoher area is a big error in my point of view and should never happen. The destination should NEVER be deleted by skipping waypoints. I hope this can be fixed.
The strange thing is also the lacks in the gps recording. Here the change from Android to Google location service obviously didn’t help because in the previous tour the same problem happened with Android location service.
Can see Google’s description for their location provider versus Android native one.
That cannot happen.
Skip next waypoint just skips next via point (if exists), while destination remains always the same.
If GPS sensor on some devices reports unusual readings, they could not pass the GPS logging filters depending on their values.
In such cases can relax or disable some filters and keep the basic ones, mainly time interval and maybe minimum distance.
But then we come to another problem or request reported earlier in another post… the context menu entries are too close together and the touch areas are not usable pinpoint. The font sizes and rectangular sizes should be much bigger than they are now in order to not use the wrong entry with the touch capable gloves. Also good would be that a borderline is drawn between each submenu.
If you are really sure that a development problem can be excluded, then I am sure that exactly this happened: I used insert as destination (german: Setze als Ziel) instead of interim destination (german: Setze als Zwischenziel)… But this should also not happen by accident. This could be avoided by making BIG Squares for each submenu function…
here a screenshot from Nav. Crusier. The separate BIG Action Menus are reached by just swiping to the left and the functions are also customizable.