GlideComp - How Track Data Cleaning Works

Why Tracklogs Need Cleaning

A flight recorder sometimes logs an altitude that no aircraft can fly. Three conditions cause this: a GPS receiver that finds the satellites again after shading, multipath reflections near terrain, and a short dropout. The fix is then hundreds of metres above or below the glider. It can also be exactly zero, which is how the format writes "no GPS altitude for this fix".

We surveyed the 3.7 million fixes in the real competition tracklogs that GlideComp is tested against. Transient GPS altitude glitches outnumber zero-dropouts by approximately 80 to 1. A glitch is a jump faster than any glider can fly, which returns to the true altitude in a few seconds. If it stays in the data, one glitch reads as a 400 m climb or dive that did not occur. It then distorts the climb rates, the glide ratios, the thermal detection and the altitude-band statistics.

A rule that reads every zero as "missing" is also not sufficient, because pilots do fly at sea level and below it. The cleaning must tell a measurement error from a real altitude, whatever the number is.

Yes, pilots really do fly at 0 m — and below

Flight at zero is usual, and every coastal ridge-soaring site has it each day. Pilots fly a few metres above the water at the Torrey Pines cliffs in San Diego, and at the Danish and Dutch dunes. They do the same at Wilderness in South Africa, and on Australia's soaring beaches. At Stanwell Park's Bald Hill, where Australian hang gliding started, the beach landing is at 0 m by definition.

Flight below zero is also real. The Dead Sea shoreline is at approximately −430 m, the lowest dry land on Earth. Paragliders fly the Judean Desert escarpment beside it, and the GPS reads negative for a whole descent. Death Valley's Badwater Basin (−86 m) is beside famous US hang-gliding country, and the Salton Sea basin in California (approximately −70 m) has soaring around its edges. Australia's own below-sea-level point is Kati Thanda–Lake Eyre (approximately −15 m), so an outback cross-country flight can correctly log a negative altitude.

GlideComp therefore never reads an altitude as wrong only because of its value. It repairs a fix only when the physics shows that the fix cannot be real. That happens in two cases: the barometer disagrees, or the climb rate is more than any glider can do.

The Two Altitude Channels

Every fix in an IGC tracklog carries two altitudes: the GPS (GNSS) altitude, and a barometric altitude from the pressure sensor of the instrument. The two channels measure the same flight through different physics, so they disagree by an offset that moves slowly. The day's air pressure, the temperature profile and the local geoid set that offset. It is usually a few tens of metres, and it is larger at height on a hot day.

One property is important: the offset changes slowly. In any one minute of flight it moves by less than ten metres. The barometric channel is therefore a reliable witness for the GPS channel, and the GPS channel is a reliable witness for the barometric channel.

The Cross-Check: Barometer as Witness

The recorder usually writes both channels. GlideComp then follows the GPS-minus-barometric difference through the flight, with a rolling two-minute median. If the difference of a fix moves away from that baseline by more than 150 m, GlideComp flags the fix as a GPS error. It repairs the altitude to the barometric reading plus the current baseline offset. That value is the best available estimate of the true position of the glider.

This test separates a glitch from real flying. In a real fast descent, such as a spiral dive, big ears or strong sink, both channels descend together. The difference stays flat, and GlideComp flags nothing. A slow glide to a beach landing at 0 m keeps both channels in agreement to the ground. GlideComp therefore keeps a real sea-level fix exactly as logged. Only a jump in one channel and not the other is an error. A zero-dropout is the extreme case of such a jump.

The Fallback: Physical Plausibility

Some instruments record only one altitude channel, for example a GPS-only tracker or a barometer-only logger. There is then no witness for a cross-check, so GlideComp uses physics instead. Hang gliders and paragliders do not hold a vertical speed of more than approximately 25 m/s, even in a spiral dive. GlideComp therefore reads an altitude step of more than 40 m/s between fixes as suspect.

GlideComp repairs a suspect step only when the track returns to near the altitude before the step, in 30 seconds or less. That out-and-back shape is what a glitch looks like. GlideComp then bridges the excursion with straight-line interpolation. If the track never returns, for example after a logger restart during the retrieve, GlideComp changes nothing, because a repair there invents data.

A slow descent through zero and back up is normal flying at a coastal site. It never starts this rule, because each individual step is small.

Error or Real Flying? Illustrated

These are the three situations that the cleaner must tell apart, side by side. The figures use synthetic data, and they carry that label because no track in GlideComp's archive can show the barometer cross-check. Scoring-server exports remove the barometric channel, as the real examples below show. Every line is still the output of the real cleaning engine over that data. The 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 figures come from real competition tracklogs in GlideComp's test archive. Each one is a segment 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.

The figures also show one honest detail. A scoring server that re-exports a tracklog often removes the barometric channel. The channel then reads 0 for the whole flight, as it does here. On such a file the cross-check cannot run, and the vertical-speed rule does the work instead. A track uploaded directly from an instrument carries 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

The cleaning changes altitude only. It never changes the positions, the times or the validity flags in the tracklog. GlideComp stores and shows the original file without a change, and that file keeps both raw altitude channels. The repairs go into a separate cleaned altitude series, which the analysis reads.

Positions and times drive GAP and open-distance scoring, so the cleaning almost never changes a score. It is important for everything that is built on altitude:

climb rates and thermal detection
glide ratios
take-off and landing detection
the goal-altitude bonus
the behavioural field analysis

Full Disclosure on the Report Card

The cleaning is never silent. If GlideComp repaired any fix in a track, that pilot's report card shows a Track data cleaning note. The note gives the number of repaired fixes, the time range of each incident, the size of the correction, and the test that flagged it. A track with no repairs shows nothing, and most tracks are clean.

This is the same transparency rule that the rest of GlideComp scoring obeys. Every number that reaches a leaderboard must be explainable, and everything the system did on the way to that number must be visible.