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

App: Improve rerouting at start

Discussion Implemented features
,
#1

When you start navigation while being away from route you have the choice between:

  • rerouting to start.
  • rerouting to standard.
    Standard is then derived from the Rerouting options in the settings.

When you have set “Next unvisited waypoint” in rerouting options, then you will be routet to waypoint1 when you choose standard - right? This is usually not what you want.

May I suggest to change the behavior at start of navigation?

Instead of using the Rerouting options from the settings let the user choose only between two options at start of navigation:

  • Start
  • Nearest point on route

I cannot imagine that anybody would want another rerouting choice at start of navigation.
Additionally it would be clearer to understand, as many people probably don’t know what standard is meaning here.

Manfred

1 Like
Kurviger 1.13.16 (Beta)
Kurviger 1.13.16 (Beta)
Website and user location
Kurviger 1.13.16 (Beta)
Rerouting issues
Rerouting issues
Kurviger 1.13.17
#2

That was the old implementation, before the various rerouting modes were introduced.

That depends on what each user wants at navigation start?

I’m not very happy with that dialog either, but we need something simple, not 1+3 options (start + rerouting modes) all together.

#3

fully agree, “Start” = begin of the route and “Standard” I would expect the routing to be always to the nearest wp from the actual GPS position, independend of what rerouting option is set.

Rerouting issues
#4

What do other users think about that change?

#5

I hope all the other users comment this topic. I find it pretty much important. For example when my round trip was destroyed by deleting and skipping waypoints, this had at least helped me to easily find back to my planned route after having reloaded it. But instead it guided me to the start of the Route or wp1 in “Standard” Mode. And without the right spectacles i could not even read the numbers of the route with the consequence of not knowing how many waypoints to delete until I get back to my track again. Additionally if there is no internet connection by accident in this area, it deletes no waypoints manually.

Using “Standard” in the sense of nearest next GPS waypoint from the actual GPS position, would be the most natural way in my point of view.

#6

Which is the suggestion (of the two)?

  • Nearest point on route: nearest coordinates on the route path (not waypoint)
  • Nearest waypoint: nearest waypoint (via points, destination) of the route
#7

My suggestion would be:
Nearest point on route : nearest coordinates on the route path (not waypoint)

Edit:
Nearest point on route usually would insert a new WP on the route path.
If the user wants Nearest waypoint then a “skip next waypoint” afterwards would do the job.

Manfred

Kurviger 1.13.16 (Beta)
App: Improve rerouting settings
#8

I see it more connected with / after the rerouting options suggestion discussed here:

https://forum.kurviger.de/t/app-rerouting-options/1934/15

Kurviger 1.13.16 (Beta)
#9

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.

#10

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

1 Like
#11

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

#12

Available in Kurviger 1.13.5 (Beta).

1 Like
#13

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

Rerouting problem at start of navigation
#14

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
or
nearest waypoint

Edit:
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.

#15

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(?).

#16

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:

#17

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
#18

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

#19

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.

#20

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