@ Uli_LH…I suppose I am using the correct (new) tread for the next proposal ?
@ Robin. Not urgent !
Only when all the dust, caused by your new website, has settled
Unless a free extra offer for all ? Otherwise could be a niceTourer web extra ?
Planner agreement to do.
Desired scheduled U-turns should best be triggered by a Via Point.
Sloppy misplaced Shaping points at road intersections cause false turn instructions and *a nearby U-turn. These unexpected 180° U-turns (sign -98) indicate that something may have gone wrong with a somewhat too hasty route planning.
You can find the U-turns due to incorrect positioned Shaping waypoints in the turn instruction list pretty quickly. For a long route with many instructions you will have to spend a little longer tracking them all down. Click on a U-turn instruction and quickly find the corresponding Shaping Point on the map and correct it. When the unplanned unwanted (Shaping) U-turns are gone you will have *almost no false turn instructions left. By the way this procedure works very nice using the Kurviger app too !
The * Exceptions. So avoid planner mistakes and work accurately at waypoint placements !
It can sometimes happen that you are offered a return alternative over a nearby traffic circle.
In case of multiple lanes with a passage correction by a directional U-turn. EU:Left U. UK:Right U
Tourer web ? Cleaning tool.
Kurviger Planner notifies you of the total number of detected suspicious (Shaping) U-turns.
Shows a compact turn list with only the (Shaping) U-turns and the suspicious positions on the map.
You so do not have to search the entire Turn List manually. Then follow the same correction procedure as the non-tourer
If admin thinks this should be a separate thread, please move “in block”.
It is primarily intended for the website with the aim of keeping the app simple.
Provided good experience or not, this is possible later in the app maybe.
That’s how I imagined it in the past.
Automatic was intended for the next idea.
But we’re still a long way from that, so …step by step ;-).
For the classic route planning, therefore, formulated a little less drastically.
With careful manual planning, the number of annoying U-turns is limited.
In this way, the user himself retains the desired correction control.
Loading that route (app or web) and analyzing it, all “error” U-Turns are related to wapoints:
WP7, WP14, WP15, WP16, WP27, WP37, WP38, WP39, WP40, WP43, WP45, WP48, WP49
All of them besides WP45 and WP48 can be identified by an easy rule: U-Turn conected to a waypoint, with an other turn point less than 15m before / after. WP45 and WP48 have bigger deviations due to snapping next street.
So I would provide a rule, which is executed if a GPX route or track is imported:
If a U-Turn is connected to a waypoint, and an other turn instruction if less than 15m (to be discussed, if perhaps even 20m or 30m) before / after, shift that waypoint to the position of the turn instruction.
after shifting all waypoints, do a new route calculation
This would fix most of the “error” U-turns in that route.
If you have further examples of routes with “error” U-turns, please provide that examples here.
Even if stopover waypoints are snapped over 30m to an other turn instruction, from my point of view this will not harm even if user has to ride in an other street for 30m.
I tested the method a little more. Unfortunately not always 100% successful. I took the turn coordinates (6 digits after the comma), but sometimes still a track glitch appeared. It is too delicate for me. So I still do prefer manual correction. Fully automatic without final check I do not trust. You can just as quickly move a few wrongly positioned shaping points a bit further away from the critical road crossings.
I suppose by a Via edit U-turns so are mostly intentionally planned so I did nog suggest a “red” light warning signal.
Anyway Emux if you have a different opinion you are completely free to (eventually) apply this also on Via’s. No objection, of course not.
By the way the import file in the .gif was next one. TET_trk_0.50km_rte_ticks.gpx (13.9 KB) Import (gpx) route Overlay: Track Routing: Route Unchanged Max waypoints: 200
Locus recently has introduced also a trackglitch alert into the Locus Planner using the offline BRouter engine.
After tests I found out there is a small difference in track generation production by both router engines GH or BRouter.
Locus so optimised this alert method mainly for the prefered Locus_BRouter offline planner.
Read more in next.
As far as I can see this algorithm works fine - perhaps it would be useful to do the shift automatically in Kurviger (app and website), if a track has been imported and a route fitted onto it (as far as I understand, the example of @llodiers was created by importing a recorded track into Kurviger).
If you have further testcases or any ideas for improvement, please give feedback.