Autodetect and select navigation points from simple waypoints in a trackfile

0709 shared this idea 2 years ago
Completed

Autodetect and select Navigation points from simple Waypoints in a trackfile with merged single (way)points.

Single points identical in position AND timestamp with single trackpoints are promoted to Navigation Points, and selected by the Navigation system. All other single points are to be considered as simple waypoints, and selected by the POI alert system. This should allow flexible support of ALL Navigation(course)points, including free waypoints and be fully compatible with idea:

http://help.locusmap.eu/topic/edit-track-creation-of-waypoints

more info:

http://forum.locusmap.eu/index.php?topic=4178.msg36848#msg36848

Comments (23)

photo
2

Auto detector navigation points ? It is very well.

Voted !

photo
2

Willy, when you say "trackfile" I guess you mean TCX format file? If Locus compatibility/ interoperability with Garmin GPSs, Garmin software (Training Center), and other online websites that can import/ export TCX files is implied in your suggestion, then maybe it needs to be stated more explicitly?

photo
1

Yes Andrew, in first instance to be functional using .tcx file (to share). Sure, I was seriously worried for eventual compatibility issues in other software. I tested a .tcx course/coursepoints file, and changed the timestamp of one coursepoint with notepad editor. This file is not rejected by the otherwise very critical Garmin Training Center. The point is still known by TC, but no longer part in the strictly timed Navigation order list wich is ok. See picture example in the .pdf, from original and the adapted file. Imported the file also into Basecamp, JaVaWaRTWtool,TrackNavigator and online service RWGPS and BRT. Some imports did not show the changed point, some others did even accept this as Coursepoint. But at least the file was not rejected. I can not test compatibility with a Garmin Edge 705 because I recently sold my unit ;-)

photo
1

Only supporting .tcx file system ?

photo
2

Use popular gpx, out of the waypoints, select and promote associated points into Navigation points, use non strict Waypoints for information. This should provide same strict Navigation performance as the tcx file system and additionaly support total free Waypoints.

photo
photo
2

Hello guys,


if I understand correctly, you want to import track together with waypoints, merge them together and use attached waypoints during navigation right?


In this case, I think waypoints are already correctly attached in Locus, but I do not understand how to use them. Every navigation waypoint in Locus, needs to have an "command". Defined action that should happen on certain place. And common waypoints do not have this command. Or am I missing something? Thanks

photo
2

The Navigation order: System similar as by tcx <PointType>. In gpx is <sym> element.

http://www.topografix.com/gpx_manual.asp#sym

Text of GPS symbol name. For interchange with other programs, use the exact spelling of the symbol on the GPS, if known.

Known: Left,Right,Straigt. Not documented and unknown are all other internal <sym> texts.

Example unknown <sym>: Bearleft ? or Bear Left or bear left or Slight Left or ?

If <sym> not recognised: Use alternative direct speech from field: desc -> name

photo
photo
2

What is the problem ?

- Garmin .tcx: Navigation by associated Coursepoints, no free Waypoints support.

- Popular .gpx: Supports free Waypoints, not recognising associated (nav)Waypoints.


What is the current behaviour of Locus ?

- Use .tcx for strict Navigation only or .gpx for free Waypoints info only.


How should Locus work in the future ?

- Support both, and Navigationpoint and Waypoint styles using popular gpx. (page 1 linked pdf)

Locus finds selects and promotes associated points into Navigation points (page 3 linked pdf)

Generating strict timed Navigation commands and free Waypoint info messages.


Info: https://www.dropbox.com/s/3fmpc56xb7b8xfo/Navpoint_Waypoint%20guide.pdf?dl=0

photo
2

Willy,

I might be mistaken, but the way I understand it, this would "promote" all waypoints that I set with Locus while recording to navpoint when I re-import an exported track. So right now, the way it's phrased, it's not compatible with my idea you linked above.

Could you please rephrase this, otherwise I'll have to vote it down...

photo
2

Action: track record, add point. Waypoint timestamps are later in time than same positioned trackpoints, if point added by a *normal user operation. Result: non associated


*I had several tests, retries to be able to generate "special" associated waypoints by the add point function during track record. Setting: track record each second. Only if within 1 second, add waypoint and fast save button action, there is possibly an equal timestamp.


Locus v 3.9 and 3.9.1 export to gpx track.

The waypoint Z time is correct but trackpoints timestamps are - 1 hour off !

In the above tests, to conclude, I corrected the timestamps.

I think was already reported before by forum member(s).

photo
photo
2

Another thing:

With the above idea, exporting a (recorded) track and reimporting it in Locus wouldn't lead to the same track. I think exporting should be usable for backup purposes, so with that idea, it wouldn't be anymore.

-> Cannot support, sorry...

photo
1

I suppose this brings no change for your use. Track import with or without associated waypoints, they just stay simple waypoints. Because the main change, recognise associated points happens after pushing the Navigation button. Not using navigation, I think you will not observe a change.

photo
1

A Renewed request, triggered by evolution and recent new Navigation *experiences using Locus version 3.18.9.8.

Recognise three gpx associated Waypoints as Navigation Direction Points, promotes a gpx file as Navigation file with already integrated instructions.

Or use a very similar technique for gpx file navigation as existing system in use for tcx course navigation.

Locus NAVIGATION ! If importing a gpx file and associated waypoints, SET merge track and points !

Tcx courses(tracks) and associated coursepoints(waypoints)

Coursepoints are Locus "Priority_Points" TTS announced with symbol display in "Navigation_Button".

Out of all (16) Coursepoints, 3 Coursepoints have the special status to be "Navigation Points" TTS announced with symbol display in Navigation_Button

Left Direction by Coursepoint <PointType> Left.

Right Direction by coursepoint <PointType> Right.

Straight Direction by coursepoint <PointType> Straight.

Gpx navigation_track and associated waypoints. A tcx clone by gpx.

Associated waypoints are Locus "Priority_Points" TTS announced with symbol display in "Navigation_button".

Out of ALL associated waypoints, 3 waypoints should have the special status to be "Navigation Points" TTS announced with symbol display in Navigation_Button.

Left Direction by associated waypoint <sym> Navaid, White/Red OR Left.

Right Direction by associated waypoint <sym> Navaid, White/Green OR Right.

Straight Direction by associated waypoint <sym> Navaid, White OR Straight.


In zip attachment test example files. Start Navigate (simulate). By actual Locus version 3.18.9.8.

- tcx course files with 2 additional Priority Points.

Navigation TTS announced and <Notes> of both Navigation and Priority_ Points as text display in the map top info bar.

- gpx navigation track with some additonal demo Priority Points.

* Actual version not recognising the 3 integrated L/R/S 'Navigation_Points", Locus adds own generated instructions :-(( Also does not display the <desc> information of points into the maps top information bar :-((

* Displays ALL (= more than +16) standard known waypoints Icons (Locus Priority Points) in the Navigation Button :-))

More info: http://forum.locusmap.eu/index.php?topic=4178.msg42614#msg42614

photo
1

I would like this also

photo
photo
1

Sounds like a good idea to have general "free" waypoints and "special" navigation "priority points" supported from the same gpx file!

Also, this could eventually lead to a more general gpx format "standard" for navigation purposes without the need of special app-specific extensions -> better interoperability between apps (if they implement support for it).

photo
1

gpx navigation by the waypoint association method.

A most actual report comparing Locus tcx/gpx navigation.

http://forum.locusmap.eu/index.php?topic=4178.msg42614#msg42614

photo
1

Hello guys,

I'll probably needs some help here. As I see, topic has 19+ votes, which is nice and it means some interest in this topic.

Unfortunately base idea is still not perfectly clear to me. As I understand it:

Base idea: import file with track and waypoints and use certain waypoints as navigation commands, correct?

Current situation:

TCX file format: course + coursePoints are well supported and should work without a problems now. Why? TCX course format is directly made for this purpose

GPX file format: no united official support for navigation over this format. Same problem discussed in BRouter support forum. Almost every navi software export own version.

So, if I understand correctly, TCX support is done. GPX except street names also. So question: WHY to add precise support for GPX, when there is no universal format and also no desktop app that may generate compatible GPX files?? And please, 19 votes = 19 interested people, so I'll appreciate some short feedback, thanks!

photo
1

No worry Menion. Idea is practically implemented by evolution.

Tcx by associated Coursepoint = perfectly Implemented.

Gpx by associated Waypoints = nearly finished in Locus, just misses that finishing touch in the nav implementation itself.

Only small issue is: The gpx <desc> attribute is not that nicely supported as in Locus perfect tcx <Notes> implementation/examle. That is all !

See picture in http://forum.locusmap.eu/index.php?topic=4178.msg42614#msg42614

I hope that picture tcx versus gpx coursepoints list clears all up.

Otherwise this idea: = Completed !

(My congrats, and thanks for your efforts to even support a "non standard" but promising gpx method).

(btw...I can easily custom edit by gpx pc editor program.) On some occasions a little bit easier to do than on smartphone even when method is not a standardised system.

photo
1

Thanks for answer Willy, you confirmed me what I thought, now it's clear, thanks.

I'm still little worried about adding support for reading "desc" tag as "street name" over GPX file. Descriptions may be quite long and it will need some check if it isn't too much ...


If you export any route with navpoints to GPX, you should see Locus extension. I should rather try to improve this or create some new, more universal usable extension format if there will be interest.


Anyway problem will be same ... no general support for custom extension in any other application and creating routes in text editor? Crazy ....

photo
1

I'm still little worried about adding support for reading "desc" tag as "street name" over GPX file.

My answer:

No, no worry...as gpx<desc> is the exact mirror system as by tcx<Notes> so, no problem.

And no, no crazy text editor route creating.

Locus/Brouter generation is marvelous system. I do use 95% of the nav operational time.

Custom edit of a Locus navfile by pc program is not optimal because of the <extension> system.

(Locus in house solution = also no universal standard system)

Still some navtracks however are generated by websites and output tcx.

And tcx has 16 x PointType limit, standard set by our Garmin friends, without POI support.

After converting tcx into a gpx association system there are no such limits.

- All attributes are clear human readable understandable language.

- Custom edit to be done by graphical gpx (I prefer) pc program.

- Easy add (++16) all known <sym> Icons to used as (nav) Priority Point or as simple (free) POI.

- Easy edit inclusive free <name><desc>...and guess what...Locus understands this file system !

Also "Track Navigator" (let's not go in detail) does..but is by far not as perfect as Locus implementation.

Willy.

photo
1

Good day Willy, thanks for a feedback.


I was just working on this, made some changed to GPX import and set description as internal "Street name" parameter, like in case of TCX files. Unfortunately, when I'm not sure about something, I revert it and leave it on later. And I have this feeling here. For me, these extra modifications to GPX import still looks like something unwanted, like something that may break compatibility and confuse users in some cases (like when then setup custom symbol that will match to any of Locus Map navigation commands and then Locus will read whole point description during navigation).


I'm sorry, I'm ending with this topic. It has high number of votes, but except from you, I do not have any feedback from other users and I'm not really convinced about it's usage. Thanks for understanding and your patience.

photo
1

Message received. Maybe have to change 0709 into "Don Quichot" ? ;-)

photo
1

As far as I can see it, at least OSMAND (although having an own gpx extension for streetnames) and TrackNavigator seem to make use of the <desc> tag.

At least that's what I wrote some time ago when discussing about street names in brouter group: https://groups.google.com/d/msg/osm-android-bikerouting/LL8vW-kNmPg/nTv-QJWBBAAJ


Maybe make usage of <desc> tags optional first to allow testing?

You see, I'm also not 100% convinced...

photo