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

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

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 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.