Kurviger.de | Application | Blog | Frequently Asked Questions (FAQ) | Legal Notice | Privacy Policy

Rerouting changes the planned route

Towards nearest or next waypoint? In some situations this might be the same waypoint, in others not. It would be helpful to be able to understand the algorithm more precisely.

It’s an AND (not OR). The algorithm searches for the next waypoint which is nearest to user location. While skipping any waypoints that were “passed” while moving far away from the route.

(obviously depending the route / road geometry some corner cases can happen)

Just back from a quitting time tour…

… thanks for clarification, this helps better understanding what happens and means, if I don’t want any waypoint to be skipped, never use these 2 options of the blue arrow function:

When start navigation away of route and trigger a rerouting, then the rerouting dialog appears to select:

  • Nearest point: rerouting is done towards route’s nearest point (skipping waypoints)
  • When go away of route with active navigation , then a rerouting is triggered towards nearest / next waypoint.

Also fine when Explicit waypoint types (shaping, etc.) will come in a future version to define waypoints which should never be skipped in any case.

What about a change here? When go away of route with active navigation , then a rerouting is triggered towards nearest / next waypoint.
Change to also show a menu with 2 options like mentioned above:

  • reroute to the nearest GPS waypoint
  • reroute to the nearest waypoint in the planned route

An alternative for this would also be a fixed setting for one of the above mentioned options for the blue arrow when go away of route with active navigation

A thing for submenus is also the size of text and touch areas of the options. It would result in a better handling if they are bigger in size in order to be able to strike the right option with thick motorcycle gloves.

After all I think it’s somtimes really hard for an algorithm to decide what the appropriate next waypoint should be when it comes to recalculating a route. Especially if one of the “later” waypoints is nearer to your current location than any other waypoint.

Therefore if planning a roundtrip (where “start” and “end” are in fact the same location) I’d recommend to move the “end” point a little bit farer away from the location where you begin your trip than the “start” point. Otherwise Kurviger says “destination reached” immediately. I noticed this behaviour regularly after importing GPX files from another route planning system.

If Kurviger will support two types of waypoints (“must visit” and “only shaping”) in one of the future versions this issue should be finally solved.

2 Likes

I can’t imagine that it is too complicated, at least in theory. App knows all positions and the sequence of all waypoints. The last past number of the waypoint is probably stored in a variable. When the blue arrow always offers a menu especially when go away off road with active navigation and has two more options, one for recalculate to next number of the waypoint and one for stoppage, shouldn’t this work? Example: last past waypoint was number 4. In first Option hit the road to number five in second option it skips five and heads towards six.

I think with “human eyes” the whole situation of a route can easily be interpreted to take the “right” decision. But an algorithm sometimes is more limited (at least if you don’t offer additional rules and information like diffferent types of waypoints defined as “must be visited” or “can be left if necessary”).

Here’s an example. Same section, same route within this section, but whole route situation differs.

Situation 1: I left my route at Wollomoos heading Sielenbach (red arrow). Now the nearest waypoint is number 9, but it seems to be Ok that 7 and 8 are omitted after recalculating the route and that my route continues with waypoint 9.

Situation 2: left my route at the same position. But this time the route is longer (more sections to go between waypoint 7 and 16). But (of course), after recalulating based on the same algortithm waypoints 7 to 16 are omitted and like in situation 1 my new route will continue with waypoint 17.

So my question is: how to decide? One solution would be to define waypoints as “must be visited”. If in situation 2 one waypoint between 7 and 16 would be defined accordingly, everything would stay just fine - even after recalculating the route.

For clarifiycation one more situation which should be considered when planning routes. In this case I imported a route from another route planning system. Again it’s a roundtrip starting from and ending at my homebase (in fact this isn’t my real home, just choosen for example).

It seems to be of minor importance where exactly to set “start” and “end”. But it isn’t if I begin my route at a position away from those two points.

Situation 1: “end” is a little bit farer away than “start”. If the route is calculated from the position with the red arrow, my route will begin with the “start” point and everything’s just fine.

Situation 2: “end” is a little bit nearer than “start”. If the route is calculated from the position with the red arrow, Kurviger would immediately say “destination reached”. Of course this wasn’t the intended way to go, but without additional information (e.g. what waypoint to head for at the beginning of the route) this can easily happen.

2 Likes

why do you think so complicated?

I don’t want the algorithm decide what to do, especially not deleting any waypoints automatically… I want to decide that myself.

In 95% of all cases you start your way at your starting point. If for some minor reason you want to start in the middle, then just go to waypoint list and delete MANUALLY the number of waypoints which you don’t want to pass and start your tour. The algorithm can then calculate the way to the next available in the defined tour sequence… if you have deleted 6 waypoints, then it should find the 7th.

I only don’t want the algorithm to automaticall delete waypoints just because I am near to another one. The function can be kept whenever needed, but it should be offered as an OPTION and not the default way of working when leaving the route, for example because you have just missed the turnoff.

With the 2 more options mentioned above, everyone would be happy.

Because mathematics are different than human thoughts.
Or else everyone could master them in one weekend. :slightly_smiling_face:

In that case the rerouting dialog appears already and can select where the rerouting is done:

  • Start
  • Nearest point

So where is the exact issue of this discussion?

Because my thoughts are driven by the way Kurviger works. If leaving a route and recalculating it, my current position IS the new start point (in my example above the position of the red arrow).

In my opinion there are two scenarios to be considered:

  • what should happen, if I have automatic recalculation switched off and activate recalculation manually by tapping on the direction indicator? In this case it would be Ok if I have to decide something in an additional dialog.
  • what should happen, if automatic recalculation is activated? In this case the app should be able to automatically take the “right” decision for me because I don’t want to fiddel around on the screen while riding my bike.

Yes, I agree with that. Still room for improvements. But I’m pretty sure we’ll see them in a future version.

In my opinion there would be two approaches:

  • simpler: offer a new setting to avoid automatic decisions about the next waypoint when recalculating the route. This in fact means that you alway have to skip unwanted waypoints manually if leaving the original route.
  • more complicated: functional diffferentiation between “via / must be visited” waypoints and “shaping / can be omitted” waypoints to define a route.
2 Likes

Thanks for summarizing, the topic is already too long with much text, so difficult to clarify the options.

Is anyone expected to do that while driving?

Explicit waypoint types (shaping, etc.) are in todo list:

2 Likes

One Last Post, then I give up and think by myself how (willingly?) can someone be misunderstood? This was only related to schlesies answer.

That’ts Not the situation where I am talking about. I’m talking of what you say:

*When go away of route with active navigation, then a rerouting is triggered towards nearest / next waypoint.

This happens very often when i’m on the road, also when the GPS-Signal is Not exact enough. And in this Situation there is No Option Menu and Pressing the blue Arrow destroys waypoints and this is a NoGo for me.

I consider this as too Dangerous for my well-beeing and use another navigation App until this is sorted Out in some way in the future. Sorry.

@schlesieM
I had mentioned that I normally use Automatic calculation Off by Default, so No Change needed for me in this Variant. Except maybe one: Automatic Deletion of waypoints would also be a NoGo for me.

Thanks that is finally clarified. So mean while navigation is in progress and go off route, to not resume later at nearest route point but have also other extra options, like use all waypoints.

As Robin mentioned, rerouting was designed in the way users wanted it and expect on road. That’s why there are not any complaints so far. Nevertheless any improvements can certainly be discussed, re-designed and implemented.

1 Like

Ok then a last last post: yes, I do. Just please take this as a proposal. Also then would be fine to make the context menu entries bigger as they are… distance between the entries around 3 times bigger than now and with Bold Font and bigger and big touch areas in order to not mix it up while driving and not select the wrong one with the motorcycle gloves.

Cool. I would consider this as a workaround until the “via / must be visited” waypoints and “shaping / can be omitted” waypoints feature is available:
When pressing the blue arrow, forcing to show the submenu in every case:
I guess it is possible to identify and remember the last passed waypoint (starting with 0)

Option 1: Route to next waypoint in sequence of the planned route
Option 2: Start (like already available)
Option 3: Stoppage (route to next but one waypoint in sequence of the planned route after skipping only the 1 next waypoint of the sequence…)
Option 4: Next waypoint to GPS position (like already available and driving me crazy)

I think I can then pull my socks up and remember not to use option 4 :slight_smile:

Ok I stay tuned, but for this weekend I will temporarily take another nav system for the Dolomites.

Mean a specific context menu or all of them?
We generally use Android’s default fonts, sizes per theme (except nav panels).
It’s considerable work to visit every UI element and apply custom appearance settings.

Android offers font size options under system “Settings | Display”, that could help in the meantime until we can review the UI. :slightly_smiling_face:

No need to visit every UI element.
Mean all context menus. I played already around with bigger Font sizes on OS level, but this has the disadvantage that the navigation and information bars on the top get too big and use too much of the screen. This reduces the available space for the most important thing, the actual driven route.
If especially the context menus could be size increased, I think this should be just fine for every motorcyclist who mostly handles the smartphone with thick touch capable gloves.

That’s how Kurviger worked some time ago. And there were many complaints. There are many cases where you don’t start at your starting point. For example you stop at a road stop and stop the navigation. Start it again, suddenly you are in the middle of your route, why should you have to delete waypoints?

I think we had a discussion here in the forum to change the behavior to must visit all waypoints as an opt-in setting. But I think we dropped that in favor of allow to set certain waypoints as must-visit points.

I think that’s not a good solution. Hitting a large blue button with gloves can be done easily by everyone. Reading text, deciding for an option, and then trying to hit it with gloves is not nice.

3 Likes

That could work via an option (nearest point | follow waypoints) in Settings, so that during navigation no dialogs suddenly appear. Though still remains that need to re-implement different code paths to support different workflows.

I think to resolve, this Kurviger needs to keep track of past way points. When recalculation route due to stop or something, and starting up again, it should automatically route to next way point that it has not gone through and also have a setting that asks if recalculate should go to nearest way point or next way point.

1 Like

Perhaps a proposal as a compromise, because I had an similar topic today:

Would it be interesting to give the user the chance to select “next waypoints” and additionally the selection " waypoint nr …"…" (entry of the number?) while importing a file and/or recalculation of a route?

Today I had a tour: we came to a blocked road because of some cable installation - and we followed a lokal information how to drive.
The tour was there like a large circle and because of the lokal signs we came nearly in the middle of the circle. The plan was to go to the south first, and then came back after driving aroung in a large circle. Rerouting was disabled . After a lot of km I’ve thought that I could do the rerouting (blue arrow) to find the way back to south on the planned track.

I didn’t imagine to be to near on the way back - and for sure it happened the not planned action: After e recalculation Kurviger planned a new track directly to the north and then the way home, withouth the planned large round tour. Unfortunately the rest of the track before was eliminated. So I’ve driven with another navigation tool to the next large city (I’ve remembered the name), there I’ve restarted Kurviger and imported again the origin kurviger-file (with information “next waypoint”). Then we’re back on the planned tour.
But a little bit complicated :slight_smile: - and not easy to explain in english :slight_smile:

So my idea was today: if I’m able to import the route and calculate with “next waypoint” - it would be interesting to have the function " waypoint nr…" as an alternative.
In my simple thinking I’ve thought that you still have the GPS-information of each waypoint, so to restart a route a planned waypoint with his GPS-coordinates should be possible?
The task would be "bring me from my actual point to waypoint nr. - and then follow the route as planned… "
What do you think about this?
Would this be possible in a further development?
Thanks and best regards
Juschka

In the past there was a note from devemux86 to configure the target for recalculation of the route when you are off the route. This seems to be a good idea.

Currently in navi mode when you are off the route the navi info Panels are empty and the “blue arrow” appears. Touching the “blue arrow” sometimes a Dialog appears and/or recalculation is started when you have Internet Connection.


To continue the note from devemux86 perhaps you could use the blue arrow for two Actions:

  1. short touch: starting the calculation (when possible due to Internet Connection and/or on-/off-line calculation (in future).
  2. Long touch: opening a Dialog (draft see below) and after giving ok starting the calculation (as mentioned under 1.)

Draft of Dialog:

Content of the Dialog:
1. A button to save the actual route. The Name of the route file could be automatically a timestamp and the Format could be *.kurviger. So you don’t have to manipulate more dialogs. When the user wants other names or formats e.g. he can Import the route file later and Export it with other Name and Format.
2. Short note what to do.
3. Selection of target via radiobuttons. In the draft you find some items. Juschka had a nice idea, to ad a selection item: “Waypoint no …”.
4. Bringing back note (red in draft).

Pre activatet selection item Comes from the Settings mentioned below.

Similar to this draft the selection Dialog in the Routing Settings for Off The Route Bringing Back Calculation could be. There you don’t need the save button (1) and bringing back note (4).

That’s only a proposal without knowing what is possible or not. Thanks to the developers what they are giving us in app and web.

2 Likes