This object is in archive! 

Navigation Now Fails On Overlapping Course

Steve L shared this problem 14 months ago

Well, this used to work 5/21 and a subsequent update seems to have broken it. Here is an example course:

The course is input directly from RWGPS with an Android app using the Locus API. The app hasn't changed since this last worked so something has likely happened in the way that Locus pulls (and orders) Nav points from its internal database.

I have also exported the route via Locus and the GPX is also incorrect as shown in the attached file. Unfortunately I don't have visibility into the Locus database so cannot trace further.

Replies (3)



By design: Has a 180° trackglitch.

Since the system RWGPS does not generate U-turn navigation commands, detecting these vicious (sometimes small) trackglitches is quite difficult. Unexpected U-turns (caused by falsely positioned Shaping Planner Points) quickly and prominently displayed on the map could avoid a lot of such design misery.

Virtually no existing route planner generators nor apps highlight this simple but excellent tool visually on the map. This could avoid a lot of design woes and the now difficult search work and so optimise the route quality generation. Avoid undesirable U-turns by optimal map display ? How it eventually could look like ?

The U-turn command itself is not the problem. The cause of the unwanted U-turn is the falsely placed Shaping Point. So it is better to indicate the falsely placed Shaping Point. Once you place this Shaping Point in a correct position, the undesired U-turn and the associated track glitch will also disappear. That is why it is so important to keep the Shaping Points clear at all times. For this item Shaping Points save in all circumstances this so also until in the generated export gpx file fails also in the Locus application . Sad.


You are correct that the map does show issues which are a RWGPS problem. The RWGPS route planner has a mind of its own sometimes! The U-turn is a map/route problem that needs to be fixed.

However, the main issue is with rest of the overlapping sections. Check the cuesheet with the Locus generated GPX file and the issue should be apparent.

EDIT: I just fixed the U-turn issue and slightly modified the route so the cuesheet is now correct but Locus Nav is still wrong per the previous GPX file.


Your new gpx file has not been added, I cannot check it without your conversion app.

By Plotaroute "retrace" I fastly produced a gpx file, I do not note errors at the overlaps.



As for the "quirks" of the thus according to you "quirky" RWGPS router as you reported. ;-)

I know of hardly any routers that give optimal warning of these very annoying (sometimes short) trackglitches.

These annoying trackglitches are almost always the result of placing the Shaping Planer Points in a too hurried and careless manner.

I especially mention the "unannounced" Shaping Planner Points, because precisely these ones are often placed rather quickly and so carelessly.

With the "announced" Via Points, I think the positioning is usually a bit more careful and this way you can even "indicate" a desired U-turn by the way.

An example of a desired U-turn. A ride where you take a side road to a good "café" after which you turn back. Worthy of a U-turn and the extra announcement, no ?

The Locus_Brouter engine is one of the better router combinations at the moment as far as the alerting (red alert circle) of such vicious short trackglitches is concerned.

What remains very unfortunate however, is that after you leave the Locus planner this nice very useful user Shaping point info is then lost.

This is because Locus_Brouter navigation and the produced gpx do not fully support both the Shaping Point and the so falsely -triggered U-turn command.

You therefore need both in one combination in order to work with them smoothly. U-turns triggered by Shaping Points are mostly very suspicious.

Unexpected U-turns commands do alert you, and the corresponding Shaping Point is what you need to easily and quickly correct a design error that has occurred.

Once you drag the wrongly positioned Shaping Point to its correct position, the unwanted U-turn than disappears immediately.

Translated with (free version)


Well, I am now completely befuddled! I re-imported the route and the route appears to navigate correctly using "armchair" navigation. The new GPX also looks correct. However, this was not the only route that was misbehaving recently. I have a "real-world" test coming up tomorrow with yet another overlapping route (most bike routes do this to some extent).

So now I am scratching my head... I did notice an intervening Locus update from 3.57.1 to 3.58.1 so Locus may have fixed something.

Another thought... What does Locus navigation do if you start the navigation somewhere in the middle of a route. Google Maps has no trouble with this but what does Locus do?


Nice msg Steve, so provided the RWGPS design is correct, the conversion tool does a fine job.

Shaping Point & U-turn combi that triggers an alert tool in the route planning and the navigation result track could prevent a lot of mischief

Yes, Locus navigation start up in overlapping segments can be problematic.

This is because Locus switches rather quickly to a closest target trackpoint at navigate.

This is as Locus" flies quite randomly as a butterfly" and switches to a nearby trackpoint.

Strict Locus navigation focused onto track points prevents this, but is operationally unfriendly.

The navigation should optimally better focus onto next not yet consumed target Planner points.

This applies as well toward the many unannounced Shaping points as the announced Via points.

Locus neglects the functional nice Shaping Points, despite requests in as well navigate and to keep them pse intact in gpx transfers.

More optimal behaviour has been reported and demonstrated inclusive video demo by the Kurviger app, which does make full use of them.

The Kurviger navigation so is sure superior to the typical "butterfly behaviour" Locus navigation. Kurviger has a strict navigation mode toward all target Planner points but this is hardly ever needed.

These target points, still flexibly, can be skipped manual or even automatically, but the planner points are "a little bit more sticky" when you indeed than do deviate.

Better navigation experiences by more optimally using BOTH the Shaping & Via points as nice and clear navigation targets are reported, but the message sadly remains ignored.


Hi guys,

"flies quite randomly as a butterfly" > nicely said and agree, this should be improved.

Detection of small u-turns > Locus Map already do this for some time, check my screenshot!



@ Menion

<quote> Detection of small u-turns > Locus Map already do this for some time, check my screenshot! </quote>

Pse Sir, notice that this Locus very usefull router feature tool was positively mentioned and shared in a previous msg reply ;-) Yep, for sure is very well done Menion !

"The Locus_Brouter engine is one of the better router combinations at the moment as far as the alerting (red alert circle) of such vicious short trackglitches is concerned"


Even a more optimal usage of the important (imo) target "Planner Shaping Points in both the navigation and for later (re)planning calculation usage is still possible. Best is so to KEEP this very useful user input always available in both the navigation and the database and in the gpx file transfer exchanges.

Find some gpx examples that do very simply indicate the Shaping Points into the gpx files A & B and in the file 1 & 2 & 3 in the attached zip file pse.

Replies have been locked on this page!