Via points not being created on import

I disagree. GPX is a standard file format which allows for extensions. The track and waypoints should still be correctly imported irrespective of any valid extensions.

It's ridiculous to expect people to only ever create GPX files in LocusMap and never for example to import a GPX file generated by someone else (e.g. a challenge event organiser).

Gpx only describes how to basically generate a simple waypoint or a track by trackpoints or a route by routepoints. Locus and others so indeed do display you that basic functionality of displaying a track and free positioned waypoints this by the gpx standard. So far so good. So your gpx file is correctly displayed by that.

But gpx does not describe how to implement the extra functionaly as how to produce Via Points nor Shaping Points nor any other such extra's. Gpx allows you (developpers) to do so by adding a gpx extension. Any app or program can so produce their own propieratary extensions. But these propietatary extensions (the extras) are mostly incompatible with each other applications.

Gpx by the standard only ADVISES developpers to please correctly describe and document their extra extensions. ADVISE so is mostly neglected. The result is that most app developper do not document their used extension. A fact.

To say only the Garmin compaby seems to correctly describe and document their extensions and also the topografix company has also an extension available for developpers that can be usefully used for track colorisation exchanges by gpx. (Locus does use + even adds more extra by own extension)

Anyway Locus also does not describe the propietary extension, but on demand Menion will sure give you the necessary hints if you need.

It is by that information that BRouter web generate you a Locus navigation capable gpx by the Locus extension format. And if you have a carefull look in the BRouter web export selection you will notice there are different formats to be selected for the different apps to be used. Crazy ? Yes sure it is.

Thanks for taking the time to look into this further.

Yes, the GPX contains a recorded track supplied by the organisers for an upcoming event. I assume it was created by them walking the event beforehand. I would trust that this is accurate. If it deviates from OSM then this will be due to missing paths in the OSM data.

The GPX also contains 5 waypoints which I manually created (in the 3rd party software desktop software Quo mapyx). Each waypoint corresponds to a place where refreshments etc will be provided by the event organisers (they call them checkpoints - hence CPx). I want these to become "via points" in LocusMap. This is so that when I'm walking a (custom) LocusMap dashboard will give me the distance to the next checkpoint. Each of these waypoints should be on the track.

I'm not sure what you are intending to do in plotaroute - I certainly don't want to be editing the track that was supplied by the event organisers. As stated above, this is 100% accurate. I only want to add 5 via points to that track.

OK Guy, now I do understand exactly what you want here. Quite simple.

- To estimate the distance to your next target CP you can use the guide to point function.

This does not show the walking distance, but the bird's eye view distance to your selected CP. After the refreshment you then choose the guide me function to your next target CP.

The advantage is simplicity, without any additional track or waypoint editing needed.

- But you do indeed want those Via Points ? Right ?

To know the walking distance to the target CPs, so produce a via point at the track point closest to your CPs. Converting a track point to a via point was once possible without any risk to damage your original track path in the older Locus versions. But unfortunately, that very simple robust feature was later removed. * ?

Now you have to use that more complex and confusing Routeplanner for this very basic task. Confusing because some CP waypoints nearby (snap to street) are then indicated here as being Via Point "candidates". However, since you do NOT wish to recalculate, the diversions must usr the Routeplanner is therefore also a (too) critical operation.

I so have just converted those nearby track points into Via Points functionality for your original so undamaged track. The CPx waypoints positions so do even remain unchanged located at their original position too.

Not carried out task with the Locus Planner, which is just a nonsense complex tool for this o so simple task.

* Providing this function in the non-critical trackpoint editor, as with older Locus versions, has been requested by users but was refused. :-((

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

Thanks. I can see you've created the "via points" by adding the <symbol>pass_place</symbol>. I think this is just an alternative way of doing the same thing.

If I import this track, then go to "route planner" then I can see the viapoints as expected. If I then go back (top right back arrow) and immediately go back into the "route planner" then some of the via points have been deleted! If I then go back (top right back arrow) again and go back into the "route planner" then some more via points have dissapeared.

TLDR; The bug seems to be that the "route planner" is deleting "via points".

Guy, once again. It doesn't work like that and it can't work like that.

On file imports with waypoints, only the special associated Locus Waypoints or the trackpoints with sym pass_place are rightly recognised by Locus as being announced Via Points.

The main bug in the Locus Planner is that it still gives you the false ILLUSION that it will show some simple freely positioned waypoints at random positions as being Via Points. And this is a serious error and imperfection in the Locus Planner implementation.

I think you're wrong about what LocusMap creates as via points, but that's not important right now.

There is definetely a bug that going into the route planner is deleting via points. You should be able to verify yourself by following the steps I detailed above.