App: Improve rerouting at start

Same here, I find this the best option for “Standard” when starting outside of the planned route. But don’t delete Start, this can also be useful depending on the tour… but I would find this more useful as a general setting (if others agree and it is not too much work), because the text size is too smal for motorcycle gloves and old guys like me who need spectacles for reading (not for driving). While driving I find it better to keep things simple. When I start the tour outside of the planned route, the app automatically can find the nearest point on route by default. If I want it differently from Start I can change the setting. At the moment with tiny buttons there are just 2 more possible faulty entries.

Now it inserts a shaping point, so it is not problem for turn instructions and navigation.

1 Like

Nice little improvement. :slightly_smiling_face:
BTW: Nearest point on route has never made any issues at start of navigation.

Available in Kurviger 1.13.5 (Beta).

1 Like

There can be corner cases like here, so do we need more rerouting options at start of navigation?

IMO ideally there should be no question at all at start of navigation.

If I am somewhere near the route (but not on the route) maybe after a break, I want to be guided back to the route as seamless as possible.
Whether this is “nearest point on route” or “nearest waypoint” isn’t too important. But not both.
Keep the start menu as simple as possible!

Some people seem to expect start as an option as well, so I would offer start and one other option.

nearest point on route
nearest waypoint

Despite the issues dicussed here I still prefer nearest point on route
Edit 2:
Maybe onother option could be “nearest unvisited waypoint”.
So that after a break, you won’t be guided backwards, providet that the route is still in memory.

It’s recommended to avoid placing points close to intersections, so nearest instruction could be problematic.

The most sane extra option (besides the start) seems to be the nearest waypoint(?).

I think, you have to differentiate between manually placing a waypoint, and doing this by a program i.e. the program that has created the turn instruction.

  • manually created waypoints are not exactly at the intersection point, and therefore can have strange effects.
  • when you use "nearest instruction*, this point has been created by the router itself.
    So it should be exactly at the correct place, the router would expect it?
    Well, at least if you use the same router and routing graph that has created the original route. :thinking:
    This might be not true for offline routing with different routing engine.

At least users won’t be surprised :wink:

Setting new waypoints on each rerouting request is never future-proof, so “Nearest route point” can never be safe either at start (discussed here) or during navigation and removing it seems the most sane choice everywhere, falling back to:

  • Start
  • Nearest waypoint

Probably the easiest way.
The beauty of “nearest waypoint” is, that users would understand what is happening, and probably don’t complain - even if they might not like the result.

My concern is the following situation:

At a break along the route, I would stop navigation and maybe even close the app.
My position may be 100m away from route.
Then when I start navigation again, app may route back to a waypoint I have already visited, because the history of visited waypoints has been lost then.
The “nearest waypoint” may be many km back.

“Nearest point on route” would route back only a few 100m, even in corner cases like here

Nicely described and what we need to provide for a robust result.

In such cases, sane is also to resume the route first, instead of reroute on each small stop.

That would require:

  • App does have the route in memory, which is already the case even after closing the app.
  • App does have the history of visited waypoints still in memory ?!

:bulb: Then app could continue navigation without any further question :thinking:
That would be my ideally behavior described above

Let’s not move away from the discussion’s purpose, what are the most useful start options.

When be away from route, navigation always asks for rerouting, it’s fundamental workflow.

When be near the route, can cancel rerouting at start, resume route & continue navigation.
There is no need to do reroutings for small stops / deviations & risk serious route changes.

1 Like

Currently v.1.13.5(beta) when start navigation away from route it looks like this
(with automatic rerouting enabled)

So we have the choice between

  • Start
  • Nearest point on route

and disable (automatic rerouting)

Do you mean that disable should be replaced by resume?
Navigation would then pause automatic rerouting, until I am back on the route for the first time.
And then continue with automatic rerouting :thinking:

I think, I would like such a behavior.

1 Like

I replaced it with “Cancel” so that can skip that rerouting action, resume navigation on your own and automatic rerouting continues from there. So workflow can be more flexible based on user preference.

Available in Kurviger 1.13.6 (Beta).

I did some testing with Kurviger 1.13.6 (Beta) around my home base, to simulate this situation:

The “flexible version” (nearest waypoint) behaves very nicely.
If 100m away from route, hit cancel and navigation continues as soon as you are back on your route.

The “strict navigation” works if you start navigation where you paused the route.
It is a bit tricky if you start navigation 100m away from route.

Would it be possible to add a “resume” button (maybe additionally to cancel) as proposed above

Maybe this scenario isn’t too realistic. :thinking:
I think in most cases, you would start navigation at the exact place where you left your bike.
What do others think?

Edit 2:
I think, I had such situations in the past e.g. at a gas station:

  • stop navigation at the gas pump
  • after filling up move the bike a few meters without navigation. e.g. to get some eating.
  • Bingo, I am a few meters away from route.

More buttons usually are not nice, they complicate UI and implementation. :slightly_smiling_face:

Can always stop navigation and restart it anytime later.
Now can cancel rerouting at start & so “resume” route.

So resume already exists in some way, only strict navigation has its own rules.
It’s difficult to bend them & want making it flexible again, defeating its purpose.

1 Like

Ich hätte nur eine Frage zum Stoppen der Navigation, zB an der Tankstelle. Was verstehst Du unter stoppen, beendest Du die Navigation komplett? Ich lass kurviger immer im Hintergrund laufen (runder Kreis bei meinem Handy).
I would only have one question about stopping navigation, e.g. at the gas station. What do you mean by stop, do you stop the navigation completely? I always let the navigation run in the background (round circle on my mobile phone).

Here navigation is stopped i.e. the symbol (in the red circle) is not blue anymore.
I usually do this at any pause of the route e.g. at a gas station.

  • because I don’t want to hear “route missed” messages at the cashier
  • because I hope, that this would save battery