Locus activity export to FIT format
Hello,
I am new on this forum, but I use Locus highly : mapping, orienting, navigating, analyzing activities, modifying activites, etc…...
Sometimes I need to modify activities imported from plateforms, which Locus do perfectly (import fit file and then modifying), but when I export them again into fit format, files seems not properly/completely formatted (at least mine), not following the official sdk requirements, and thus not handled properly by some other tools : at least it is my own analysis.
I definitely decide to join this forum, to see if I can get some assistance and/or changes with fit files export function from Locus (for activities). I searched for other issues like this, but it seems not totally the same.
In summary, some mandatory messages are missing for exported activity file (SESSION, ACTIVITY) and some messages defined “correctly” but are missing some data.
I also try the add-lon locus-out-fit, but result is not good also, so I preferred to analyze direct locus fit export.
Is it possible, and for sure I can provide as many example or tests, to update Locus activity fit file export so that it follows the fit SDK which some 3rd party tools are following religiously ?
Thanks a lot in advance.
Here are some details and explanations, regarding one activity file generated by Locus : not changed at all : locus_fit_SnowShoeing_2021-12-30T12_15_35.fit
If I convert this fit file into CSV (attached also), here are my findings :
- There is a LAP message :
- In LAP definition there are correctly the mandatory timestamp and start_time : Definition,0,lap,timestamp,1,,start_time,1,,start_position_lat,1,,
- But missing timestamps and start_time data in LAP message : Data,0,lap,start_position_lat,"510378757",
- In the same LAP message :
- There is a total_descent definition : total_elapsed_time,1,,total_ascent,1,,total_descent,1,,max_altitude,1,,
- But no total_descent data in the message : total_ascent,"389",m,max_altitude,"1749.0",m,
- There is an EVENT message :
- With timestamp in the definition : Definition,0,event,event,1,,event_type,1,,event_group,1,,timestamp,1,,
- But no timestamp data in the message: Data,0,event,event,"0",,event_type,"9",,event_group,"0",,,
- According to FIT SDK requirements (https://developer.garmin.com/fit/file-types/activity/) , an activity file (type 4) must contain mandatorily an Activity Message AND an SESSION message
- And there are none in the Locus fit file ☹
If I tweak manually the csv file to add missing informations (LAP/EVENT ones + ACTIVITY + SESSION), the fit file becomes “OK” for uploading into other parties that are really strict regarding fit content. I also attached OK tweaked csv and fit files.
Hi Mick,
thank you for the very precise test & suggestion.
Indeed, I may confirm your observations, so I made a few changes that may cover mentioned problems. Give a try to the next app version (will be published most probably till the end of January) and let me know. Thanks.
Hi Mick,
thank you for the very precise test & suggestion.
Indeed, I may confirm your observations, so I made a few changes that may cover mentioned problems. Give a try to the next app version (will be published most probably till the end of January) and let me know. Thanks.
Hi Menion,
Hope you are fine.
Any news on this please ?
Thanks.
Hi Menion,
Hope you are fine.
Any news on this please ?
Thanks.
Hi Menion,
Just a kind ( and full of respect for the whole job done) reminder about this topic.
Lack of pause management in Locus for fit files, makes this almost useless 😔 to work with this file format.
Hi Menion,
Just a kind ( and full of respect for the whole job done) reminder about this topic.
Lack of pause management in Locus for fit files, makes this almost useless 😔 to work with this file format.
Hello Menion,
How is going this topic ? is there any beta i could test ? I would be happy to do so.
thanks.
Hello Menion,
How is going this topic ? is there any beta i could test ? I would be happy to do so.
thanks.
Hi,
Waiting eagerly for new beta to test 😊. Hope it is not the 4.11. 2 already on the drive, and I am waiting for nothing ? 🤔
Hi,
Waiting eagerly for new beta to test 😊. Hope it is not the 4.11. 2 already on the drive, and I am waiting for nothing ? 🤔
4.11.1.3 bêta tested, and...... Much better 😊
I record à small activity in Locus, with one pause.
Good points :
Not so good points :
Fit import should also be able to manage pauses/breaks, and proper duration calculation. Next step 😁
4.11.1.3 bêta tested, and...... Much better 😊
I record à small activity in Locus, with one pause.
Good points :
Not so good points :
Fit import should also be able to manage pauses/breaks, and proper duration calculation. Next step 😁
Hello Mick,
thanks for the tests. Yes, import is currently untouched, so these new changes, mainly handling of breaks, is not done yet. I'll look at it ...
Anyway problem no. 1 > "total_timer_time" is weird. May you please double check it? Because all three times are set in the code for the "SessionMsg" and also for every "LapMsg" as I see.
Hello Mick,
thanks for the tests. Yes, import is currently untouched, so these new changes, mainly handling of breaks, is not done yet. I'll look at it ...
Anyway problem no. 1 > "total_timer_time" is weird. May you please double check it? Because all three times are set in the code for the "SessionMsg" and also for every "LapMsg" as I see.
If I could also dare a comment for when you will work on "pauses" Import from fit 😊.
As far as I understand, Locus is focus on points timestamps) with GPS coordinates. While fit files contains also potentially data with timestamp not mandatorily with such coordinate (recording devices may optimize recording in case of no movement).
Then pause (timer trigger) might happen in these cases, thus after (some) time after latest timestamps with location.
Maybe not easy, but could be lot more precise is Locus is able to keep timestamp of events, to keep perfect pause information (start, stop : = duration), meaning probably to create extra GPS points to support thus break / gap 😉.
If I could also dare a comment for when you will work on "pauses" Import from fit 😊.
As far as I understand, Locus is focus on points timestamps) with GPS coordinates. While fit files contains also potentially data with timestamp not mandatorily with such coordinate (recording devices may optimize recording in case of no movement).
Then pause (timer trigger) might happen in these cases, thus after (some) time after latest timestamps with location.
Maybe not easy, but could be lot more precise is Locus is able to keep timestamp of events, to keep perfect pause information (start, stop : = duration), meaning probably to create extra GPS points to support thus break / gap 😉.
4.11.1.5 beta installed, and looks promising 😊. Not too much time to test deeper, but I will.
Just a first bug : export button doesn't work. Need to share instead.
First thanks, next ones after further tests 👍👍
4.11.1.5 beta installed, and looks promising 😊. Not too much time to test deeper, but I will.
Just a first bug : export button doesn't work. Need to share instead.
First thanks, next ones after further tests 👍👍
Hi Menion,
After deeper investigation : i think it works exactely ................ as i thought :)
1- Fit export is working properly in terms of pauses management, duration calculations, etc.... : GREAT, and thanks again
2- Fit import is really good, but not perfect, and i will try to explain :
As i expected (not any criticizm ;) ), Locus is creating pause/gap/breaks, according to timer trigger from fit file, but often (always ? ), there is no GPS position at the exact timestamps of pause event. And, "nicely", locus is taking the nearest GPS point to create the pause/gap/break after import, thus in the locus track database. But it creates offsets in the real start/stop .
in the file attached, i compared original fit file, with the same activity, imported and re-exported.
on the left, i focused on pause events and just before and after GPS point of original fit
on the right, i focused on pause events only for locus exported fit
Result : orginal activity is 5:26:19 while Locus one is "only" 5:25:24 (couple of seconds, lost for each pause/break offset in time, due to non GPS data).
not sure how to manage it, if i were to code this (even if i have no coding skills :) ).
in terms of logic, according to what i understand from what i see of current behaviour : i would say :
Locus would detect orginal event pause timestamps (as of now), then, search just before or after GPS point location (as of now), but then, create a new GPS point, with same coordinate, but with pause timestamp.
Logic ? I think
Easy ? Not sure :)
by the way, a really great improvement :) thanks.
Hi Menion,
After deeper investigation : i think it works exactely ................ as i thought :)
1- Fit export is working properly in terms of pauses management, duration calculations, etc.... : GREAT, and thanks again
2- Fit import is really good, but not perfect, and i will try to explain :
As i expected (not any criticizm ;) ), Locus is creating pause/gap/breaks, according to timer trigger from fit file, but often (always ? ), there is no GPS position at the exact timestamps of pause event. And, "nicely", locus is taking the nearest GPS point to create the pause/gap/break after import, thus in the locus track database. But it creates offsets in the real start/stop .
in the file attached, i compared original fit file, with the same activity, imported and re-exported.
on the left, i focused on pause events and just before and after GPS point of original fit
on the right, i focused on pause events only for locus exported fit
Result : orginal activity is 5:26:19 while Locus one is "only" 5:25:24 (couple of seconds, lost for each pause/break offset in time, due to non GPS data).
not sure how to manage it, if i were to code this (even if i have no coding skills :) ).
in terms of logic, according to what i understand from what i see of current behaviour : i would say :
Locus would detect orginal event pause timestamps (as of now), then, search just before or after GPS point location (as of now), but then, create a new GPS point, with same coordinate, but with pause timestamp.
Logic ? I think
Easy ? Not sure :)
by the way, a really great improvement :) thanks.
Hello Mick,
hmm, thanks for the very precise test! I think, we are done here ...
Locus simply keep index of point, where break happend. And because there can't exists two points with identical coordinates, there is no simply solution for this. I think this is really minor issue and because Locus Map does not try to be an exact sports-manager and because FIT is not even a most used data format, excuse my lazyness in solving this issue. Thanks for understanding and once again for the patience with me!
Jiří M. aka Menion
Hello Mick,
hmm, thanks for the very precise test! I think, we are done here ...
Locus simply keep index of point, where break happend. And because there can't exists two points with identical coordinates, there is no simply solution for this. I think this is really minor issue and because Locus Map does not try to be an exact sports-manager and because FIT is not even a most used data format, excuse my lazyness in solving this issue. Thanks for understanding and once again for the patience with me!
Jiří M. aka Menion
Hi Menion,
I understand your "lazyness" :), even if i am little disapointed against all this work to be stopped just near almost perfection.
One other workaround i could imagine :) (and after i will stop :) )
Since Locus can now detect pause/breaks events in fit file during import,
Since i understand that locus is finding the nearest GPS points according to these breaks events and tag them as a break (keeping their original timestamps)
WHY NOT, during the routing of "tagging", changing these GPS points timestamps, by the break/pause event timestamp ? I think it would solve the issue ,no ? GPS coordinate will still be unique and breaks will be accurately represented.
In the below (and same example as before) :
initial time trigger is 1031213169, but first GPS point is 1031213172
Can Locus import this first point with 1031213169 time instead ?
For first real break : why not writing the GPS point originally at 101223341 with the real break time = 1031223351 ?
and so on.....
Hi Menion,
I understand your "lazyness" :), even if i am little disapointed against all this work to be stopped just near almost perfection.
One other workaround i could imagine :) (and after i will stop :) )
Since Locus can now detect pause/breaks events in fit file during import,
Since i understand that locus is finding the nearest GPS points according to these breaks events and tag them as a break (keeping their original timestamps)
WHY NOT, during the routing of "tagging", changing these GPS points timestamps, by the break/pause event timestamp ? I think it would solve the issue ,no ? GPS coordinate will still be unique and breaks will be accurately represented.
In the below (and same example as before) :
initial time trigger is 1031213169, but first GPS point is 1031213172
Can Locus import this first point with 1031213169 time instead ?
For first real break : why not writing the GPS point originally at 101223341 with the real break time = 1031223351 ?
and so on.....
Replies have been locked on this page!