# App: Improve rerouting at start **URL:** \ **Category:** Implemented features\ **Tags:** implemented\ **Created:** [March 28, 2020, 6:51pm UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875 "2020-03-28T18:51:33Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![linux-user](https://forum.kurviger.com/user_avatar/forum.kurviger.com/linux-user/32/56_2.png) [@linux-user](https://forum.kurviger.com/u/linux-user)\ **Post date:** [March 28, 2020, 6:51pm UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/1 "2020-03-28T18:51:33Z")
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](https://forum.kurviger.com/t/app-rerouting-options/1934) 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](https://forum.kurviger.com/t/app-rerouting-options/1934) 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 ---
**Author:** ![devemux86](https://forum.kurviger.com/user_avatar/forum.kurviger.com/devemux86/32/6239_2.png) [@devemux86](https://forum.kurviger.com/u/devemux86)\ **Post date:** [March 28, 2020, 7:00pm UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/2 "2020-03-28T19:00:54Z")
That was the old implementation, before the various rerouting modes were introduced. > [@linux-user](#): > > I cannot imagine that anybody would want another rerouting choice at start of navigation. 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. ---
**Author:** ![Tom](https://forum.kurviger.com/user_avatar/forum.kurviger.com/tom/32/168_2.png) [@Tom](https://forum.kurviger.com/u/Tom)\ **Post date:** [April 20, 2020, 1:16pm UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/3 "2020-04-20T13:16:09Z")
> [@App: rerouting options at start of navigation Android App](#): > > 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? 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. ---
**Author:** ![devemux86](https://forum.kurviger.com/user_avatar/forum.kurviger.com/devemux86/32/6239_2.png) [@devemux86](https://forum.kurviger.com/u/devemux86)\ **Post date:** [April 20, 2020, 1:22pm UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/4 "2020-04-20T13:22:19Z")
What do other users think about that change? ---
**Author:** ![Tom](https://forum.kurviger.com/user_avatar/forum.kurviger.com/tom/32/168_2.png) [@Tom](https://forum.kurviger.com/u/Tom)\ **Post date:** [April 21, 2020, 4:16am UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/5 "2020-04-21T04:16:59Z")
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. ---
**Author:** ![devemux86](https://forum.kurviger.com/user_avatar/forum.kurviger.com/devemux86/32/6239_2.png) [@devemux86](https://forum.kurviger.com/u/devemux86)\ **Post date:** [April 21, 2020, 6:46am UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/6 "2020-04-21T06:46:19Z")
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 ---
**Author:** ![linux-user](https://forum.kurviger.com/user_avatar/forum.kurviger.com/linux-user/32/56_2.png) [@linux-user](https://forum.kurviger.com/u/linux-user)\ **Post date:** [April 21, 2020, 6:48am UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/7 "2020-04-21T06:48:58Z")
[My suggestion](https://forum.kurviger.com/t/app-rerouting-options-at-start-of-navigation/2875) 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 ---
**Author:** ![devemux86](https://forum.kurviger.com/user_avatar/forum.kurviger.com/devemux86/32/6239_2.png) [@devemux86](https://forum.kurviger.com/u/devemux86)\ **Post date:** [April 21, 2020, 1:04pm UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/8 "2020-04-21T13:04:30Z")
I see it more connected with / after the rerouting options suggestion discussed here: [https://forum.kurviger.com/t/app-rerouting-options/1934/15](https://forum.kurviger.com/t/app-rerouting-options/1934/15) ---
**Author:** ![Tom](https://forum.kurviger.com/user_avatar/forum.kurviger.com/tom/32/168_2.png) [@Tom](https://forum.kurviger.com/u/Tom)\ **Post date:** [April 21, 2020, 7:01pm UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/9 "2020-04-21T19:01:18Z")
> [@linux-user](#): > > [My suggestion](https://forum.kurviger.com/t/app-rerouting-options-at-start-of-navigation/2875) would be: > **Nearest point on route** : nearest coordinates on the route path (not waypoint) 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. ---
**Author:** ![devemux86](https://forum.kurviger.com/user_avatar/forum.kurviger.com/devemux86/32/6239_2.png) [@devemux86](https://forum.kurviger.com/u/devemux86)\ **Post date:** [April 23, 2020, 11:19am UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/10 "2020-04-23T11:19:58Z")
> [@linux-user](#): > > _Nearest point on route_ usually would insert a new WP on the route path. Now it inserts a [shaping point](https://forum.kurviger.com/t/app-waypoint-types/2821), so it is not problem for turn instructions and navigation. ---
**Author:** ![linux-user](https://forum.kurviger.com/user_avatar/forum.kurviger.com/linux-user/32/56_2.png) [@linux-user](https://forum.kurviger.com/u/linux-user)\ **Post date:** [April 23, 2020, 4:58pm UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/11 "2020-04-23T16:58:21Z")
> [@devemux86](#): > > Now it inserts a [shaping point](https://forum.kurviger.com/t/app-waypoint-types/2821) Nice little improvement. 🙂 BTW: _Nearest point on route_ has never made any issues **at start of navigation**. ---
**Author:** ![devemux86](https://forum.kurviger.com/user_avatar/forum.kurviger.com/devemux86/32/6239_2.png) [@devemux86](https://forum.kurviger.com/u/devemux86)\ **Post date:** [April 26, 2020, 12:32pm UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/12 "2020-04-26T12:32:32Z")
Available in [Kurviger 1.13.16 (Beta)](https://forum.kurviger.com/t/kurviger-1-13-5-beta/2855). ---
**Author:** ![devemux86](https://forum.kurviger.com/user_avatar/forum.kurviger.com/devemux86/32/6239_2.png) [@devemux86](https://forum.kurviger.com/u/devemux86)\ **Post date:** [April 27, 2020, 10:39am UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/13 "2020-04-27T10:39:57Z")
There can be corner cases like [here](https://forum.kurviger.com/t/app-rerouting-problems/3086), so do we need more rerouting options at start of navigation? ---
**Author:** ![linux-user](https://forum.kurviger.com/user_avatar/forum.kurviger.com/linux-user/32/56_2.png) [@linux-user](https://forum.kurviger.com/u/linux-user)\ **Post date:** [April 28, 2020, 8:11am UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/14 "2020-04-28T08:11:04Z")
> [@devemux86](#): > > 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_ or _nearest waypoint_ Edit: Despite the issues dicussed [here](https://forum.kurviger.com/t/rerouting-problem-at-start-of-navigation/3086) 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. ---
**Author:** ![devemux86](https://forum.kurviger.com/user_avatar/forum.kurviger.com/devemux86/32/6239_2.png) [@devemux86](https://forum.kurviger.com/u/devemux86)\ **Post date:** [May 2, 2020, 8:43am UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/15 "2020-05-02T08:43:37Z")
It’s [recommended](https://docs.kurviger.de/app/faq/navigate_incorrect_voice_prompt) 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(?). ---
**Author:** ![linux-user](https://forum.kurviger.com/user_avatar/forum.kurviger.com/linux-user/32/56_2.png) [@linux-user](https://forum.kurviger.com/u/linux-user)\ **Post date:** [May 2, 2020, 11:33am UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/16 "2020-05-02T11:33:45Z")
> [@devemux86](#): > > It’s [recommended](https://docs.kurviger.de/app/faq/navigate_incorrect_voice_prompt) to avoid placing points close to intersections, so nearest instruction could be problematic. 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. 🤔 This might be not true for offline routing with different routing engine. > [@devemux86](#): > > The most sane extra option (besides the start) seems to be the nearest waypoint(?). At least users won’t be surprised 😉 ---
**Author:** ![devemux86](https://forum.kurviger.com/user_avatar/forum.kurviger.com/devemux86/32/6239_2.png) [@devemux86](https://forum.kurviger.com/u/devemux86)\ **Post date:** [May 2, 2020, 11:50am UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/17 "2020-05-02T11:50:03Z")
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](https://forum.kurviger.com/t/app-improve-rerouting-options/3107) and removing it seems the most sane choice everywhere, falling back to: - Start - Nearest waypoint ---
**Author:** ![linux-user](https://forum.kurviger.com/user_avatar/forum.kurviger.com/linux-user/32/56_2.png) [@linux-user](https://forum.kurviger.com/u/linux-user)\ **Post date:** [May 2, 2020, 5:53pm UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/18 "2020-05-02T17:53:00Z")
> [@devemux86](#): > > 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](https://forum.kurviger.com/t/rerouting-problem-at-start-of-navigation/3086/14) ---
**Author:** ![devemux86](https://forum.kurviger.com/user_avatar/forum.kurviger.com/devemux86/32/6239_2.png) [@devemux86](https://forum.kurviger.com/u/devemux86)\ **Post date:** [May 2, 2020, 5:58pm UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/19 "2020-05-02T17:58:10Z")
> [@linux-user](#): > > 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. Nicely described and what we need to provide for a robust result. > [@linux-user](#): > > At a break along the route, I would stop navigation and maybe even close the app. In such cases, sane is also to resume the route first, instead of reroute on each small stop. ---
**Author:** ![linux-user](https://forum.kurviger.com/user_avatar/forum.kurviger.com/linux-user/32/56_2.png) [@linux-user](https://forum.kurviger.com/u/linux-user)\ **Post date:** [May 2, 2020, 6:45pm UTC](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875/20 "2020-05-02T18:45:02Z")
> [@linux-user](#): > > > [@linux-user](#): > > > > At a break along the route, I would stop navigation and maybe even close the app. > > 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 ?! 💡 Then app could continue navigation **without any further question** 🤔 That would be my ideally behavior described [above](https://forum.kurviger.com/t/app-improve-rerouting-options-at-start-of-navigation/2875/14) [Next page](https://forum.kurviger.com/t/app-improve-rerouting-at-start/2875.md?page=2)