How Track Data Cleaning Works
Repairing GPS altitude glitches before analysis — and telling you exactly what was touched
Why Tracklogs Need Cleaning
Flight recorders sometimes log an altitude no aircraft could fly. It happens when a GPS receiver reacquires satellites after being shaded, when its signal reflects off nearby terrain, or during a brief dropout. The fix lands hundreds of metres above or below the glider, or at exactly zero, which is how the IGC format says "no GPS altitude for this fix".
Across the 3.7 million fixes in the real competition tracklogs GlideComp is tested against, brief GPS altitude glitches outnumber zero-dropouts by about 80 to 1. A glitch jumps faster than any glider can climb or sink, then returns to the true altitude within a few seconds. Left in, a single glitch reads as a 400 m climb or dive that never happened, and it skews climb rates, glide ratios, thermal detection and altitude-band statistics.
Treating every zero as "missing" doesn't work either, because pilots do fly at sea level and below it. The cleaning has to tell a measurement error from a real altitude, whatever the number.
The Two Altitude Channels
Every fix in an IGC tracklog carries two altitudes: the GPS (GNSS) altitude, and a barometric altitude from the instrument's pressure sensor. They measure the same flight by different physics, so they differ by an offset set by the day's air pressure, the temperature profile and the local geoid. That offset is usually a few tens of metres, more at height on a hot day.
What matters is that the offset changes slowly: by less than ten metres in any minute of flight. That makes each channel a reliable witness for the other.
The Cross-Check: Barometer as Witness
When the recorder writes both channels, GlideComp tracks the GPS-minus-barometric difference through the flight as a rolling two-minute median. A fix whose difference strays more than 150 m from that baseline is flagged as a GPS error. Its altitude is repaired to the barometric reading plus the current offset, which is the best available estimate of where the glider really was.
This is what separates a glitch from real flying. In a genuine fast descent, such as a spiral dive, big ears or strong sink, both channels drop together, the difference stays flat, and nothing is flagged. On a slow glide to a beach landing at 0 m, both channels agree all the way down, so a real sea-level fix is kept exactly as logged. Only a jump in one channel but not the other is an error, and a zero-dropout is the extreme case of that.
The Fallback: Physical Plausibility
Some instruments record only one altitude channel, such as a GPS-only tracker or a barometer-only logger. With no second channel to cross-check against, GlideComp falls back on physics. Hang gliders and paragliders can't sustain more than about 25 m/s vertically, even in a spiral dive, so a step of more than 40 m/s between fixes is suspect.
A suspect step is repaired only if the track returns to near its earlier altitude within 30 seconds. That out-and-back shape is the signature of a glitch, and GlideComp bridges it with a straight line. If the track never comes back, as after a logger restart during the retrieve, nothing is changed, because a repair there would invent data.
A slow descent through zero and back up, which is normal at a coastal site, never trips this rule, because no single step is large.
Error or Real Flying? Illustrated
Here are the three situations the cleaner has to tell apart, side by side. They use synthetic data, and are labelled as such, because no track in GlideComp's archive can show the barometer cross-check: scoring servers strip the barometric channel on export, as the real examples below show. Every line is still the output of the real cleaning engine, and the chart generator fails if the engine stops behaving as the captions describe.
A GPS spike the barometer refuses to confirm
A genuine spiral dive — repaired: nothing
A beach landing at 0 m — repaired: nothing
Real Examples
These come from real competition tracklogs in GlideComp's test archive, each a stretch where the cleaning found something to repair. The green band marks the repaired fixes. Everywhere else, the cleaned line sits exactly on the raw GPS line.
They also show a limitation. A scoring server that re-exports a tracklog often strips the barometric channel, which then reads 0 for the whole flight, as it does here. On such a file the cross-check can't run, so the vertical-speed rule does the work. A track uploaded straight from the instrument keeps both channels and gets the stronger barometer cross-check.
A GPS spike, 9.5 km below the flight
A dropout to zero
What Gets Repaired — and What Never Changes
Cleaning changes altitude only. It never touches positions, times or the tracklog's validity flags. The original file is stored and shown unchanged, with both raw altitude channels. Repairs go into a separate cleaned altitude series, which is what the analysis reads.
GAP and open-distance scoring run on positions and times, so cleaning almost never changes a score. It matters for everything built on altitude:
- climb rates and thermal detection
- glide ratios
- take-off and landing detection
- the goal-altitude bonus
- the behavioural comp and task analysis
Full Disclosure on the Report Card
Cleaning is never silent. If any fix in a track was repaired, that pilot's report card shows a Track data cleaning note: how many fixes were repaired, when each incident happened, how big the correction was, and which test flagged it. Most tracks are clean, and a track with no repairs shows nothing.
It's the same transparency rule the rest of GlideComp's scoring follows: every number on a leaderboard must be explainable, and everything done on the way to it must be visible.