-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get current navigated track data into tasker variable #26
Comments
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. |
Hi 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: 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 |
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 |
I did a test and:- 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 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. 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. |
above should say "GPX contains sym tag data, which I use, CSV doesn't". |
What tags do you need? I talk about 12 times less size, so 7k vs 80kb Example:
274B vs 12B
or all fields: 78B
|
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. Header is: 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) |
sorry don't know why it put that line in big size and in bold. Wasn't deliberate :-) |
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
The text was updated successfully, but these errors were encountered: