App: Turn instructions on waypoints

[devemux86]

The turn instructions on via / shaping points are generated because of the via / shaping points.

Anyway the discussion keeps doing circles, perhaps the community can explain better all that.

[0709]

We’re not going to fight for it, but you can just say you don’t want it. But a better example of what the website shows with the return symbol in the instruction list I don’t have to offer. You may indeed place hundreds of Shaping Points without notice, but only in this very specific case does the navigation point with its instruction exactly coincide with the Shaping Point. I think you are mistaking that.

You know, we are not going to put the website and the application against each other.
We compare politely.
But in this case, the website implementation is right.

[rumbrummer]

Perhaps there is a misunderstanding:

As far as I can see, the routing returns 2 instructions for each via point / shaping point: The first has sign=5 which is the value for “REACHED_VIA”. It also has distance=0.0 and time=0.0, which means that the following instruction is on the same place.
The following instruction is the 2nd one - in many cases it has sign=0 ( =“CONTINUE_ON_STREET” ), but in the case that the point is in a dead end, it has sign=-98 (=“U_TURN_UNKNOWN”).

Showing the turn instructions on the Website, both turn instructions of the via points / shaping points are shown (please see screenshot of @0709 above).

As far as I understand, the app suppresses the 2nd turn instruction of the via points / shaping points: Even if I change the shaping point from route above to via point and enable option “Waypoints in instructions”, I can not see a hint that I have to make an U-turn @ the via point (Version 1.14.11).

I am not sure, if the discussion “announce via points / shaping points or not” and the option “Waypoints in instructions” concern just the announcement “here is a via point / shaping point” or if it includes “hide the 2nd instruction or not”:

My current, personal opinion:

• hide the 2nd instruction or not" should be a separate descision
• In most cases it is good to suppress the 2nd turn instruction, because it is just a “continue on street” hint, which would not be there if the via point / shaping point would not be there,.
• But if there is a real turn hint (any left, right, U-Turn hint) it would be useful to show it even in combination with shaping point, because it would be also there if the same route leg would be routed without that viapoint / shaping point.
  The “Dead end U-Turn” case shown by @zaphod_42 is an extreme example - as Wolfgang mentiond you miss the turn point, if you do not observe the map.
• On the other hand, this “severe case” is caused by a user failure (@Wolfgang: sorry ), so the first advice would be “avaoid failures”
• as in many cases, a more complex handling of the decision “show 2nd turn instruction?” would increase the effort, due to limited developer resources a priorization has to be done! I would like to have such an improvement, but would give a low priority ( = “nice to have” )

[devemux86]

@0709

implementation is right

You confuse right and expected / discussed / agreed with community.

Looks like another BRouter forum discussion about what is right and wrong in turn instructions.

[devemux86]

@rumbrummer

Perhaps there is a misunderstanding

Thanks for the detailed post.

Like explained above the routing API works correctly.
Then the clients choose how to use the responses.

The app merges via’s successive instructions, because one instruction can be announced per location.
Now it announces via’s name. There was not a need to announce together the via’s turn instruction too.

So the suggestion is that all turn instructions should be visible and announced in navigation?
Regardless of waypoint type, its turn instruction should be announced (u-turns and continue).

Obviously we cannot fill the app with options, that will complicate further the development.
The “Settings | Routing | Waypoints in instructions” already complicates app maintenance.

[0709]

You can also demonstrate it differently.

Website Roadbook. Follow all instructions exactly.
Now with the app turn instruction list. Isn’t something missing?

The problem mentioned in Brouter forum. (Perfectly reproducible)
Follow the navigation instructions exactly. Good luck !
There are tow services in the area that will help you further.

Admittedly.
U-turns are rare, but they are there.
Brouter generates few errors, but they are there.

[devemux86]

@0709

Website Roadbook. Follow all instructions exactly.
Now with the app turn instruction list. Isn’t something missing?

Voice navigation announces turn instructions as they exist in app’s turn instructions list.

So it cannot have 2 instructions at the same point and the first with 0 distance and time.
(some merging / post-processing must happen)

I am open for changes, but without adding more options, instead simplify existing ones.

[rumbrummer]

@devemux86

So the suggestion is that all turn instructions should be visible and announced in navigation?
Regardless of waypoint type, its turn instruction should be announced (u-turns and continue).

@devemux86

but without adding more options, instead simplify existing ones.

My proposal (perhaps to complex, as a discussion base):

• remove option “Waypoints in instructions”
• suppress shaping points with sign=0 (continue), show and announce the other ones
• symbol and announcement of shaping points according to turn instruction (as other turn instructions)
• show and announce via points (if you do not want to show + announce a via point, convert it to shaping point)
• use Waypoint symbol (flag) for via points
• if via point turn instruction sign=0 (continue) just show / announce as currently done when option “Waypoints in instructions” enabled
• for other via point turn instruction sign values add turn instruction text to announcement and to text in headline. Also add text like “turn left” etc. to headline, because waypoint symbol does not give information

[0709]

I have to read this a few times first. Emux, If you indeed need to break existing functionality in order to accomplish this, I’ll withdraw my question for u-turn support. I really don’t want to get the whole forum on my head.

I did investigate the consequences of locating a Shaping Point very precisely on a track point with an expected Navigation instruction at exactly the same position.
I see an identical twin track point pair being created. One trkpt coupled with the Shaping Point the second trkpt with the Navigation instruction.
Regarding: Track point pair 22 & 23. (latitude: 48.29193 longitude: 11.97671)
Navigation works normally.
DeadEnd-Test_export.kurviger (1.4 KB)

[devemux86]

Thanks for the detailed suggestions. They make my work as developer much easier.

They seem reasonable and simplify / improve app implementation (an ongoing goal).

@rumbrummer

• remove option “Waypoints in instructions”
• show and announce via points (if you do not want to show + announce a via point, convert it to shaping point)

Indeed that option is unnecessary with the shaping points and only causes maintenance troubles.

Everything else seems reasonable as well. I will check the algorithms and think for improvements.

[devemux86]

@0709

If you indeed need to break existing functionality in order to accomplish this, I’ll withdraw my question for u-turn support. I really don’t want to get the whole forum on my head.

This is not necessary, it is a reasonable request.
Software can not progress unless we review it often and push it to its limits.

[rumbrummer]

@rumbrummer

• for other via point turn instruction sign values add turn instruction text to announcement and to text in headline turn instruction display. Also add text like “turn left” etc. to headline turn instruction display, because waypoint symbol does not give information

with “headline” I mean “turn instruction display”

[0709]

@rumbrummer thanks for thinking along. Very helpfull.
The different U-turns.

sign: -8 u-turn_left:
Left U turn_example.kurviger (684 Bytes)
U turn with often a spacious turntable. U turn command linked to single track point
sign: 8 u-turn_right:
U turn with often a spacious turntable. U turn command linked to single track point
sign: -98 u-turn:
U turn with often a limited turn area. U turn (-98) and Shaping Point do share a common trackpoint.
ONLY this U turn (-98) is able to replace the Shaping Point info and changes it to announced.
U turn (-98) exceptionally so promotes the corresponding Shaping Point into a announced informative one.The standard routing functionality thereby is kept intact as usual by non strict or strict.

The “turn instruction display”, only contains street name info.
This keeps it compatible with the next realization.

App: Display street name

I have a prototype working with e.g. (offline) GraphHopper (on and off route). It does reverse geocoding of user location and displays the street (at bottom). With Kurviger that could make sense only on the route (if route contains that data). Doing continuously online reverse geocoding does not seem a very wise solution? [Cruiser]

Image examples as trk gpx list.

Shaping Point and straight share a common trkpt.
Shaping_straight.kurviger (1.0 KB)
The not announced Shaping point has priority.
Shaping_straight_trk.gpx (1.3 KB)

Shaping Point and u-turn share a common trkpt.
Shaping_u-turn.kurviger (985 Bytes)
The announced u-turn has priortiy.
Shaping_u-turn_trk.gpx (1.3 KB)

Demo video U-turn: https://youtu.be/CysDm9BwF3I
Apps without shaping points rarely navigate this route flawlessly.
Kurviger navigates this correctly by using the shaping points.

[devemux86]

@rumbrummer

My proposal (perhaps to complex, as a discussion base)

In fact it is quite simple and also my thinking.

@rumbrummer

use Waypoint symbol (flag) for via points

Any turn instruction with a direction must have the direction symbol.
We can enrich via instruction to [Waypoint name + Turn instruction].

Each routing service can have different behavior:
BRouter, GraphHopper + Kurviger, OpenRouteService, OSRM, etc.

BRouter does not generate (double) turn instructions on via and shaping points.
We can only have the [Waypoint name] instructions on waypoints with BRouter.

BRouter did not generate either the [Waypoint name] instructions on waypoints.
I generate them myself when I post process BRouter routing:

App: Improve BRouter turn instructions

BRouter does not generate turn instructions for waypoints. So BRouter routes don’t know waypoints, only start + end. That may concern navigation (reported here and here). We must post process & enrich BRouter results before use. Related to the feature: https://forum.kurviger.com/t/app-offline-routing-brouter/649

[0709]

Concerning Via Point support in BRouter
https://groups.google.com/g/osm-android-bikerouting/c/ceUFvc4sFdQ/m/OTqDbieOEQAJ
No succes…Only one vote for ;-((

Concerning Shaping Point support in Locus gpx & navigation.
Shape Point transfer by gpx | Locus Map - help desk
No succes…Only 2 Votes ;-((

Only Kurviger understands the usefulness of using both Via and Shaping Points @ navigation.
That’s why I’m here, even if I’m not a motorcyclist. The investment in this app: Peanuts
The pleasure you get in return is well worth the mini investment.

[devemux86]

Available in Kurviger 1.14.12 (Beta) based on above discussion.

Please test routes and their turn instructions with menu “Routing | Turn instructions”
and voice guidance with the simulation in “Settings | Navigation | Navigation Mode”.

[zaphod_42]

With my stupid mistake I kicked off a snowball … an avalanche has now arrived in the valley, without damage!
Thanks @Emux - good job! And thanks @0709 and @rumbrummer for being so though to represent all the technical stuff I know so little about. I think kurvigerPRO has once again become a bit better.

[0709]

Kurviger 1.14.12 Sure a good job.
AND it also works by using Shaping Points. (= Perfect tnks)

U turns are indeed rarely Planned, but it is now possible perfectly. Protect by using a Via Point.
U turns by the instruction list are perfect indicators to locate false instructions even faster.
In many cases, U turns are not expected instructions that are caused by planning errors.
1. In Wolfgang’s example due to a too quickly executed so falsely positioned Shaping point.
2. Shaping Points planned too close to critical road intersections that so ended up on a side road undesirably with the corresponding false turn instruction.
3. If you enter a simple track and have a route calculated by reference Shaping Points you often see these “dirty” instruction errors arise.

*You can hardly discover this on the map itself unless you zoom in very deeply. *
So it is now already a bit more noticeable by the navigation list.
The ultimate goal, the app automatically detects this and removes harmful Shaping Points itself.
The autocleaner should so clean and remove “U turn Shaping Point” combinations only.
The autocleaner should NOT clean nor remove any “U turn Via Point” combination.

[rumbrummer]

@devemux86

Any turn instruction with a direction must have the direction symbol.
We can enrich via instruction to [Waypoint name + Turn instruction].

Very nice, thanks a lot.

Just a question concerning a detail, Route: https://kurv.gr/UUy6N

Reaching via point #1 announcement and turn display is fine (as expected ).

Reaching the U-turn via point, there is an announcement that there is a U-turn, followed by via point name .

Would it be possible also to add a hint to turn display that rider is approaching a via point / the via point name?

Riding motorcycle without using a headset (-> no voice guidance) this might be helpful!

Perhaps it would be also useful to add the hint / via point name to turn instruction list - but I think that has a lower priority (nice to have), because it will not lead to missing a via point (like restaurant etc.).

Remark: I tested via simulation, did not test if hint/via point name is shown during real driving.

Remark2 (quite late): Thanks a lot for implementing simulation mode - that helps testing behaviour a lot, makes it quite easy to simulate without using further tools and therefore it leads (and led) to more testing, which probably improves quality !

[devemux86]

@rumbrummer

Reaching the U-turn via point, there is an announcement that there is a U-turn, followed by via point name .

Actually it is an announcement of [Waypoint name + Turn instruction].
(similar to turn instructions list)

@rumbrummer

Would it be possible also to add a hint to turn display that rider is approaching a via point / the via point name?

Indeed now the turn instruction overrides the via point.
I will see what can be done.

@rumbrummer

Perhaps it would be also useful to add the hint / via point name to turn instruction list

The turn instructions list already has the updated instructions.
(similar to navigation)