Falcosc / locus-addon-tasker

Locus Maps API useable as Tasker Plugin
GNU General Public License v3.0
9 stars 2 forks source link

Get current navigated track data into tasker variable #26

Open algil opened 2 years ago

algil commented 2 years ago

Hi, Question: - Can the Locus/Tasker plugin get the currently guided/navigated track from Locus into a tasker variable in e.g GPX format ? I can see that the trackID is available in "Request Sensors and Stats"/guide_target_id, and there appears to be a Locus API for it as in https://github.com/asamm/locus-api/wiki/Work-with-known-track but I can't see an option in the plugin config to use this.

Currently I am using the tasker/Autoinput plugin (button pushing/screen-scraping) to export the current track to a file then reading it in tasker. I use this after Recalculate or Navigate-to actions. However this is vulnerable to changes in Locus, changes in Android, timing issues, and needs screen on etc, so is not ideal.

If it's not currently available in the Locus/tasker plugin could it be added ? My tasker/JS code currently expects gpx format so getTrackInFormat would be good. I'm not sure what the Locus track object structure is (getTrack) - can't see it documented anywhere, so not sure if suitable.

Thanks Alan

Falcosc commented 2 years ago

The GPX track will be too large to fit into the intent. But CSV would be fine.

But your issue is: you need the trackId. There is no API to obtain the Track Id, it is something you get after importing GPX files via API into Locus. But if you just need the current navigation track, I can share the undocumented/unstable technical Id for the current navigation track.

algil commented 2 years ago

Hi What is the maximum size the Intent can handle? My GPX file would be max about 100kB , usually less (e.g 60 or 70kB). I thought this would be OK.

On the trackID maybe I am misunderstanding something. Doesn't the locus/tasker plugin variable "guide_target_id" already contain the trackID ?

So for example, if I start navigation for track number N in Locus Map (with column _ID = N in tracks.db tracks table) then do: 1/ Run locus/tasker plugin "Request Sensors and Stats" - it returns guide_target_id = N 2/ In Locus, tap on the Nav arrow, then tap on the Recalulate option - new track is created (not saved in tracks.db) with new name based on date/time. 3/ Run locus/tasker plugin "Request Sensors and Stats" - it returns guide_target_id = 1000000001 4/ In Locus choose option "Navigate to" and navigate to new point - new track is created (not saved in tracks.db) with new name based on name of target location. 5/ Run locus/tasker plugin "Request Sensors and Stats" - it returns guide_target_id = X where X is next in sequence after maximum stored track ID in tracks.DB.

So I was expecting that in the code to call getTrack or getTrackInFormat the trackID can be obtained in same way as done already to populate guide_target_id. Is that not correct ?

Thanks Alan

Falcosc commented 2 years ago

guide_target_id could be a point instead of a track, but maybe I am wrong.

You could add the GPX tags around the values of the CSV output with little effort in JS

algil commented 2 years ago

I did a test and:- Guidance or Navigation along a track, and Navigation to a point, (so whenever there is track to be followed) guide_target_id contains the trackID Guidance to a point (no track involved just straight line to point) then guide_target_id contains an 11 digit number which must represent the target point in some way.

Yes I can process CSV if needed. I convert the GPX (or could be CSV) to a JS object in JSON format anyway, and save in a tasker global variable. I do myself prefer GPX for couple of reasons:- Size of CSV is not much different to GPX - e.g. I exported from Locus a track with several hundred points and waypoints, CSV is 72kB, GPX is 80kB. So not much difference. GPX contains data, which I use, CSV doesn't. Dealing with embedded quotes can be awkward in CSV.

I had a look at the getTrackInFormat documentation and it says it supports FIT, GPX, KML, TCX. So not sure if CSV is possible ? Or maybe the documentation isn't up to date. There is also getTrack but its not clear to me what the output of that looks like.

I can't try these out because I'm not an Android developer, so relying on your excellent plugin !!

If you get time could you see if this is feasible ? e.g. Check if getTrackInFormat works with trackID using content of guide_target_id. If you do include it in the plugin then maybe the format can be a user selectable option.

algil commented 2 years ago

above should say "GPX contains sym tag data, which I use, CSV doesn't".

Falcosc commented 2 years ago

What tags do you need? I talk about 12 times less size, so 7k vs 80kb

Example:

<ele>657.700000</ele>
<time>2019-03-20T15:19:08Z</time>
<fix>dgps</fix>
<sat>9</sat>
<pdop>1.20</pdop>
<extensions>
<gpxx:TrackPointExtension>
<gpxx:speed>1.41</gpxx:speed>
</gpxx:TrackPointExtension>
</extensions>
</trkpt>

274B vs 12B

50.786265,15.101354

or all fields: 78B

2019-03-20T15:19:08Z,50.786265,15.101354,657.700000,dgps,9,1.20,1.41
algil commented 2 years ago

I exported same track from Locus in GPX and CSV format. Waypoints are only small part of size. (5% of CSV 15% of GPX), Most is the trackpoints. GPX trackpoint 105 bytes. Usual form. CSV entry is 109 bytes. For example: "2","54.498664","-2.922761","180","2021-10-29T01:00:01.000+0100","0.89","","","","","","","","NY 40335 11876"

Header is: "pos","lat","lon","alt","time","speed","bearing","acc","heartRate","cadence","temperature","strides","speed_sensor","custom_coords"

So there is a lot of junk included in the CSV trackpoints which makes it in the end similar size to GPX. Can't see any way in Locus of choosing which fields to export in the CSV.

The CSV doesn't include the sym tag in navpoints - in gpx sym is included which is the code for the waypoint nav command (eg, straight, left_slight etc ). This can differ from the Name value. I use sym for direction of track and Name for path direction, So it could be e.g. Bear left and keep right. Track turns left (and forks) and choose right hand path. Anyway, this isn't critical.

(tried to amend size/bold of comment)

algil commented 2 years ago

sorry don't know why it put that line in big size and in bold. Wasn't deliberate :-)