BRouter U-turn command missing.

[0709wiwiwi]

Current: BRouter (web) does not generate U-turns.

Desired: Brouter (web) generates U-turns.

Generating U-turns (180° track returns) is very valuable. By generating U-turns you can avoid unclear or false turn indications.
Especially when navigating with "display off" and with TTS audio indication mainly, U-turns can prevent very serious wrong turn instructions. How the confusion can arise without those U-turns can be found in the link to the google BRouter discussion group.

Pse find the details here:
https://groups.google.com/g/osm-android-bikerouting/c/-ljF8nqbFZc/m/4CjP2PQ7AAAJ

[polyscias]

I am not so sure u-turn instructions are the solutions for this problem.

The Via point is about 1 meter from the wanted route and I would think that by the default setting of turnInstructionCatchingRange=40 (meter) this 1 meter detour would be ignored completely and the only turn instruction should be "Turn left".

So there is a bug, I can recreate the bug using OsmAnd turn instructions, it gives Turn Right and 85 degrees, that is clearly incorrect. I tried also with turnInstructionCatchingRange=0 but then I still get only only one instruction this time Keep Right with 0 degrees also clearly wrong.

Looking at this issue this way is also linked to what was discussed in #332

[0709wiwiwi]

Keeping to the right if it was indeed preceded by the U-turn, how strangely close this may be is always correct and clear. What the U-turn, so close to the next Right instruction shows you as such, is that the planning edit has to be adjusted here. A Clear and simple msg. Point the finger so to the planner operator.

The simplification problem by turnInstructionCatchingRange=40 (meter) was also presented here.
https://groups.google.com/g/osm-android-bikerouting/c/1zl5NSLR0y8
In my planning experiences this method is absolutely not a heaven on earth nice method. On the contrary bad results happen.
So this simplification tool should be used with of lot of care (or even not) and by well understanding what really happens!

And it also does not solve the badly planner points positioning problematic nor does it discourage such bad planning practices. Good planning practice should so encourage: Do NOT (never) click to near to the road junctions.
Remark:
Some small sideroads available in the routing data can even be hidden by the visible map not displaying them.

Example

You can see how unexpectedly something like this can happen in the following example.
https://forum.kurviger.de/t/missing-street-in-maps/8173
As U-turns are supported in the Kurviger app, you can observe the U-turns in the turn instruction list.
When no U-turns are generated by the router engine, you will probably not notice the unnecessary right/--/right combination. You so will experience this annoying track glitch due to the strange unexpected instructions while you are already actually navigating. Too late ! You must so prevent this to occur already in the planning phase.

In the discussed format, instructions in the track points, this could look like this in the exported track file.
View this most easily and optimally with the freeware (PC) gpx editor program.

Delligsen_rte__trk_navtrkpt_U-turn.gpx.txt

In this file find both the gpx (rte) route with the routepoints and the resulting (trk) track with the instructions in track points.

Allow me to ask myself whether the turnInstructionCatchingRange simplification does not sometimes create more problems than it helps. If too dubious turn instructions are generated by a not-so-decent simplification tool, removing this may be the better option.

[nrenner]

Probably also related regarding the wrong turn instruction near/at junction: #282

[polyscias]

Yes, agreed the turnInstructionCatchingRange does not what it is supposed to do.

Looking at the details and past experience I think one possible solution here is to extend the algorithm that snaps the via point to the line structure to check if there is a crossing nearby and if so, snap to that instead of the point closest on the way. This will also be good for other purposes.

I added some debug code to VoiceHintProcessor.java and that reveals the likely problem:

The voice instructions are generated in two steps, first from to to via1 and then from via1 to to

That can explain a big part of the strange behavior I think and is not what is wanted I think.

[afischerdev]

We have a turnInstructionCatchingRange problem, yes. I'm with @polyscias some thing with an additional snap logic seems to be a good idea.
But where is the break between snapping to junction or way?
2,5,10,20 meters?
And how to know if this peak from the main way is intended or just a bad mouse click?

When you have short view on this . It is off a catching range. But it shows the voicehint problem. All gpx exports with voicehints as wpts meets the turn point 13.766777,51.061312 twice, on the way to u-turn point and back to river. Only the second one is valid. Please try the index based export 'comment-style' or json export - BRouter calculates it well.
Btw. export 'auto-choose' = 1 has a index based gpx variante that covers a little bit of issue #499 - voicehints at the trkpt - but is not reachable on BRouter server.

For more turnInstructionCatchingRange discussion please see #375
There are a lot of tests for critical voicehints.
Use this branch for testing.
It uses a turnInstructionCatchingRange of 2 meters and that covers a lot of the problems.
We also played a little bit with the turning angles.
So please have a critical look on it.

Coming back to start: U-turn command missing
All this doesn't effect the main request.
If we want it in this sketched situation, we should try to add it.

[0709wiwiwi]

The U-turn command request.
Placing planning points Via or Shaping near road crossings is always 'risky business'.
Usually caused by sloppy fast planning. In the example, I wanted this as a demo of course.
It can be better or worse if your planner point so deviates by accident onto a side street.
How do you find out which planner points are potentially harmful or not?
If you generate U-turns, see a well-functioning and so useful detection method.

Anyway sometimes, although rarely used, you want to plan something with a U-turn indeed.
As shown in the next document.
U-turns and Via Points.doc.txt

How to use the U-turn info as a nice error indicator?

Demo by an example file with (rtept) route points and a track displayed as an overlay.
This traject is suitable for motorbiking, a demo with the Kurviger app is possible. ;-)
Video: https://youtu.be/xNozjTKx92Y
Or solved by a more radical intervention.
Video: https://youtube.com/shorts/gcpGECN-2k0

Check and compare the results against the track template.
If it differs, you so do know exactly what to do next.

In a Kurviger export the gpx (rtept) routepoints are marked with the tag "type" Shaping.
Kurviger (Cruiser) recognises the routepoints by "type" Shaping at imports.

(To know: Kurviger uses own .kurviger files (.json variant) to transfer navigation tracks)
For easy edits on the map it is advantageous to hide the yellow turnpoint Icons for a while.

Then look for the U-turns in the turnpoint list. Clicking on them will take you to the suspected wrong locations.
Then click on the triggering Shaping Point and move it to a safe and proper zone. Or more radical delete and check.
You will then see the unwanted U-turns disappear with so correct turn instruction results.

Some other Shaping Points are also critically close to road junctions but not in a position to cause turn errors.

Translated with www.DeepL.com/Translator (free version)

[polyscias]

some thing with an additional snap logic seems to be a good idea.
But where is the break between snapping to junction or way?

On the snapping logic, and far as I understand it now, the problem is only there only for via points and if there is a crossing nearby, no problem when there is only a way.

A workable solution is I think to look for a crossing that is within say 10 meter and it is present, take it. If the waypoint is further away from a line, take the normal perpendicular line and check if along the way within 10 meter a crossing is and if so, that that.

The "10" meter could maybe be the same numbers as the turnInstructionCatchingRange

The other problem that should be solved I think before further improvements is not to have the voice instructions for routes with via points not generated in a step per segment, i.e. first from to to via1 and then from via1 to to. Instead the voice instructions should be calculated for the whole track in one go.

[0709wiwiwi]

Difficult subject.

When converting from "track to route", automatic planner points are placed. Depending on the 'fuziness' choice, many or few. Here, too, track glitches sometimes occur. Pointing out suspicious planner points by means of U-turn alerts can also be helpful here.

What route planners should try to enforce is that sound and correct planning is done.
And so to generate a helpful U-turn alert signal if it is likely to go wrong sometimes.

A demo example.
On map red dot alert. ( a still a not realised proposal)
https://forum.kurviger.de/t/show-list-of-u-turns/6062/16?u=0709

U-turn alert example: The Shaping Point 44 triggers a U-turn.

In the last picture the original route Shaping routepoint position is snapped to the track into a trackpoint type Shaping. Both trigger Planner Point Shaping and U-turn do share the exact same trackpoint location.

Even with a lot of planning experience, working too fast can sometimes lead to unexpected results.
Planning is sure a discipline operation, and yes, appreciate so the help of an extra useful alert tool.
(imo)

[afischerdev]

A workable solution is I think to look for a crossing that is within say 10 meter and it is present, take it. If the waypoint is further away from a line, take the normal perpendicular line and check if along the way within 10 meter a crossing is and if so, that that.

My name on this problem is 'avoid peaks'. This means not to have a view on only one point. A 'peak' can have more points. I have a workaround on that, but I can't 'deliver' now - or the next days, hope on next week.
The Idea is to walk back the line and rearrange current and previous segment when the points are equal.

the voice instructions should be calculated for the whole track in one go.

I agree that. It could be saved several of the discussed problems. This is on agenda as well as other ideas.

[0709wiwiwi]

@afischerdev
You must ensure that the planner operator remains free to keep the planned U-turns.
It is up to the planner operator to decide whether or not he wants the U-turn to be kept.

• Locus compatible gpx navigation track.
  To the Biergarten than to the Ferry.gpx.txt
• Useful use through planned U-turn.

Or import in Locus direct by the .zip (do not unzip)
To the Biergarten than to the Ferry.zip.txt

[nrenner]

The Idea is to walk back the line and rearrange current and previous segment when the points are equal.

the voice instructions should be calculated for the whole track in one go.

I think this would break a basic principle of consistent results between routing individual segments and the whole route, which is what brouter-web relies on, don't know about other clients.

Don't know about all the implications and pros and cons, and might be Ok for just voice hints, but such a potentially breaking change should be given some consideration.

[afischerdev]

@nrenner
Yes, I think we have to view this very carefully.

As far as I know the web client connects segment by segment. This will work as normal, only with more then two points in lonlats new function is active.

[0709wiwiwi]

The simple request is: Please generate the (180°) U-turn command.
(That by U-turns you fastly notice possible trackglitches is a nice extra)

[nrenner]

As far as I know the web client connects segment by segment. This will work as normal, only with more then two points in lonlats new function is active.

The upcoming brouter-web release switches export from re-requesting the whole route with all points to concatenating client-side segments, so it won't be affected but also won't benefit from those changes. And results would then be different from the app, which isn't ideal.

But I will open a separate issue for that discussion.

Just this pse. Github/abrensch/brouter) (app/engine)

Core results from app/engine and web should be consistent.

The simple request is: Please generate the (180°) U-turn command.

Currently the router processes each segment between two route points separately, and I guess this is on purpose, so it can't detect those U-turns.

Changing that to looking at the whole route would be a fundamental breaking change that might have unintended consequences, so I think it needs to be discussed and well-considered.

[poutnikl]

Currently the router processes each segment between two route points separately, and I guess this is on purpose, so it can't detect those U-turns....

I had been saying so few years ago, but I had not been listened much. I am glad somebody else says it.

[0709wiwiwi]

@nrenner Hello Norbert.
"So it can't detect those U-turns".
As far as the lack of U-turns is concerned, this is still a BRouter shortcoming for me.
An example of a (now) good U-turn usage can be found here.
https://forum.kurviger.de/t/app-turn-instructions-on-waypoints/4300
Just see how very misleading the turn instruction sequences are without the U-turn command.
Without that U-turn message you even used to continue your drive until the off track signal than came.

The Kurviger app now indeed uses the (GH) engine U-turn signal to its full potential.

Also if apps, when driving wrong, by auto recalculation, it would also be useful to get the U-turn command instead of that very misleading (180°) straight ahead. Commercial (car) GPS systems will sure of course ask you to turn around, and if you still drive on, than an alternative proposal follows. With Locus_Brouter this alternative design comes after the second autorecalculation. Method proposal triggered by @poutnikl in Locus.

@poutnikl Hello Libor.
I once reported strange BRouter turn instructions followed by the comment that it was technically impossible to do otherwise.
Note that the erroneous BRouter turn instructions reported then are now correct. That reported issue was so nicely solved in silence after all. To optimise routing results, you should first report the usage problem. Of course.

[poutnikl]

@0709wiwiwi To clarify, I had no problem with that myself, as I understood there was a Brouter backend layer and the (web/android) application frontend layer and how they (may) approach routes and route segments.

Personally, I am not so much lately interested in the web application, preferring LocusMap route planner.

BTW, thanks for your thorough end user testing and reporting. Good work.

[0709wiwiwi]

@poutnikl
Roger, sure plenty of choice. I prefer Brouter web. What's missing is U-turn & Shaping & Via Points in the gpx export.
A gps app should also perform very well offline, so it is necessary to continue to improve the BRouter (app) as well.
This includes, when offtrack, faster alternative recalculation results through the BRouter app.
However, that's a separate story.

[afischerdev]

Changing that to looking at the whole route would be a fundamental breaking change that might have unintended consequences, so I think it needs to be discussed and well-considered.

Yes, I think so.

@nrenner
Could you please tell us - I don't know enough about the history - why the web client 'only' uses single segment requests?

I had a look on your wiki 'segments vs. full route'.

• One reason is the use of direct routing. But there was already in older versions of BRouter server a part on beeline routing. And a new one as well.
• 'different route' I can't follow. Always get correct route (with / without extra points)
• 'no height on bridge' Interesting, I didn't get a height in this example either, but it has nothing to do with multi or single segment for me.
• 'turn instruction when via point is exactly on junction node' should be done with the update

And we have some bothering routing instructions through single segment requests. Is that the reason why we don't see voice hints on web client?

[afischerdev]

Now I can publish a work around.
The idea is to go back the line when points on prev track and new track are equal.
And the voicehint generation is moved from track by track to the end - with detours.
Time and energy are calculated back but differ a bit to a plain track.

You find it on afischerdev/avoid-peaks

There are some new rules:

• With parameter 'avoidPeaks=1' you can switch on/off the new logic.
• Additional the parameter 'avoidPeaksDistance=60' sets a break distance for catching a peak. Default is 'avoidPeaksDistance=0', means no distance check.
• When a peak has a poi around, peak is not dropped.

This can not be tested with web client so here are some wget samples:

wget  -O result_1.gpx "localhost:7777/brouter?lonlats=13.764484,51.06054|13.767552,51.061545|13.766512,51.06172&profile=trekking&alternativeidx=0&turnInstructionMode=1&profile:avoidPeaks=1"

wget  -O result_2.gpx "localhost:7777/brouter?lonlats=13.764484,51.06054|13.767552,51.061545|13.766512,51.06172&profile=trekking&alternativeidx=0&turnInstructionMode=1&profile:avoidPeaks=1&profile:avoidPeaksDistance=30"

wget  -O result_3.gpx "localhost:7777/brouter?lonlats=13.764484,51.06054|13.767552,51.061545|13.766512,51.06172&profile=trekking&alternativeidx=0&turnInstructionMode=1&profile:avoidPeaks=1&pois=13.767423,51.061584,Restaurant"

turnInstructionMode == 1 is now reachable in export and contains voicehints information on trackpoint.

avoidPeaks should be found in the editable part of the profiles. So user can play around with it.

This is not ready and needs a carefully test.

[0709wiwiwi]

You can see how you sometimes unexpectedly produce those very annoying trackglitches in the sample video here.
https://www.mtb-news.de/forum/t/brouter-web-fragen-antworten-hilfe-profile-tipps-etc.917910/post-18064906

I produced a similar short design based on that demo video: https://t.ly/4LZF
turnInstructionMode Locus style & turnInstructionCatchingRange 4

This is a short track, you hardly will notice trackglitches on longer tracks with a zoomed out map.
Attached find a gpx track with instructions in trackpoints inclusive the U-turn and the unexpected turn instructions.
The original trigger planner (wpt)waypoints are only "for illustration purpose" also still added here.
The trigger planner (wpt)waypoints are "snapped" into a Via or Shaping trackpoint indicated by the sym pass_place.

Gräbendorf -_ Dolgenbrodt (8km)_navtrkpt_wpt.gpx.txt

[afischerdev]

For the blocker 'no height on bridge' (e.g. #70) I added the tunnel version announced here and merged it into the avoid-peaks branch.
I experimented with the start situation on a bridge, but ended up with sharp edges when the start and end points of bridge/tunnel are at different heights, so I prefer a post-process variant.

[afischerdev]

@0709wiwiwi
For your sample I merged the direct line logic into the avoid-peaks branch. Was introduced here - see for more info.

With this you can switch between direct lines or not in server and you get this results (Locus new export with reduced name tag, you asked for in #332):

testtrack0.avoid-peaks.gpx.txt

testtrack0.direct.gpx.txt

At the moment only available for the server variante, Android will follow.

[0709wiwiwi]

@afischerdev
Nice, the turnpoints are sure perfectly functional with the gpx track import.

By the way I can't of course not forbid anyone to use the name tag though.
But you might understand why I prefer to keep the name tag free at turnpoints.
This is necessary to compactly apply announced ViaPoint_U-turn combinations in the gpx trackpoint.

What I don't see in the export gpx trackfile yet are the "snapped" planner trackpoint positions.
Planner points 'snapped' to a trackpoint to be tagged with 'sym' pass_place & 'type' Via or Shaping.

I estimate that about 90% of the points in a design are shaping points, i.e. planner points without announcement in the navigation. However, shaping points are just as valid reference position points for the (re)planner and for the auto (re)routing in the navigation as the announced Via points. (= Kurviger implementation and style use by the type tag)

Locus map actual already uses these positions as reusable Via points.
(No import support as Shaping points by the type yet by Locus map)
Whether you automatically or manually assign a name or not is completely free.
At navigation a Via trackpoint without a name is of course without TTS announcement.
Anyway such a Via trackpoint is shown in the turnlist and as Via Icon in the app.
(Not announced Shaping points should NOT be shown in the turnlist nor as Icons)

See a question about the possible recovery of the planning Via points (Shaping) in a gpx track file.
https://www.mtb-news.de/forum/t/brouter-web-fragen-antworten-hilfe-profile-tipps-etc.917910/post-17690773

Thank you anyway for your enthusiasm and fast development progress.

[0709wiwiwi]

@afischerdev

I have thought a bit more about the new "avoid¨Peak" tool which you propose and introduces.
With parameter 'avoidPeaks=1' you can switch on/off the new logic or else you apply avoidPeaksDistance=0 or 60 or 10 etc.
.
#436 (comment)

And how to know if this peak from the main way is intended or just a bad mouse click?

What would you think of the following ?

• For not announced Shaping Points which cause a U-turn the avoidPeak tool works.
  (I expect that 90 % of the planner points are thus not announced Shaping Points)
• At the announced Via Points which cause a U-turn the avoidPeak tool is ignored.

"A Via Point is simply a promoted Shaping Point."
"A Via Point can thus make 'noise' in the navigation."

If you accidentally produce a U-turn due to a (too) quickly and carelessly placed Shaping Point, the avoidPeaks tool will intervene according to the profile setting.
If you do want to set a planned U-turn, even if it is in the catching range of the avoidPeaks tool, you need to produce it with a Via Point. The placement of a U-turn is then by no means still an accidental mistake, but it is so clearly a real planned one.

[0709wiwiwi]

nrenner/brouter-web#498

How to promote route points to Via points without extra button in the BRouter web GUI ?
The construction of a new route is by quickly placing route (reference) Planner Points without a name.
So from the Start (automatic name to Via) so on with tap tap tap this until the End (automatic name Via).
These quickly placed route planner points without a name can so be considered as Shaping points.
You could promote some to be announced Via points in the navigation by giving them a name.
Name edit trigger by right-clicking or long-clicking on the Planner point on touch screens.

Nice to have extra's.
Altstadt -_ Neustadt (0.5km)_navtrkpt_edit_extra.pdf

[afischerdev]

@0709wiwiwi

Locus map actual already uses these positions as reusable Via points.
Interesting feature - did not know that before. Good point on continues routing when you miss the route.
So I add this to Locus export.

testtrack0.via.gpx.txt

You could promote some to be announced Via points in the navigation by giving them a name.
Name edit trigger by right-clicking or long-clicking on the Planner point on touch screens.

Good idea, I think this could work.

[0709wiwiwi]

Yes, this Via trackpoint import works fine as expected in Locus.

Start & End Via trackpoints automatically with 'name' are with 'type' Via.
Middle planner points without 'name' are preferably with 'type' Shaping.
Only when you add a 'name' in the Brouter planner, then with 'type' Via.

I try to preserve the simple Brouter operation in this way.
The BRouter gpx export file is so functional and basic simple.

With gpx editor or Notepad++ you can always change the 'type' freely.
In the Locus planner you can convert imported Via points to Shaping Points.

[0709wiwiwi]

@afischerdev

I am curious about the effectiveness of the "avoid Peak tool.
Find here attached a nice gpx (rte) route file to test it now.
TET_rte_rtept_0.5km_type_shaping.gpx.txt
Calculate by the gpx (rte)route import, weird, in Brouter menu import as track ;-)
(The Kurviger_Cruiser app import by wpt&rte&trk menu is perfectly clear though)
Set Profile Trekking Bike & use default fuziness, so using all routepoints.
Normally you find a single Peak over the total traject (km22).
With set avoidPeaksDistance=30 the result is without peak ?

Note. Good to know.
These rtept distance tickmark routepoints positions are the original distance "tickmarks" of the track.
So the chance that distance tickmark routepoints fall on an intersection of roads is quite small.
The downloaded original track (the one where I attached than distance tickmarks) is shared here:
#282 (comment)

Calculation with the Cruiser_Brouter_app using that route file is very smooth, but produces that "peak" (track glitch) at km22.
You probably do notice in this video example the missing U-turn in the turnlist, that's why I ask for Brouter U-turn support.
https://youtu.be/MmedcoEtupo

[afischerdev]

Middle planner points without 'name' are preferably with 'type' Shaping.

I've changed this.
And I enabled: a name on a match point and point is ignored for 'avoid peaks'.

testtrack0.via_new.gpx.txt

With set avoidPeaksDistance=30 the result is without peak ?

Yes, I can confirm the peak is inside 30 meters and removed.
And when you use the a new BRouter app, Cruiser will route the import gpx without peaks.

[0709wiwiwi]

Excellent message.
Anyway I do have one more question.
Why does trkpt14 generate a U-turn_right and not a simple U-turn ?

U-turns. The difference.

• A (180°) U-turn returns by exactly using the same way. Triggered by a Planner Point. Suspicious !
  (This is the type of U-turn where you have to be a bit alert all the time)
• A left U-turn is a normal turn where you return over a parallel lane. Not triggered by a Plannerpoint. Not suspicious.
• A right U-turn is a normal turn where you return over a parallel lane. Not triggered by a Plannerpoint. Not suspicious.

Following examples are to be generated by the Profile Car (fast) !
Find the shortlink to BRouter web in the gpx file.
Gpx tracks with a U-turn left as generated by BRouter.
See the gpx tracks with the instructions in track points.
1_Lokeren_navtrkpt_(0.7km).gpx.txt
2_Zele (0.2km).gpx.txt

Note.
Actual BRouter Locus gpx track & waypoints (extension) export.
The actual BRouter generates 2 of the 3 possible U-turns.

• Generates the directional U-turn left and U-turn right.
• Does NOT generate the non-directional (180°) U-turn.

BRouter Locus rtepointAction.

1. The simple U-turn command by rtepointaction 12.
   Icon is simple inverted U. (Not yet in Locus)
2. The left U-turn by rtepointaction 13.
   Icon is an inverted U with a small arrow pointing to the left.
3. The right U-turn by rtepointaction 14.
   Icon is an inverted U with a small arrow pointing to the right.

Information. (compare).

_GraphHopper generates all 3 U-turn versions.
The GraphHopper signs:

1. The simple U-turn command by GH sign:(-98).
   Icon is a simple inverted U. (Icon in Kurviger)
2. The Left U-Turn by GH sign: (-8).
   Icon is an inverted U with a small arrow pointing to the left.
3. The right U-turn by GH sign (8).
   Icon is inverted U with a small arrow pointing to the right._

[0709wiwiwi]

Why that strange "U-turn_right" ? (Very rare on EU mainland).
Maybe is caused by the "turnInstructionCatchingRange" ?
The "U-turn" and next "stay_right" possibly results in "U-turn_right" ?
#332 (comment)
To test: removal of the turnInstructionCatchingRange rule.

[afischerdev]

@0709wiwiwi

Why does trkpt14 generate a U-turn_right and not a simple U-turn ?

The reason for this is simple, there is no extra u-turn, only left or right.

And on this we share the source with OsmAnd - please see TurnType.

For now I have rearranged the turn tags and add a u_turn simple.
But this will only affect the Locus export, all other clients will get old voice hint values.

testtrack0.u-turn.gpx.txt

We need more input from other client projects to fill in a 180 degree turn.

And another sample:
Merged two left, left into a u-turn left.

testtrack0.u-turn-left.gpx.txt

But allow a left, right without merging.

testtrack0.left-right.gpx.txt

[0709wiwiwi]

GH web result with U-turn here.
https://t.ly/gfT-

https://youtu.be/2nE1ZdjqcuQ

A remarkable difference between the track export by GH and BRouter.

https://t.ly/NQkE9

The U-turns by Brouter are perfect 180° returns. (No 179, no 181).
The Locus map app planner has a track glitch detector, but no cure.
This Locus map tool only indicates, the user must correct himself.

The difference with this new implementation is that you detect AND heal automatically.
The user retains full control because the set conditions for auto healing are simply defined.
Only auto intervenes with the (fastly) placed Planner Points (Shaping without name) within a set "capture distance".

I find this ultimately more convenient and faster than just the 'marking' in Locus map.

I'm not an osmand user, but I do notice in their forums that this problem is also a frequent occurrence there. To avoid trackglitches, however, you need to notice them first. Imo generating (180°) specific U-turns and paying attention to the undesired ones also would lead to a more optimal track production in the osmand app.

[0709wiwiwi]

"avoid-peaks".

I did read the comment of @zod
Notice I did use "trackglitch detector".
Detector, because is not a "curing" tool.

Suggested is a tool to avoid the creation of "trackglitches".
Tracks (trk) can have annoying glitches, routes (rte) not.
A track used to be navigated technically still remains a track (trk) !

[NL] https://www.javawa.nl/unglitcher.html.
The "unglitcher".
Avoids confusion, users do call tracks also (non technically) routes.

[NL] https://help.routeyou.com/nl/topic/view/37/track
Begripsverwarring
Eenmaal een track opgeladen is bij RouteYou spreken we bij RouteYou over een route (in de RouteYou betekenis).
Dit is dus een andere betekenis dan wat men aan dat begrip geeft in de GPX (topografix)_Garmin wereld.

[0709wiwiwi]

Video demo: https://youtu.be/rIirfld57lc
This is why I ask U-turn and instructions in trkpt support.
The calculations are fine for the usual cycling distances.
Long distance? Nothing for the BRouter.
By GH: https://youtu.be/7cJ-scN4OyU
Anyway not calculating from Oberstdorf to Flensburg ;-)

Neu-Isenburg_trk_original_rte_shaping_by_type.gpx.txt

Javawa (rte)route_source.txt

A navigation track result for a direct import into the Locus app. Ready to navigate.
Instructions in waypoints (mode2) and instructions (U-turn) in trackpoints by a manual edit. (mode 7)
Neu-Isenburg (80km)_Brouter_Locus_web_edit.gpx.txt

[nrenner]

By GH: https://youtu.be/7cJ-scN4OyU

That's the performance and user experience we're competing with.

The very long route might be an exaggeration to make a point, but there is also a noticable difference between fluent and laggy for shorter routes. And we do have requests to support multi-day trips, so users do or would use BRouter for that.

[nrenner]

Video demo: https://youtu.be/rIirfld57lc
This is why I ask U-turn and instructions in trkpt support.

Manually scanning the list of turn instructions for u-turns, as a possible hint for glitches, isn't an ideal solution in my opinion.

Missing u-turn instructions are not the problem here. The problem are unintended back and forth detours (peaks/glitches/spikes) that go unnoticed by the user.

From a client-side perspective, the most obvious solution for me would be to warn the user about such a peak right at the moment it occurs, e.g. by placing a warnig sign in the via marker. The user can then manually check and fix the problem while editing the route and before exporting. Very much like your "alert signal" proposal above:

The client should be able to detect such peaks when two neighbouring segments are joined by more than one common track point. No u-turn voice hints needed for that.

[poutnikl]

I cannot imagine I would plan a multiday trip or expedition without viapoints/Shapepoints, at least for important POIs or camps(whatever is meant by that). And more probably, I would make separated daily routes.

GH performance comparison is imho an underbelt hit, as GH uses AFAIK Contraction hierarchies , an algorithm specialized for long distances, using intensively preprocessed data, what OTOH limits it's end user adaptability.

[0709wiwiwi]

Thank you for watching Norbert.

Concerning

• The speed of the Brouter calculation for normal bicycle routes is definitely sufficient for me.
  Example combination Cruiser_with BRouter app server is therefore completely satisfactory to me.
  I always use fairly normal cycle routes and in this respect I completely agree with @poutnikl

• I definitely like the U-turn command. Planner point_U-turn (planned) combo is very elegantly implemented in Kurviger.
  Uniquely applied in this one Kurviger app. It is highly recommended that even other apps also would offer this.
  In Kurviger by using a .kurviger (.json variant) file but it should be just as easy with a super simple gpx navigation track.

• Large distance calculation in the Kurviger motorbike app is standard by the online Kurviger (GH) router. When redirecting at
  (short distance) deviations when positioned in a "data hole" so must use BRouter. That the BRouter offline app is needed for
  this is not so much out of love but pure necessity, but you already knew that.

• Street names are nice to have and very common among Kurviger motor bikers, so this is just interesting nice.

• The 180° U-turn indication is a Kurviger proposal that has not yet been realised. The user then determines the necessary actions himself. Actually the U-turn text by search tool is used in Kurviger to fastly detect the problematic U-turn locations.
  By the way.
  In contrast to the BRouter by the Kurviger (GH) router, the return path is not always exactly a 180° overlap return. So the only method there is to use the U-turn command as a warning signal. I explained this with an example from the Locus forum.
  So I would appreciate the generation of a U-turn command this for the Kurviger guys. "Motorbikers your friends ;-)"

• Unexpected new.
  Dev "afischerdev" already had prepared a design for the automatic healing of 'glitches_ peaks.
  If this works, it would be very nice. But I don't know the impact on the total BRouter performance.

[nrenner]

The 180° U-turn indication is a Kurviger proposal that has not yet been realised.

The idea was to maybe implement something similar in BRouter-Web.

Your comment above sounds like the BRouter-Web client isn't involved at all - do you actually use that?

Just trying to understand the use cases and what that all means for BRouter-Web, and if we have a theoretical or practial consistency issue here.

[poutnikl]

I guess sometimes that, without careful reading, it may be questionable if a particular issue or topic belongs to abrensch/brouter or nrenner/brouter-web.

[0709wiwiwi]

Right.

This entry was moved (advised) from Brouter web nrenner to BRouter abrensch.

BRouter Generator.
The U-turn command generation is in the Brouter engine abrensch.

BRouter web planner.
The U-turn is expected in the BRouter web client nrenner.
The operator planner accepts a U-turn or corrects the design.

App planner(s). Locus and Cruiser and other.
Clients with which you can plan additionally or totally new.
Locus_BRouter signals 180° track returns by a red marker.