Pause/resume refactoring regarding GPX

[dennisguse]

While checking the pause/resume refactoring, I found the implemented functionality is not supported by GPX (i.e., the generated GPX is not in complaince with version 1.1.).

Context

We now store trackpoints that do not have a actual location (i.e., where generated by the user and only contain a timestamp).
And the plan was to export those, so we can actually backup/restore the trackstatistics.

Issue

While KML supports empty gx:coords (i..e, https://developers.google.com/kml/documentation/kmlreference#gxcoord ), this is not supported by GPX as here the lat and lon attributes must be present (and valid numbers).
In GPX a track (trk) contains track segments (trkseq) which contain trkpt that are of type wptType and wptType defines that lat&lon must be present.

Options

1. We can ignore the standard and just keep everything as it is.
   (users might have trouble importing into other software)
2. We do not export those trackpoints for GPX.
   (track cannot be restored exactly from GPX)
3. We do some other magic.

@pstorch @rgmf Any suggestions on what to do?

[pstorch]

What about repeat the coords of the last track point for a pause track point and vice versa use the coords of the next track point for resume track points?

[dennisguse]

While importing (I chose), the absence of lat/lon creates a MANUAL_START trackpoint while it's presence creates a AUTOMATIC_START.
(only applies for the first trackpoint in a segment);
We could also change this for GPX and encode this information differently.

[rgmf]

In GPX seems logical to use trkseg to mark PAUSE and RESUME but in that case we cannot to distinguish between MANUAL and AUTOMATIC START. Is the difference between AUTOMATIC and MANUAL very important???

<trk>
    <trkseg>
        <trkpt lat="..." lon="...">
            ...
        </trkpt>
        ....
    </trkseg>  <!-- PAUSE -->
    <trkseg>   <!-- RESUME: AUTOMATIC OR MANUAL START? -->
        <trkpt lat="..." lon="...">
            ...
        </trkpt>
        ....
    </trkseg>
</trk>

I like the best trying to encode the information differently for GPX files but I've not looked into the impact of this change.

[dennisguse]

For the statistics, we need this differentiation to compute the overall / moving time as well as avg speed (I guess).
If a segment starts with AUTOMATIC_START, the duration between the previous trackpoint and the current one is added to the overall time/moving time.
While for MANUAL_START, the overall time/moving time is not increased; i.e., we assume the user paused and continued some time later.

@rgmf nice summary!

[pstorch]

A GPX trkpt can have a type child element, can we use that? Or a OpenTracks extension to the trkpt type?

[dennisguse]

@pstorch That's a really cool idea!
We already export elevation gain/loss as a trackpoint extension, so we can do the same for the type of the first trackpoint in a segment!

[dennisguse]

i did some conceptual thinking about indoor training (i.e., without GPS signal): #500 (comment)
... and then we get in total trouble with GPX as there are no GPS coordinates at all...
So, I would propose to reduce the functionality of GPX and not export any trackpoints that have no location (for now) until we get a real solution.
Otherwise, the next release will delayed for some time...

[rgmf]

i did some conceptual thinking about indoor training (i.e., without GPS signal): #500 (comment)
... and then we get in total trouble with GPX as there are no GPS coordinates at all...
So, I would propose to reduce the functionality of GPX and not export any trackpoints that have no location (for now) until we get a real solution.
Otherwise, the next release will delayed for some time...

Seem a transitional good solution... 👍

[dennisguse]

Workaround is implemented (basically reverting adaptation for MANUAL_START and MANUAL_END; see #591).
Thus GPX should behave as pre #553.

Follow-up work is tracked in #597.

@rgmf @pstorch Thanks for the discussion! 😎