App: Waypoint types

[devemux86]

@grua

But configurable whether shaping points are taken into account when rerouting or not.

We cannot add more options. Already the “Waypoints in instructions” option seems unnecessary.
(and adds severe maintenance problems)

We must finalize the workflow with some sane defaults, like most routers work and users expect.

[devemux86]

So the only needed change seems to be that shaping points must participate in rerouting,
even if they are before the next via point. Does everything else work the way we need it?

[linux-user]

Well, this is then different as proposed above:
here and here

If you don’t want to have different rerouting strategies (strict for via points, flexible for shaping points)
than, the only difference (between via points an shaping points) would be:

Shaping points:

• No name, only numbered
• decent marking (only a point with number)
• not mentioned in turn instructions

Probably easier to implement

[devemux86]

@linux-user

Well, this is then different as proposed above

Well, we cannot fill the app with options that will make its maintenance impossible.

But we must examine other routers, participate in discussion and make 1 decision.

[grua]

• Turn instructions for all via points (named or not)
• No turn instructions for all shaping
• shaping points must participate in rerouting, even if they are before the next via point

this would be OK for me

[devemux86]

@grua

Turn instructions for all via points (named or not)

That seems valid (and was my first implementation).
e.g. now a via point must have a name to appear in next waypoint’s distance / time panel.

Or are there any routers that allow turn instructions only on via points with custom names?

@grua

shaping points must participate in rerouting, even if they are before the next via point

In that case the via points and shaping points will have the same weight in rerouting.
(which could be the right thing to do)

i.e. “Skip next waypoint” will skip next point (via or shaping).
Now it skips next via point (omitting the intermediate shaping points).

[WalterG]

@devemux86

In that case the via points and shaping points will have the same weight in rerouting.
(which could be the right thing to do)

i.e. “Skip next waypoint” will skip next point (via or shaping).

For me that would be the prefered rule.

Then the advantages of Via points AND Shaping points can be used by the users.

Some users until now didn’t recognize the advantages of the Shaping points. And those which don’t like the Shaping points can work with the Via points without using Shaping points.
But there are users which like the benefits of Shaping points.

The Don’t-like-shaping-point-users should be tolerant to the Like-shaping-point-users and the introduction of the shaping points. They don’t loose any benefits of the earlier working of Via points.

[Corinna]

As far as I understand where this discussion is heading to, there should be only two types of waypoints, those mentioned in turn instructions (via points) and those not mentioned (shaping points). No differences otherwise.

I think that makes sense, but I’d like to point out that turn instructions are only required for some waypoints. The typical route will have mainly shaping points and only a couple of via points. Therefore the default generated by the website should be the shaping point and the user should convert the few via points manually.

I’d also like to point out that this all is a bit of a slippery slope. Existing kurviger routes consist entirely of via points since shaping points didn’t exist a couple of weeks ago. So when importing an old kurviger route, all via points suddenly are mentioned in turn instructions when they where not mentioned before. This sounds like surprising, backward-incompatible behaviour in the UI to me.

Corinna

[linux-user]

@Corinna

So when importing an old kurviger route, all via points suddenly are mentioned in turn instructions

I think, this is the behavior in current production version of the app until V1.12.x
Only V1.13.x (beta) has different behavior.

In current beta, user can change all waypoints into shaping points with one click in the waypoint list.
So no compatibility problem.

[devemux86]

@linux-user

In current beta, user can change all waypoints into shaping points with one click in the waypoint list.
So no compatibility problem.

That’s right and there is also the option “Settings | Routing | Waypoints in instructions”.

[grua]

@Corinna

The typical route will have mainly shaping points and only a couple of via points. Therefore the default generated by the website should be the shaping point and the user should convert the few via points manually.

I agree with that!

[devemux86]

Let’s discuss here for app implementation.

Website implementation has its own topic:

Website: Waypoint types

Wenn ich eine Route plane, besteht sie zunächst aus POIs, also interessanten Zielen, die ich anfahren möchte. Aber nicht immer Routet kurviger so, wie ich gerne fahren möchte. Deshalb setze ich in diesem Fall einen Zwischenpunkt und verschiebe den Routenverlauf. Das Blöde ist nun, dass dieser Zwischenpunkt genauso aussieht wie alle anderen Punkte. Das macht die Tour in der Ansicht sehr unübersichtlich. Deshalb hätte ich einen oder zwei Wünsche: Am liebsten hätte ich es, wenn ich die Route vers…

[devemux86]

Kurviger 1.13.11 (Beta) has some changes:

• Via points (named or not) participate properly in turn instructions and navigation (panels).
  Shaping points are the ones that obviously don’t alert on arrival.

• Via + shaping points participate equally in navigation actions, like rerouting, skip next, etc.

• Option “Settings | Routing | Waypoints in instructions” remains for those who need it.
  And can change all waypoint types simultaneously with one click in the waypoint list.

All that seems more friendly & less confusing to users?
And more compatible to other popular routing services.

[Corinna]

What I mean is this: Importing an old route now requires an extra step by the user to get the original behaviour. And you actually have to remember that every time you import an old route and before starting navigation. That’s a surprising change in the UI which ideally should be avoided. Again, I’m just pointing this out for consideration. The general direction this is taking is fine, imho.

Corinna

[devemux86]

@Corinna

So when importing an old kurviger route, all via points suddenly are mentioned in turn instructions when they where not mentioned before. This sounds like surprising, backward-incompatible behaviour in the UI to me.

@Corinna

Importing an old route now requires an extra step by the user to get the original behaviour. And you actually have to remember that every time you import an old route and before starting navigation. That’s a surprising change in the UI which ideally should be avoided.

That’s just not correct.

In public release version, the via points also participate in turn instructions.
You could disable that with “Settings | Routing | Waypoints in instructions”.

That option still exists in Beta, so via points continue to behave the same.

[Sabu]

@devemux86

Via + shaping points participate equally in navigation actions, like rerouting, skip next, etc.

Tested Today with a shaping point and avoid roadblock. Shaping point was not skipped
I’m a happy camper. Thanks for your hard work and openness for customer feedback!

[grua]

@devemux86

Option “Settings | Routing | Waypoints in instructions” remains for those who need it.

What does this function do in the actual beta release in detail? Default ebabled?

[devemux86]

@grua

What does this function do in the actual beta release in detail?

The same with the public release: show (or not) the waypoints in turn instructions.
(those who are allowed to participate anyway)

[devemux86]

Implemented in Kurviger 1.13.13.