# App: Waypoint types

**URL:** <https://forum.kurviger.com/t/app-waypoint-types/2821>\
**Category:** Implemented features\
**Tags:** implemented\
**Created:** [March 16, 2020, 5:08pm UTC](https://forum.kurviger.com/t/app-waypoint-types/2821 "2020-03-16T17:08:29Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**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 8, 2020, 8:13am UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/21 "2020-04-08T08:13:27Z")

</div>

> [@SchlesiM](#):
>
> One question prior to my first tests: will the options of the rerouting mode distinguish between regular waypoints and shaping points?

Rerouting currently uses all waypoint types: stopover + shaping.  
If skip the shaping points, then reroutes are different from planned old routes.

Does that make sense or navigators usually skip shaping points in rerouting?

---

<div class="post-metadata">

**Author:** ![SchlesiM](https://forum.kurviger.com/user_avatar/forum.kurviger.com/schlesim/32/1080_2.png) [@SchlesiM](https://forum.kurviger.com/u/SchlesiM)\
**Post date:** [April 8, 2020, 9:20am UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/22 "2020-04-08T09:20:53Z")

</div>

> [@devemux86](#):
>
> Does that make sense or navigators usually skip shaping points in rerouting?

Yes, in my opinion this makes sense (at least as a configurable option). Because even if you’re forced to take a detour you still want to reach/visit regular waypoints (as they’re somehow mandatory parts of your route). But this is not always the case with shaping points which were used to affect the “layout” of your route because the detour anyhow changed the circumstances.

I think the different handling of waypoints and shaping point in case of rerouting would be one of the most essential benefits of those both types.

---

<div class="post-metadata">

**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 8, 2020, 10:16am UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/23 "2020-04-08T10:16:18Z")

</div>

> [@SchlesiM](#):
>
> I think the different handling of waypoints and shaping point in case of rerouting would be one of the most essential benefits of those both types.

Perhaps, though in a round trip with start / end and 1-2 shaping points,  
if not use shaping points, then rerouting leads straight back to the start.

So seems like having an extra setting: use shaping points in rerouting?

---

<div class="post-metadata">

**Author:** ![rumbrummer](https://forum.kurviger.com/user_avatar/forum.kurviger.com/rumbrummer/32/113_2.png) [@rumbrummer](https://forum.kurviger.com/u/rumbrummer)\
**Post date:** [April 8, 2020, 10:36am UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/24 "2020-04-08T10:36:37Z")

</div>

Hi,

my Navigator 5 has a good strategy (from my point of view): If you cross the route between two points and there are no ViaPoints “undone” before the crossing point, all ShapingPoints before are skipped.

“Crossing” also includes turning onto the calculated route after riding a detour “manually”.

To skip ViaPoints you have to press a skip button.

Regards Markus

---

<div class="post-metadata">

**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 8, 2020, 10:44am UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/25 "2020-04-08T10:44:46Z")

</div>

Automatic skip of waypoints (of any type) and resume of route continue to work like before.

The basic feature with waypoint types, like mentioned above and in [other navigators](https://forum.kurviger.com/t/app-waypoint-types/2821/3) is:

_“Shaping points are any position along a route that will not alert you when you arrive.”_  
(but they continue to shape the route path)

---

<div class="post-metadata">

**Author:** ![rumbrummer](https://forum.kurviger.com/user_avatar/forum.kurviger.com/rumbrummer/32/113_2.png) [@rumbrummer](https://forum.kurviger.com/u/rumbrummer)\
**Post date:** [April 8, 2020, 10:58am UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/26 "2020-04-08T10:58:46Z")

</div>

Hi,  
I do not fully agree: In Garmin Navigators (Zumo and also BMW Navigators) one big difference between ShapingPoints and ViaPoints is, that ShapingPoints do not have to be “reached”, they are skipped automatically if you drive a detour etc.  
ViaPoints have to be reached - so if you do not Skip them manually, Garmin Navigators might guide you backwards on the planned route to the “not reached” ViaPoint.  
From my point of view this is the most important difference between those 2 kind of points…  
Regards Markus

---

<div class="post-metadata">

**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 8, 2020, 11:09am UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/27 "2020-04-08T11:09:24Z")

</div>

You can already use the “Next unvisited waypoint” option for that kind of rerouting.

> [@rumbrummer](#):
>
> this is the most important difference between those 2 kind of points

This is more if a navigator is flexible allowing automatic skip of waypoints or not (a different option).

We cannot fill the UI or the implementation with so many workflows, must use some sane defaults.

The above discussion started more about what happens with _next waypoint types_ during rerouting.

---

<div class="post-metadata">

**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 8, 2020, 12:05pm UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/28 "2020-04-08T12:05:33Z")

</div>

> [@SchlesiM](#):
>
> I think the different handling of waypoints and shaping point in case of rerouting would be one of the most essential benefits of those both types.

I 100% agree with this.

- stopover points (or viaPoints) → must not be skipped automaticaly
- shaping points → can be skipped automatically

My ideal rerouting strategy would be a combination between “_next unvisited waypoint_” and “_nearest waypoint_” something like this:

1. Use _nearest waypoint_  
unless a “stopover waypoint” would be skipped

2. Then use “next unvisited stopover point”

---

<div class="post-metadata">

**Author:** ![SchlesiM](https://forum.kurviger.com/user_avatar/forum.kurviger.com/schlesim/32/1080_2.png) [@SchlesiM](https://forum.kurviger.com/u/SchlesiM)\
**Post date:** [April 8, 2020, 12:13pm UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/29 "2020-04-08T12:13:27Z")

</div>

> [@Kurviger 1.13.16 (Beta)](https://forum.kurviger.com/t/kurviger-1-13-16-beta/2855/38):
>
> ViaPoints have to be reached - so if you do not Skip them manually, Garmin Navigators might guide you backwards on the planned route to the “not reached” ViaPoint.

> [@Kurviger 1.13.16 (Beta)](https://forum.kurviger.com/t/kurviger-1-13-16-beta/2855/35):
>
> So seems like having an extra setting: use shaping points in rerouting?

> [@linux-user](#):
>
> stopover points (or viaPoints) → must not be skipped automaticaly

That’s exactly what I meant by asking how shaping points will be handled in case of rerouting.

In my opinion a differentiation would be a helpful (and consequent) addition to the way those both types are displayed.

Therefore there would be 2 types of waypoints:

- shaping-points: can be omitted in case of rerouting
- visit-points (or via-points): cannot be ommitted automatically (only the user deletes them, changes them into a shaping-point or uses the “skip next waypoint” function)

Would solve various situations (like already discussed [here](https://forum.kurviger.com/t/rerouting-changes-the-planned-route/1801/36) or [here](https://forum.kurviger.com/t/rerouting-changes-the-planned-route/1801/48), for example).

I think there wouldn’t be any new/addtional UI elements necessary to support such a behaviour because its just the internal logic of the rerouting algorithm.

---

<div class="post-metadata">

**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 8, 2020, 12:18pm UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/30 "2020-04-08T12:18:00Z")

</div>

So that just means that shaping points, as they don’t participate in turn instructions / voice guidance,  
they shouldn’t participate at all also in rerouting. Rerouting uses only via points (like in 1.12 version).

---

<div class="post-metadata">

**Author:** ![SchlesiM](https://forum.kurviger.com/user_avatar/forum.kurviger.com/schlesim/32/1080_2.png) [@SchlesiM](https://forum.kurviger.com/u/SchlesiM)\
**Post date:** [April 8, 2020, 12:34pm UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/31 "2020-04-08T12:34:07Z")

</div>

Yes, that’s the reaon why I would vote for an additional options in the rerouting settings:

- nearest point in route
- nearest waypoint _(means: both types)_
- next unvisited waypoint _(means: both types)_
- next unvisited visit-point _(means: without considering shaping-points)_

To be more specific: if the last (new) option is set, rerouting should of course only omit all shaping-points before the next unvisited visit-point - not those behind it. Because a detour/rerouting should only affect the part of my route which leads to my next unvisited visit-point, not the whole route. This way the impact will remain as minimal as possible. But also as reasoned as necessary.

Why a new option? Because this most probably still depends on the way someone uses the two types of waypoints. I’m pretty sure that there will be differences between - for example - (former?) Garmin users and those who are using Kurviger as straight forward and simple as possible (and therefore won’t even use shaping-points at all).

---

<div class="post-metadata">

**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 8, 2020, 12:37pm UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/32 "2020-04-08T12:37:31Z")

</div>

_(moved discussion in its related feature topic)_

---

<div class="post-metadata">

**Author:** ![SchlesiM](https://forum.kurviger.com/user_avatar/forum.kurviger.com/schlesim/32/1080_2.png) [@SchlesiM](https://forum.kurviger.com/u/SchlesiM)\
**Post date:** [April 8, 2020, 12:40pm UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/33 "2020-04-08T12:40:02Z")

</div>

> [@devemux86](#):
>
> (moved discussion in its related feature topic)

I really like and appreciate the way you take care about keeping topics and discussions structured and well organized 😄.

---

<div class="post-metadata">

**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 8, 2020, 12:48pm UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/34 "2020-04-08T12:48:41Z")

</div>

That seems complicated and there are still the “Avoid roadblock” and “Skip next waypoint” reroutings, we cannot have multiple options in every UI rerouting process.

Also how about round trips, are their auto generated intermediate points supposed to be shaping points (now they are) or yellow via points? If they are shaping points then a rerouting that skips them will lead back to start.

So probably the most simple workflow is to keep the UI options unmodified.  
And use shaping points only for rerouting from nearest / next waypoint to the end, so can maintain the rest route geometry.

---

<div class="post-metadata">

**Author:** ![SchlesiM](https://forum.kurviger.com/user_avatar/forum.kurviger.com/schlesim/32/1080_2.png) [@SchlesiM](https://forum.kurviger.com/u/SchlesiM)\
**Post date:** [April 8, 2020, 1:00pm UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/35 "2020-04-08T13:00:56Z")

</div>

> [@devemux86](#):
>
> That seems complicated and there are still the “Avoid roadblock” and “Skip next waypoint” reroutings, we cannot have multiple options in every UI rerouting process.

I can understand your thoughts quite well. Nevertheless it would really improve Kurviger’s functionality and make the two waypoint types much more useful. I think other manufacturers (like Garmin) had similar motivations for implementing such features in their rerouting algorithms.

> [@devemux86](#):
>
> Also how about round trips, are their auto generated intermediate points supposed to be shaping points (now they are) or yellow via points? If they are shaping points then a rerouting that skips them will lead back to start.

In my opinion a regular (visit) waypoint should always be default (also if creating roundtrips). Because shaping-points have a somehow less obligatory character so that the user should decide about it.

> [@devemux86](#):
>
> So probably the most simple workflow is to keep the UI options unmodified.  
> And use shaping points only for rerouting from nearest / next waypoint to the end, so can maintain the rest route geometry.

Sounds like a reasonable solution and helps to keep things as simple as possible. So the existing option “next unvisited waypoint” (for example) would result in a behaviour like my suggested “next unvisited visit-point”, right? I think that would be absolutely sufficient.

---

<div class="post-metadata">

**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 8, 2020, 1:05pm UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/36 "2020-04-08T13:05:33Z")

</div>

> [@SchlesiM](#):
>
> In my opinion a regular (visit) waypoint should always be default (also if creating roundtrips). Because shaping-points have a somehow less obligatory character so that the user should decide about it.

Round trip intermediate points are set for shaping the route, so they’re meant as shaping points.  
But since that could produce other rerouting issues, I can revert them back to via points.

> [@SchlesiM](#):
>
> So the existing option “next unvisited waypoint” (for example) would result in a behaviour like my suggested “next unvisited visit-point”, right?

Exactly, like you described:  
(I will see how this can be implemented)

> [@SchlesiM](#):
>
> rerouting should of course only omit all shaping-points before the next unvisited visit-point - not those behind it. Because a detour/rerouting should only affect the part of my route which leads to my next unvisited visit-point, not the whole route. This way the impact will remain as minimal as possible.

---

<div class="post-metadata">

**Author:** ![SchlesiM](https://forum.kurviger.com/user_avatar/forum.kurviger.com/schlesim/32/1080_2.png) [@SchlesiM](https://forum.kurviger.com/u/SchlesiM)\
**Post date:** [April 8, 2020, 1:12pm UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/37 "2020-04-08T13:12:16Z")

</div>

> [@devemux86](#):
>
> Round trip intermediate points are there just for shaping the route, so they should be shaping points.  
> But since that could generate other rerouting problems, I can revert them back to via points.

Exactly. From a human point of view you’re absolutely right, of course. But from a “computer’s point of view” this may lead to loss of the initial intended routing plan.

---

<div class="post-metadata">

**Author:** ![zaphod\_42](https://forum.kurviger.com/user_avatar/forum.kurviger.com/zaphod_42/32/499_2.png) [@zaphod\_42](https://forum.kurviger.com/u/zaphod_42)\
**Post date:** [April 8, 2020, 1:30pm UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/38 "2020-04-08T13:30:30Z")

</div>

One of my friends returned his BMW navigator because he thought  
a study of computer science was necessary for the operation.  
Are we not moving in the same direction here? (And I’m not kidding!)

---

<div class="post-metadata">

**Author:** ![SchlesiM](https://forum.kurviger.com/user_avatar/forum.kurviger.com/schlesim/32/1080_2.png) [@SchlesiM](https://forum.kurviger.com/u/SchlesiM)\
**Post date:** [April 8, 2020, 2:17pm UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/39 "2020-04-08T14:17:08Z")

</div>

> [@zaphod\_42](#):
>
> Are we not moving in the same direction here? (And I’m not kidding!)

No, I don’t think so. But for this reason it is very important that things should be kept as simple as possible (and this is something devemux86 is really very aware of). And to keep in mind that all default options and functions should work properly for “basic” users without the need to “learn” too much aspects.

But if someone is willing to “dive deeper” he will be rewarded by having a really powerful tool which can be adjusted for his very personal and individual needs.

And there’s a difference between discussing “internal” algorithms and using them later as a regular user (when all those “internal” aspects aren’t visible any longer but instead the app just “works”).

---

<div class="post-metadata">

**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 11, 2020, 2:42pm UTC](https://forum.kurviger.com/t/app-waypoint-types/2821/40 "2020-04-11T14:42:14Z")

</div>

> [@SchlesiM](#):
>
> In my opinion a regular (visit) waypoint should always be default (also if creating roundtrips). Because shaping-points have a somehow less obligatory character so that the user should decide about it.

> [@SchlesiM](#):
>
> rerouting should of course only omit all shaping-points before the next unvisited visit-point - not those behind it. Because a detour/rerouting should only affect the part of my route which leads to my next unvisited visit-point, not the whole route. This way the impact will remain as minimal as possible.

The discussed improvements were implemented in [Kurviger 1.13.16 (Beta)](https://forum.kurviger.com/t/kurviger-1-13-3-beta/2855).

[Previous page](https://forum.kurviger.com/t/app-waypoint-types/2821.md?page=1)

[Next page](https://forum.kurviger.com/t/app-waypoint-types/2821.md?page=3)
