App: Turn instructions on waypoints

In the next Kurviger file generated by the online Kurviger router it is (internal) in instruction 3 inclusive street.
DeadEnd-Test_Kurviger_router.kurviger (1.1 KB)

All signs must always be included in routing responses, for responses to be valid and complete.

Then whether a sign is used or not, it’s the client’s responsibility to decide.

Via and shaping points work differently, we already have discussed all that.

Please explain what you mean.

App is the client right ? Website display is also a client right ?

App does not display nor use. Website does, see instruction list.

App is one of the clients and follows specific rules for via and shaping points.

Shaping points don’t have voice guidance or else they will be identical to via points.
Via points (now) announce only their name and not their turn instructions.

Website is another client.
@boldtrn can answer for that.

Than why not using than that generated sign:-98 ?
This is not a Shaping Point nor a Via Point it is a Navigation Point.

It’s a turn instruction produced from / on a shaping point, which are not announced.
If you want turn instructions on waypoints you should use via points.
And wait when app can offer turn instructions on via points in the future.

Please check the waypoint types topic where all these have been discussed with the community:

A Navigation point generated (by the router) with a very close nearby Shaping point (by the user) that it is. The Navigation point should be announced the Shaping Point sure not as agreed before.

public static final int UNKNOWN = -99;
public static final int U_TURN_UNKNOWN = -98;
public static final int U_TURN_LEFT = -8;
public static final int KEEP_LEFT = -7;
public static final int LEAVE_ROUNDABOUT = -6; // for future use
public static final int TURN_SHARP_LEFT = -3;
public static final int TURN_LEFT = -2;
public static final int TURN_SLIGHT_LEFT = -1;
public static final int CONTINUE_ON_STREET = 0;
public static final int TURN_SLIGHT_RIGHT = 1;
public static final int TURN_RIGHT = 2;
public static final int TURN_SHARP_RIGHT = 3;
public static final int FINISH = 4;
public static final int REACHED_VIA = 5;
public static final int USE_ROUNDABOUT = 6;
public static final int IGNORE = Integer.MIN_VALUE;
public static final int KEEP_RIGHT = 7;
public static final int U_TURN_RIGHT = 8;
public static final int PT_START_TRIP = 101;
public static final int PT_TRANSFER = 102;
public static final int PT_END_TRIP = 103;

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.

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.

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 :wink: ), 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” )

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

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

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.

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.

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

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.

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

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)

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

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

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.


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

1 Like

with “headline” I mean “turn instruction display”

@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.

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:
Apps without shaping points rarely navigate this route flawlessly.
Kurviger navigates this correctly by using the shaping points.