How Track Data Cleaning Works
Repairing GPS altitude glitches before analysis — and telling you exactly what was touched
Why Tracklogs Need Cleaning
Flight recorders occasionally log altitudes that no aircraft could fly. A GPS receiver re-acquiring satellites after shading, multipath reflections near terrain, or a momentary dropout can produce a fix hundreds of metres above or below the glider — or an altitude of exactly zero, the format's way of writing "no GPS altitude for this fix".
Surveying the real competition tracklogs GlideComp is tested against (3.7 million fixes), transient GPS altitude glitches — a jump faster than any glider can fly, returning to the true altitude within a few seconds — outnumber zero-dropouts roughly 80 to 1. Left in the data, a single glitch reads as a 400 m climb or dive that never happened, which would distort climb rates, glide ratios, thermal detection and altitude-band statistics.
Simply treating zero as "missing" is not good enough either: pilots genuinely fly at — and below — sea level. Cleaning has to distinguish 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 through different physics, so they disagree by a slowly-drifting offset — the day's air pressure, the temperature profile, the local geoid — typically a few tens of metres, and larger at height on hot days.
The key property: that offset changes slowly. Over any one minute of flight it moves by single-digit metres. That makes the barometric channel a reliable witness for the GPS channel — and vice versa.
The Cross-Check: Barometer as Witness
When both channels are recorded (the normal case), GlideComp tracks the GPS-minus-barometric difference through the flight using a rolling two-minute median. A fix whose difference suddenly departs that baseline by more than 150 m is flagged as a GPS error, and its altitude is repaired to the barometric reading plus the current baseline offset — the best available estimate of where the glider actually was.
This test is what separates a glitch from real flying. In a genuine rapid descent — a spiral dive, big ears, strong sink — both channels descend together, the difference stays flat, and nothing is flagged. A slow glide to a beach landing at 0 m keeps both channels in agreement all the way down, so a genuine sea level fix is left exactly as logged. Only a jump that appears in one channel and not the other is treated as an error — and a zero-dropout is just the extreme case of that.
The Fallback: Physical Plausibility
Some instruments record only one altitude channel (a GPS-only tracker, or a barometer-only logger). With no witness to cross-check against, GlideComp falls back to physics: hang gliders and paragliders do not sustain vertical speeds beyond about 25 m/s even in a spiral dive, so an altitude step steeper than 40 m/s between fixes is treated as suspect.
A suspect step is only repaired when the track returns to near the pre-step altitude within 30 seconds — the out-and-back shape of a glitch. The excursion is then bridged by straight-line interpolation. A step that never comes back (a logger restart during retrieve, say) is left untouched: repairing it would be inventing data.
A slow descent through zero and back up — normal flying at a coastal site — never triggers this rule, because every individual step is gentle.
Error or Real Flying? Illustrated
The three situations the cleaner must tell apart, side by side. These figures use synthetic data — labelled as such because no track in GlideComp's archive can show the barometer cross-check (scoring-server exports strip the barometric channel; see the real examples below) — but every line is the actual cleaning engine's output over that data, and the generator fails if the engine ever 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 figures are drawn from genuine competition tracklogs in GlideComp's test archive — segments where the cleaning pass found something to repair. The green shaded band marks the repaired fixes; everywhere else the cleaned line sits exactly on the raw GPS line.
One honest detail they also illustrate: tracklogs re-exported by scoring servers often have the barometric channel stripped — it reads 0 for the whole flight, as here — so on these files the cross-check cannot run and the vertical-speed rule does the work. Tracks uploaded straight from an instrument carry both channels and get 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 touches altitude only. Positions, times, and the validity flags in the tracklog are never altered, and the original file — including both raw altitude channels — is stored and displayed unchanged. Repairs live in a separate cleaned altitude series that the analysis reads.
Because GAP and open-distance scoring are driven by positions and times, cleaning almost never changes a score. It matters for everything built on altitude: climb rates and thermal detection, glide ratios, takeoff and landing detection, the goal-altitude bonus, and the behavioural field analysis.
Full Disclosure on the Score Page
Cleaning is never silent. Whenever any fix in a track was repaired, that pilot's score details page shows a Track data cleaning note: how many fixes were repaired, the time range of each incident, how large the correction was, and which test flagged it. A track with nothing repaired shows nothing — most tracks are clean.
This is the same transparency rule the rest of GlideComp scoring follows: every number that reaches a leaderboard must be explainable, and anything the system did on the way there must be visible.