Implement the "Export track as FIT/GPX/... etc" function

[algil]

Please consider:

Idea: Trigger Locus Map to export the currently guided or navigated track into a folder in shared storage - e.g. downloads or suchlike - and return the folder and filename to tasker so that it can be subsequently read in by tasker.

This would be useful both for tracks already saved in the Locus DB and especially, if possible, for tracks created by Recalculate, or Navigate To.

(Note: this replaces Issue #26 which was on a similar theme)

[Falcosc]

There are 2 interfaces to export tracks.

Let's start testing the first one - export.

1. Download the Locus API Sample App
2. open any saved track (API needs a trackId, we can talk about how to get it later)
3. use the track actions menu to click on the Locus API Sample
4. click on the Get as GPX button in the dialog https://github.com/asamm/locus-api/blob/4f6565a67f9832c4da7a4a6a76c853f5eb5948d8/locus-api-android-sample/src/main/java/com/asamm/locus/api/sample/MainIntentHandler.kt#L189
5. any UI interaction after this click can not be controlled, only the Toast "Process successful" is custom, so anything between "Get as GPX" and "Process successful" is fixed/part of the export interface.
   I have never used it, so if there is some strange UI interactions or unwanted popups, that's the point to test and decide if they are acceptable because they can't be disabled.

What do you do with the track? How do you process it?
Because we can use the 2nd API if it helps to process inside tasker.

1. PluginTask: Load Track by Id (Track gets stored in Plugin Memory)
2. PluginTask: get loaded track stats: point count, start time, trackPointer
3. PluginTask: set trackPointer to point 500
4. PluginTask: get next 100 track points with fields lon,lat,altitute
5. do something with the 100 points
6. PluginTask: get next 100 track points with fields lon,lat,altitute
7. do something with the 100 points
8. PluginTask: set trackPointer to point 14:02.44 UTC
9. PluginTask: get next 100 track points with fields lon,lat,altitute
10. do something with the 100 points

If we page the result we can load it directly into tasker as variable, either json or csv or anything which fits into a string. I don't know if tasker supports arrays. So you have to play arround how easy it is to parse a multiline csv string or a large block of 100 points json by putting some example data into string variables and see how it feels to work with them in tasker.
But we can't do one point per task because it would take forever to load 300 points in this way since communication is async via intents instead of direct content access

Maybe there is a 3rd way, maybe we could get the content provider access directly into tasker, you need to check if tasker supports content provider access.

Selection of the right solution depends on how you process the track contents: so what exactly do you want to do with the track points?

[algil]

If you refer to the Locus API Sample app in Google Play it is not visible there for any of my devices. I can see it in Windows Google Play and it says there it is not compatible on any of my devices (Android 13, 14, 8), and I tried Bluestacks Android Emulator for Android 7 but same again. Looks like it needs an update.

[Falcosc]

Then let's just assume it does not prompt anything on UI. How do you process the track points? Would it make sense to process them in tasker as string or not?

[algil]

Hope this helps.....
I use tasker Javascript action to read the GPX file from shared storage, process it to create array of objects for trackpoints+waypoints of track, stringify it to JSON, then store it in a tasker global variable.
Track point object properties are 1/ index 2/ lat 3/ lon 4/ dist (from start along track) 5/ bearing (from previous point) 6/ wptype (Nav or Via) 7/ wpaction 8/ wpname 9/ wpdesc.
Also get POIs in bounding box around the track from Overpass, stored in another global variable. My GPX can also have waypoints not on the track (usually for possible escape destinations) and these are stored in another global var. This load/convert task takes a few seconds. I've never had any issues with size of the track - they are typically around 50KB, max 100KB both GPX and Json. Depends on length etc. obviously. See attached for a short section of track as Json string.

GET_GPX_json_example.txt
(size could probably be reduced quite a lot by reducing unneeded high accuracy of distances and bearings)

Other tasks run JS to make use of that data, mainly to generate speech output to earphone. Tasks triggered by bluetooth device buttons, smartwatch buttons, or voice command. Also by timer - every 2 minutes a task calculates current target point on track, distance to track, and generates off course warnings by speech and so on.
I went this way because it would be unrealistic to ask for Locus to do everything I would like, but with tasker, the plugin, and the track data I can do what I want myself.

So for myself what is missing is, from tasker, to be able to get Locus to export the currently navigated track as GPX to a known folder/file, so my tasker task can easily automatically update the tasker data whether at start or during hike, after reroute or navigate_to and so on.

However in addition to that, to make it useful for others, it might be good to have an option to do something similar in the plugin and return to tasker a JSON string representing the track and way points (content/structure to be decided), though I don't know what limit there might be for passing data from plugin to tasker.
The caller can then do what they want with this. If the user doesn't want to write javascript then Tasker can interpret JSON automatically as described towards bottom of https://tasker.joaoapps.com/userguide/en/variables.html.
I've no idea whether anyone else would find this useful - hard to predict - though reading the forums there are certainly plenty of people doing sophisticated things with locus.
Tasker is very powerful really, and allows fairly complex things to be done with simple task actions, and for anything with more extended/complex logic or data manipulation it can be done in javascript.

[Falcosc]

100KB max XML is nothing.

So we can skip the exporting part and directly work with the data.

PluginTask: Load Track by Id = %trackId
PluginTask: get track points - Offset: 0 Count: 100 fields: lon,lat,name type: "waypoints"

%trackId = either get the id from a track action task or use request data field %guide_target_id
type: "waypoints" we start with waypoint or locations
But with waypoints I see a problem, they may not be ordered, you can create waypoints outside your track

Structured Variables is the new stuff, that's so much better, that changes everything. By the way, does the %data variable already work in the run tasks from locus tools? Like when you click on the track submenu to get the track id into tasker?

Do you need help with finding the current position in track?
PluginTask: get track point index - typ "next Guide/Nav Point"
"next Guide/Nav Point" only works if track was loaded from %guide_target_id

I can give you waypoints in the tracks action task to play with because I can't find your fields there.

[Falcosc]

%waypoints
%data
%fields

Are the 3 hidden variables you get when you run a task from the track info screen action.
Build 85 in open test will have the new %waypoints variable

Please try out how json processing works with %waypoints is has all I found on the waypoint object
There are even some calculated values in there. So sometimes it may be beneficial to reload track from locus to get new calculation results

https://github.com/asamm/locus-api/blob/4f6565a67f9832c4da7a4a6a76c853f5eb5948d8/locus-api-core/src/main/java/locus/api/objects/extra/GeoDataExtra.kt#L791-L1071

[algil]

"click on the track submenu" : yes works:
%data and %fields are filled.
%waypoints is not set.

I'll take a closer look and get back to you tomorrow.

For waypoints what I do currently from the gpx is get trackpoints into an array, waypoints another array and step through them matching on Lat/Lon. If they coincide then its a navpoint or viapoint. If not then its an independent waypoint/poi.

[Falcosc]

maybe yo didnt got the new a version

did work with an track plan generated with navigation hints

[algil]

ach... got it now.

[Falcosc]

Does the data structure work for you? What about this Taskdesign?

Plugin: Get Track Points (Track, Type, Location Fields, Waypoint Extras, Point Count, Point Offset)

Track: picklist - text in brackets will be displayed below picklist

• last loaded (reuse result from last load to extract more than 1MB of point details via Point Offset)
• load last shared (load track from your last track menu run task action)
• load guide track (load current guide/navigation track)

Type: picklist

• Waypoints
• Points

Location Fields: multiline text prefilled with

Id, Lat, Lot, Altitude, Time, Bearing, Speed

helptext - Waypoints will always return Id and Name field

Waypoint Extras: visible for Waypoint Type, multiline text prefilled with

Description, Comment, RelativeWorkingDir, Type, GeocacheCode, PoiAlertInclude, Language, AddressStreet, AddressCity, AddressRegion, AddressPostCode, AddressCountry, RIndex, RDistanceF, RTimeI, RSpeedF, RTurnCost, RStreet, RPointAction, RPointPassPlaceNotify, RComputeType, RSimpleRoundabouts, RPlanDefinition, RMaxSpeeds, RWayTypes, RSurfaces, RWarnings, OsmNotesId, OsmNotesClosed, LopointsId, LopointsLabels, LopointsOpeningHours, LopointsTimezone, LopointsGeometry, Lomedia, LopointReviews

Point Count: 100
helptext - only 1MB data per request

Point Offset: 0

[algil]

That looks great.
I checked the waypoints variable and structure is fine...

• non-track independent waypoints are OK - they have no Rindex.
• RPointAction" : is there a translation table available to its text meaning ? Should it be presented as text value ? I can work it out if not.
• "Lot" - typo ... "Lon"
• "Time" field - not sure which Time that contains

For Location Fields - which bearing do you mean ?

Actually - slightly off topic - there is a bit of confusion I think in the API about bearings - the guideWpt.... fields now refer to next waypoint but guideWptLoc refers to the guidepoint on the track. There was a change made as described in forum post:
https://forum.locusmap.eu/index.php?topic=5598.0
This resulted in the bearing (Azim and Angle) to the guidepoint no longer being supplied. I calculate it myself. Its the direction to go to follow the route which is different to the direction to next waypoint

Anyway, I suggest to go ahead with your proposal and make adjustments if needed after testing etc.

[Falcosc]

The action translation is used to put into the name field if generated by locus maps.
I replaced the internal action number with the internal name.

What about the data types?
Can RIndex String be used without convertion to access the right place in the points array?

%points is the variable for the points json array

Location Field Bearing is the same like updatecontainer my_loc_bearing
"Direction of travel in degrees East of true North (in degree)."
I will think about a help text for the Location fields.

For waypoint extras, I will use this link as documentation:
https://github.com/asamm/locus-api/blob/Locus_API_0.9.62/locus-api-core/src/main/java/locus/api/objects/extra/GeoDataExtra.kt#L791-L1071

Does the jump to the correct line work on mobile as well?

[algil]

Rindex: Yes it works without conversion as index into points, however the tasker arrays start at 1 , whereas the locus arrays start at zero, So have to add one to RIndex to get the correct point.

Jump to correct line on mobile: Yes it works on mine.

Using %points %waypoints in tasker:-
If pass to javascript no problems of course.
If using directly in tasker actions, some comments:

1/The JSON syntax as described in the tasker variable user guide does not work directly on those variables as they were not created with Variable Set with "Structure Output..." checkbox set.
Anyway if you Variable Set it to another variable with "Structure..." set its then OK.

2/ If you want to access Nth object fully like {x:1; y:2} , it only seems to work if the whole array has a name
So for %mypts = [{..x:1..}, {..x:2..}.....] you can can access %mypts.x(N) , but not the full Nth object {..x:N..}
but if %mypts = {somename:[{..x:1..}, {..x:2..}.....]} then %mypts.somename(N) returns {...x:N...}.
It can be fixed, if wanted, in tasker by simply doing Variable Set %mypts = {somename:%points} with "Structure Output..." checkbox set

3/ RIndex allows reference from waypoint to corresponding point but reverse isn't directly possible (e.g if want to know if point is also a waypoint - hence why I merged them in my project)
However the following search seems to work:
%mywpts = {somename:%waypoints}
%pnt = N-1 (for the Nth point as counted by tasker starting at 1))
%wpt_from_pt = %mywpts.somename($?*"RIndex":"%pnt"*) returns object for that Rindex : {..... "RIndex":"N-1",......}
I'll try that some more to see how efficient it is if looping through the points.

4/ I'm assuming that the RIndex is always the correct array index of corresponding point and not the offset from the first point "ID" number - so e.g. if the point array "ID"s had any gaps it wouldn't matter (if that ever could happen)

Looks like the trackpoint bearing field relates to recorded tracks.. it comes from the tracks.db database Location table. I can't quite understand what the values mean yet. Don't seem to correspond to reality. I'll check further.

[algil]

Trackpoint bearing : yes it does make sense for recorded tracks. Direction of travel in degrees of recorded point(N-1) to point(N)