Affected issues: #375, #316, #275, #192, #301 (remotely).
Problem
We cannot restore/recompute the TrackStatistics (mainly on import but also if we would remove TrackPoints from a track; see #375)
Fun fact: With regard to time, TrackStatistics are computed live while recording.
Current situation
All our data EXPORT/IMPORT is based upon TrackPoints (either GPS-based or PAUSE/RESUME markers).
The later are also segment separator (either manually or automatically due to distance between two GPS-based TrackPoints).
A timestamp of a TrackPoint either use GPS time or device system time.
These timestamps cannot be compared to each other directly - worst case scenario: GPS week rollover.
The differences might also be smaller, but we cannot assume that the offset is constant.
Also the GPS hardware might apply some internal processing...
One brief example:
-> start recording
---> Segment 1
* TrackPoint/GPS: GPS_time=1;x=1/y=2
* TrackPoint/GPS: GPS_time=2;x=2/y=2
-> automatically create segment marker
* TrackPoint/PAUSE: DEVICE_time=3;x=100/y=0 --> contains special coordinates
---> Segment 2
* TrackPoint/GPS: GPS_time=4;x=4/y=2
* TrackPoint/GPS: GPS_time=5;x=5/y=2
-> pause recording
* TrackPoint/PAUSE: DEVICE_time=6;x=100/y=0 --> contains special coordinates
-> recording resumed
--> Segment 3
* TrackPoint/RESUME: DEVICE_time=7;x=200/y=0 --> contains special coordinates
...
On export, we just write the GPS-based TrackPoints; all device-based TrackPoints _are not_exported.
The device-based TrackPoints are used to create GPX/KML-segments (without exporting the DEVICE_time).
On import, we recreate device-based TrackPoints using the segments, but we _cannot restore the DEVICE_time (we actually use the current DEVICE_time on import).
And thus, we recomputing the TrackStatistics leads to incorrect results - basically everything that is affected by wrong segment duration (i.e., moving time, avg speed etc, overall track duration).
In fact, this also affects the starttime and the stoptime of a Track (also DEVICE_time).
Interesting: RESUME-TrackPoints are only written to DB, but actually never evaluated (basically just ignored on export).
Idea: somehow we need to export/import TrackPoints that are based upon DEVICE_time.
Export segment markers to denote segment start/end timestamps in exported files
One simple solution is to export device-based TrackPoints to export the timestamps of the segments correctly.
As device-based TrackPoints do not provide useful GPS coordinates, the GPS-coordinate of the previous/next TrackPoint could be used (depending if either segment start/segment end).
This can be done on export and reversed on import (if the first two coordinates are identical)
GPS-time vs. device-time
To ensure that the time in exported files is monotonically increasing, we can use either:
- DEVICE_time (can be added to every TrackPoint on creation), or
- GPS_time.
2nd option: To be able to convert DEVICE_time to GPS_time, we would need to store device-time and GPS-time per TrackPoint -
At least for the GPS_time TrackPoints before/after a DEVICE_time TrackPoint.
@pstorch @rgmf
Did I miss something?
And what is your gut feeling?
I am the moment leaning towards the 2nd option as we do not modify the GPS_time if somebody needs it (for whatever use case).
Whatever, we do - it will be a really challenging operation 🥳
Affected issues: #375, #316, #275, #192, #301 (remotely).
Problem
We cannot restore/recompute the TrackStatistics (mainly on import but also if we would remove TrackPoints from a track; see #375)
Fun fact: With regard to time, TrackStatistics are computed live while recording.
Current situation
All our data EXPORT/IMPORT is based upon TrackPoints (either GPS-based or PAUSE/RESUME markers).
The later are also segment separator (either manually or automatically due to distance between two GPS-based TrackPoints).
A timestamp of a TrackPoint either use GPS time or device system time.
These timestamps cannot be compared to each other directly - worst case scenario: GPS week rollover.
The differences might also be smaller, but we cannot assume that the offset is constant.
Also the GPS hardware might apply some internal processing...
One brief example:
On export, we just write the GPS-based TrackPoints; all device-based TrackPoints _are not_exported.
The device-based TrackPoints are used to create GPX/KML-segments (without exporting the DEVICE_time).
On import, we recreate device-based TrackPoints using the segments, but we _cannot restore the DEVICE_time (we actually use the current DEVICE_time on import).
And thus, we recomputing the TrackStatistics leads to incorrect results - basically everything that is affected by wrong segment duration (i.e., moving time, avg speed etc, overall track duration).
In fact, this also affects the starttime and the stoptime of a Track (also DEVICE_time).
Interesting: RESUME-TrackPoints are only written to DB, but actually never evaluated (basically just ignored on export).
Idea: somehow we need to export/import TrackPoints that are based upon DEVICE_time.
Export segment markers to denote segment start/end timestamps in exported files
One simple solution is to export device-based TrackPoints to export the timestamps of the segments correctly.
As device-based TrackPoints do not provide useful GPS coordinates, the GPS-coordinate of the previous/next TrackPoint could be used (depending if either segment start/segment end).
This can be done on export and reversed on import (if the first two coordinates are identical)
GPS-time vs. device-time
To ensure that the time in exported files is monotonically increasing, we can use either:
2nd option: To be able to convert DEVICE_time to GPS_time, we would need to store device-time and GPS-time per TrackPoint -
At least for the GPS_time TrackPoints before/after a DEVICE_time TrackPoint.
@pstorch @rgmf
Did I miss something?
And what is your gut feeling?
I am the moment leaning towards the 2nd option as we do not modify the GPS_time if somebody needs it (for whatever use case).
Whatever, we do - it will be a really challenging operation 🥳