trk file segment counts
Posted: Mon Jan 02, 2023 6:06 pm
For ~~reasons~~ I decided to write my own `trk` parser in R. (Basically I was getting weird encoding errors in the Python parser and I'm much more comfortable debugging in RStudio.) Here's the repo: https://github.com/dhicks/alpineR
Also FWIW this is my first time messing around with raw hex data, so please let me know if I'm using the terminology wrong or missing something basic.
I have two track files I'm using to test the parser, the 2021 track (`test_data/track_20210417_094737.trk`) and the 2022 track (`test_data/track_20221223_103047.trk`). In both cases, it seems like I have to double the number of segments reported at the start of the TrackSegments section, because each "real" segment (containing data: -1 metadata entries followed by n locations) seems to be preceded by an "empty" segment (8 bytes of 0, apparently indicating 0 metadata entries and 0 locations if interpreted as a TrackSegment). For example, the 2021 track reports 1 segment, but there are actually 2: one empty, one with the location data. The 2022 track reports 2 segments (which matches what I see in the app), but there are actually 4: empty, before lunch, empty, after lunch.
To make this more concrete, here's a Google Sheet showing how I/my parser are interpreting the first 24 bytes of the TrackSegments section of the 2021 file, starting from offset 259: https://docs.google.com/spreadsheets/d/ ... sp=sharing
Is this the right way to think about how to parse TrackSegments?
Also FWIW this is my first time messing around with raw hex data, so please let me know if I'm using the terminology wrong or missing something basic.
I have two track files I'm using to test the parser, the 2021 track (`test_data/track_20210417_094737.trk`) and the 2022 track (`test_data/track_20221223_103047.trk`). In both cases, it seems like I have to double the number of segments reported at the start of the TrackSegments section, because each "real" segment (containing data: -1 metadata entries followed by n locations) seems to be preceded by an "empty" segment (8 bytes of 0, apparently indicating 0 metadata entries and 0 locations if interpreted as a TrackSegment). For example, the 2021 track reports 1 segment, but there are actually 2: one empty, one with the location data. The 2022 track reports 2 segments (which matches what I see in the app), but there are actually 4: empty, before lunch, empty, after lunch.
To make this more concrete, here's a Google Sheet showing how I/my parser are interpreting the first 24 bytes of the TrackSegments section of the 2021 file, starting from offset 259: https://docs.google.com/spreadsheets/d/ ... sp=sharing
Is this the right way to think about how to parse TrackSegments?