Skip to main content
Scoring

GlideComp logo 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

Illustration (synthetic data, real cleaning engine): mid-climb, the GPS channel jumps ~340 m for four fixes while the barometer keeps reading a smooth climb. The GPS-minus-barometer difference leaps out of its rolling baseline, so the fixes are repaired to the barometric altitude plus the current offset — landing back on the true line. 4 fixes repaired, largest correction 340 m.

A genuine spiral dive — repaired: nothing

Illustration (synthetic data, real cleaning engine): a spiral dive sheds 720 m in 40 seconds — dramatic, but real, and the barometer plunges in step with the GPS. The difference between the channels never moves, so nothing is flagged and nothing is repaired. The cleaned line is simply the raw GPS line.

A beach landing at 0 m — repaired: nothing

Illustration (synthetic data, real cleaning engine): a slow coastal glide-out to a beach landing at essentially 0 m. Every step is gentle and the barometer agrees throughout, so the sea-level altitudes are kept exactly as logged — an altitude is never treated as wrong because of its value, only because the physics says it cannot be real.

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

Bright Open 2026, task 1: mid-glide, the logger wrote a fix nearly 9,600 m BELOW the flight — eight kilometres under the valley floor, a vertical speed no aircraft could fly — and returned to the true altitude one second later. 1 fix around 11:52:00 AEDT repaired; the largest was 9,579 m from the true ~1,581 m. The barometric channel reads 0 for the whole flight — this scoring-server export carries no barometer, so the vertical-speed rule made the call.

A dropout to zero

Forbes Flatlands 2025, task 1: for one fix the GPS altitude collapsed to 0 m — the format’s “no altitude” value — while the pilot was cruising near 2,500 m, then recovered immediately. 1 fix around 14:45:03 AEDT repaired; the largest was 2,476 m from the true ~2,476 m. The barometric channel reads 0 for the whole flight — this scoring-server export carries no barometer, so the vertical-speed rule made the call.

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.