GPX Editing - Part 2

2025-12-12 · 8 min read
linux gps

Correcting GPX Errors SAR Flight

On a recent practice run for air search-and-rescue, I recorded the flight gps and altitude data using my phone and Comaps "record a track".

I noticed pretty quickly that there was a serious error in the data at about two thirds through recording the track:

SAR Flight

The track above looks really weird; huge climbs and drops of nearly 700m (~2100ft) in what looks like a very short time are suspect, but the straight line in the graph suggests strongly that there is missing data in the timeline. Using a track "scrubber", we can see that there are indeed problems in that data where some gps points weren't logged.

By the way, if you need a GPX explorer and editor, GPX Studio is pretty amazing.

This gave me the opportunity to examine the GPX data to see if I can determine what transpired. Let's find some empirical values on this section:

Elevation Errors

Above are a few reference points to pick from the data: 1038m and 369m are of particular interest here. If they are unique values in the whole set, we'll know we have points from within the aberrant area. And sure enough, both 1038m and 369m are unique elevation values for the whole set of trk (track) data for the recorded time in flight:

      <ele>1038</ele>
      <time>2025-12-13T18:27:26Z</time>
    </trkpt>
    <trkpt lat="49.06068" lon="-116.52859">
      <ele>1046</ele>
      <time>2025-12-13T18:27:32Z</time>
    </trkpt>
    <trkpt lat="49.062535" lon="-116.52903">
      <ele>1056</ele>
      <time>2025-12-13T18:27:35Z</time>
    </trkpt>
    <trkpt lat="49.064271" lon="-116.52945">
      <ele>1053</ele>
      <time>2025-12-13T18:27:38Z</time>
    </trkpt>
    <trkpt lat="49.067798" lon="-116.53002">
      <ele>1078</ele>
      <time>2025-12-13T18:27:44Z</time>
    </trkpt>
    <trkpt lat="49.068969" lon="-116.53016">
      <ele>1074</ele>
      <time>2025-12-13T18:27:46Z</time>
    </trkpt>
    <trkpt lat="49.089443" lon="-116.53209">
      <ele>839</ele>
      <time>2025-12-13T18:28:20Z</time>
    </trkpt>
    <trkpt lat="49.094228" lon="-116.5326">
      <ele>800</ele>
      <time>2025-12-13T18:28:28Z</time>
    </trkpt>
    <trkpt lat="49.115875" lon="-116.55201">
      <ele>369</ele>
      <time>2025-12-13T18:30:28Z</time>
    </trkpt>

Now we have some data.

And we only have three data types: elevation, lat/long, and time in Zulu (UTC).

There seems to be a big gap in data between 18:27:46Z and 18:28:20Z, a difference of 24 seconds, where the average increment in the normal data is somewhere between 3 and 6 seconds. Another gap of 120s is apparent just before the 369m elevation trackpoint.

We're left we a few choices here to deal with the missing data:

  1. Try to interpolate the values between the problem areas. This requires some math, which will likely end up being a stats formula to average reasonable fake data points between the start and stop of the aberrant points. This won't add any meaningful information, so I'm not keen on this solution.
  2. Use tags to segment the parts of the track before and after the aberrant points. This will look like two legs of a journey, but will give a better idea of the real and accurate data, signalling that what is between segments is simply unknown. I'd like to keep this as a last resort.
  3. Get a better copy of the data. This time, I have the luxury of access to potentially (read: likely) better data, so I'm requesting this.

I don't think I'm adding any meaningful information by fabricating interpolated data with a mathematical function, and although less confusing, adjusting the track to show gaps doesn't necessarily add much either, so option #3 seems best.

*
Jules