Parsing OpenTracks .kml exports

[pitastrudl]

Hi all,

I am working on a hobby project to visualize my hiked tracks and it includes parsing the track and it's data. Im using Python with Beautiful soup and I have a few questions regarding the format.

1. I did notice it has changed due to the empty coords tag implementation this year (2021). I've noticed this due to having some tracks from 202 and due to the indoor requests this means that the start and end will always have an empty "gx:coord/", ref: KML with empty gx:coords. #639.
   I've dealt with this by removing the first and last elements(speed,elevation,timestamp,coord) since the starting timestamp and ending do not pose much of a accuracy risk. Not a question, more of an observation

2. I am wondering why inside a </gx:MultiTrack> there are multiple gx:Track? This is a single recorded track without manual pauses inside the application. It messed up my naive parsing a bit, which i am still trying to optimize. If i understand correctly, if you lets says, stop for lunch, it will be broken into multiple tracks inside a multitrack in the .kml file?

3. Related to the above questions, how can I be sure that the paired data (elevation gain, speed, timestamp and coords) is paired correctly when I parse the data? Right now I just assume ALL of the tags are in chronological order when I parse them out and put them into an array to be used further.

4. Are the Track tags always in chronological order inside a MultiTrack?

Thank you for this wonderful application, using it quite regularly!

[dennisguse]

1. yes and we will also built indoor-only capability (i.e., GPS off or disabled as a sensor is used for distance), then there will be even more <gx:coord />.
2. Those are segments of a track (aka distance to previous trackpoint is too large); mainly affects statistics
3. exactly - count will of gx:coords matches data fields
4. yes.

Thanks!

PS: You may use GPX; then you don't have any of these problems as

1. it does not support TrackPoints without locations (those are not exported then) / not supported by the standard
2. the data is included into the same structure

[pitastrudl]

Thanks for the fast reply! I'd like to keep the settings in the app to export everything (KMZ with photos) but I could convert the .kml to .gpx in my project to eliminate this. Thanks for the tip!

Another observation regarding the same number of elements in the overall track. I've been trying to import ALL of my tracks, I think I have around 300 tracks and 200 are not importing due to missing elevation_gain and/or speed. I've been comparing the data and for most if not all tracks before July 2020 have different numbers:
number of occurence for elevation_gain is of course 0 but speed differs from coord/timestamp number of values.

Below are my analysis. The space delimited numbers are "speed, elevation_gain, coord, timestamp". The coord and timestamp are always the same but the speed seems to differ, sometimes by just a few tags. Maybe related to #192 but there are many tracks from 2019 that have similar "issues" with my import on my app.
I know the format changed over the years and the issues are a great way to discover the changes but aany insight on this would be great! Thank you.

EDIT: I am aware that exporting elevation_gain was added in late 2020 i think, so it makes sense that it is missing from my exports but i am still confused about the mismatching speed values.

not good: 0 0 991 991   2020-04-26T15:50:06.999Z
not good: 0 0 1826 1826   2020-04-30T15:29:10Z
not good: 0 0 1266 1266   2020-05-10T15:25:23Z
not good: 0 0 2661 2661   2020-05-12T15:11:32Z
not good: 1994 5948 1994 1994   2020-11-29T12:50:24.727Z
not good: 0 0 12 12   2020-07-27T22:16:40.301Z
not good: 0 0 1538 1538   2020-07-27T22:17:49.782Z
not good: 0 0 487 487   2020-07-27T22:16:38.434Z
not good: 4983 0 4988 4988   2020-05-30T09:48:10.999Z
not good: 0 0 22 22   2020-07-27T22:16:39.835Z
not good: 2724 0 2731 2731   2020-06-03T15:05:44.999Z
not good: 4484 0 4491 4491   2020-06-06T09:04:10Z
not good: 1782 0 1783 1783   2020-06-13T13:11:35.921Z
not good: 3262 0 3263 3263   2020-06-14T06:57:50.732Z
not good: 191 0 192 192   2020-06-25T09:44:01Z
not good: 2409 0 2417 2417   2020-06-26T09:38:17.999Z

[dennisguse]

@pitastrudl yes, there might have been a bug there - you would need to dig through the changes in the KML exporter to figure that one out.

It might be due to changes for this issue: #316

but not sure...