Navigation gpx wpt attaches to unexpected trackpoint

0709 shared this problem 3 months ago

Navwpt's don't always attach to the "first met" corresponding trkpt.

Example gpx file by "" web in attachment.

wpt 2 "Right Turn" to be attached to trkpt 3 is attached to trkpt 47 !

Comments (21)


Actual Locus promotes even half associated (position match) gpx to be a navfile.

Navigation by correct ordered navwpt's and a position match with a corresponding trkpt.

This allows 'basic' navigation by many more external (web) generated gpx nav files.

Some Locus features only available if gpx contains compatible <sym> Icons !

I double checked the external generated gpx file with reference Track Navigator app.

By TN the navwaypoints are exactly "consumed" one by one in a correct forward order.

TN displays <desc> text if available, if missing the <name> text in the nav bar ;-) hmm..


Good day Willy,

thanks for a bug report. Issue was caused by missing time in waypoints and Locus then attached waypoints to incorrect trackpoints. Will be fixed in next version.

About your second message, what means "Actual Locus promotes even half associated (position match) gpx to be a navfile."? As I see, all waypoints from attached file are correctly converted to navigation points.



Menion wait wait !

Track and waypoints (no timestamps) from external source Bikehike web ! (other such sources too)

Full associated: Wpt corresponds to trackpoint by position and timestamp. Strict even when waypoints in the waypointlist are timely unordered. (I tested on a previous version)

Half associated: Wpt corresponds to trackpoint by position only. Navigation functional without timestamp on condition that listed waypoints are in perfect (timely) order, one to next one.

TN for example never double checks the timestamp even if available, and relies only on a perfect ordered waypointlist. TN nav accuracy is 99%. (I know how and when the 1% failure). Waypoints are 'consumed' one by one. Any next "unconsumed" waypoints do check for a match with a next corresponding positioned trackpoint and so on and on.

Discovery: Very promising nice excellent !

I notice actual Locus also do connect such a 'perfect ordered waypointlist' with the trackpoints only by position match ! Locus actual already navigates uncomplicated tracks. But has failures by more complicated (test)track. Locus navigates also the gpx tracks from many more external sources now. A nice promotion for a Locus install, as new users are able now to have their very first positive navigation experiences by many more external source (simple) gpx files.

Half associated: Notice the example bikehike file has no timestamps in the waypointlist, track has, but your'e free to change to represent to another speed, or even just delete. The reported issue : At common positioned paths/trkpt's the orders seems to be generated +/- at random.


Willy, thanks for a precise description, I think I've got it.

I believe I've improved system now, so let me know, if next Beta version will work better for your special test files,

thank You!


V report.

On desk tests by only 2 (non T) files. (Half associated) (Bad weather, so for now no field test)

The good news.

The waypoint list is correct. Orders by the few used and tested files are precise.

But do not mark as "solved" just put "on pause" for now.

The bad news.

I can't test the complicated testfile with (critical) T (out and return) deviation

It seems the T problem solution offered completely destroys the Navigation experience.

Can' t be used ! DO NOT publish this Beta. Strict and non strict Navigation result is NOK.

Navigation at move jumps over short distance, is not fluent, and near the T the nav result is completely broken.

To simulate: By manual center cross move, and by "Lockito virtual" to see the "jumpy" map movement.

If cause unknown (not solvable) a (temp) return to previous version ?

I expect that this serious navigation trouble is caused by:


Strict even when waypoints in the waypointlist are timely unordered. (I tested on a previous version)

1. Double check ! If full association by timestamps in both trkpt's and wpt's is available ! Has Priortiy !

2. Only If by above check full association system is not available, the waypoint list order is reference


More bad news. V After extra tests I confirm the robust navigation by tcx files also is lost. Suggest to keep the actual V3.27.1 Navigation system.


Keep the "Double Check": Prevents the return of already previously solved issues !

Compare +/- results by actual (non Beta) versions.

Full association.

Track Navigator : 99 correct and 1 false order. (By correct wpt list, without double check)

Locus Pro 3.27.1: 999 correct and 1 false order. (By wpt list inclusive double check)

Half association.

Track Navigator: 99 correct and 1 false order. (By correct wpt list)

Locus Pro 3.27.1: Some orders at random. (Actually is not supported)


V_3.27.1.7. Do not publish Beta ! Keep actual version !

+ The bikely files inclusive the nav commands seems to load correct, but.....what is the price to pay ?

- Tests by a previously succesfull tcx source file at navigation are negative :-((

Actual version Pro: Switch to next command happens AFTER passing the actual instruction point. OK

Beta version: Switch to next command happens BEFORE passing the actual instruction point. NOK.

A worst example: Some turns at navigation skipped, not announced.

See comparing video's. Strict Navigation in Beta is broken. In video examples. L,R,S_turn symbols by the tcx source file. Video record without sound. (The turn was announced correct).

Video by Locus 3.27.1 Pro: Correct announcement of the first Sharp Right Turn, and only after passing the actual navpoint the next new instruction is shown. (At 18kmh (15 sec set) the sound announcement is at +/- 60 m before turn) Video record without sound, (The turn was not announced).

Video by Locus Beta: Skips the announcement of the first Sharp Right Turn. Next announcement already is displayed before even passing and announcing the actual turn !

Stopped any further tests.


Hello Willy,

it still do not work as expected, hmm.

Thank you very much for a tests. Seems that I've made system too complicated, so simple improvements makes it worst then before.

I'll revert "Strict navigation" to system of 3.27.1 version and look on it more deeply during preparation to next version in January.

I'll keep also this topic open and let you know here once there will be any progress.

Thanks Willy!


Good day Willy,

complicated task :). Firstly, thanks for testing and for additional information on forum in special topic.

If I may have one request on You: you often report me very large number of information, various GPX/TCX files for tests etc. I understand, there is a lot of work you have to do anyway my problem: such huge number of information leads on my side to situation, when I'm personally little confused what is wrong, what to do to simulate it and result is, that I do almost nothing.

So if I may ask: simplify your bug reports. Send me in best case one file and simple information like "import, start navigation from first point and on third point will be a problem". Possible? Thanks!

To this problem ... I was playing with it now. Reverted old system from 3.27.1, anyway I still think there should be a working solution. So one more attempt to next version ;). Thanks. Beta will be published probably tomorrow.


Compact report for complex problem ?

Test by a (low quality) trackrecord and tcx course.

Import record into Lockito app. Set: 18kmh Accuracy 1m +/-1m:

Lockito Replay: Start and Pause.

Start Locus Navigate than restart Lockito replay.

Compare Navigation at T section and later before Right turn.

1. By Locus Pro 3.27.1 = OK.

2. By Locus Beta V_3.27.1.7 = Disaster.

Record was started after the nav teststart ;-)

Navigate strict, no autorecalc, (push to nearest point) Go.


"Compact report for complex problem" ... I know, complicated task, but it will really help me to understand your reports and fix problems.

Thanks, this report was precise ... simulation started and with my private test version, all seems to work correctly. Maybe finally? :)


Aha ok ;-). So back to topic start, reported issue by Pro V 3.27.1 and file attached.

Attached picture also shows the original reported issue. See false Itenerary list order by Locus Pro 3.27.1.

You do say a correct solution now ? Final control by double check test:

Import navfile into Lockito app -> simulate virtual test drive.

Tnks for courage and efforts !



Locus V NOK.

Attached: File with points/tracks from Locus Map/3.27.1

Import navfile into Locus V // Import file into Lockito -> Start simulated drive.

Locus Navigate: Even before arriving at first turn "sharp right": Navigation Failure !


Hello Willy,

this is really intersting. Before, I did not used mentioned Lockito application, because my private version of Locus app allows me to use also a track for simulation. But because it worked to me correctly, I've followed your steps and tried to simulate this issue also with Lockito app and unfortunately no problem with latest version. Mainly in case of non-strict! navigation, there should be absolutely no change compare to 3.27.1 version.

Are you able to create for me a short video with visible problem on previously attached GPX track? Thank you Willy!


Aha ! That is the KEY. Use non-strict navigation, unset strict !

So set "strict" makes no sense anymore ? Strict to be used for ?

Indeed failure with Navigation set strict ! See video.

I already had a first fast *(night) test using non strict. A virtual Lockito replay test by 2 recorded tracks.

A low quality recorded track and a good quality recorded track ...both succesfully navigated.

Imported navigation (full associated) gpx track files (+tcx) : OK

Bikehike (half associated) gpx track file: OK

And (by virtual replay) tested the experimental simple to understand direct rte_rtept navigation: OK !

(I only very recently discovered that this gpx route file system is recognised and navigated by Locus)

See forum topic for the details.


Sorry Menion but I found another problem. But is not caused by the new method.

To my surprise also happens with the excisting 3.27.1 Pro version.

Issue: Go out of track using autorecalculate to point(via).

Before the next Via point the instructions are newly set by the auto(re)router. (B_router) and ok.

But after rejoining the next Via Point the already existing original turnindications further on the track are lost ?

See pdf.


Thanks Willy ... hmm more and more it looks, I'll have sit on "navigation" system and completely rewrite it to more stable one. Thanks anyway, I'll look at it ...


By V_3.28.1.3

Back to the original problem/question: The Bikehike files (halfassociated):

Correct ordered navigation announcements using the bikehike's Via points : OK

(Other single issue's will be reported by new problem or forum).



Hmm this is really good news, finally ... thanks!