Why Can't Strava, Garmin or Race Directors Get Elevation Right?

Ever wondered why you can load the same course into Garmin, Strava and a race website and end up with three different elevation numbers.

Then you run it and your watch gives you a fourth.

It is very easy to look at that and assume somebody has got the elevation wrong.

The problem is that elevation gain is not sitting inside a GPX file waiting to be read like the distance on a road sign. It has to be calculated from a series of position and height observations, and there are several perfectly reasonable ways of doing that.

The interesting part is that Garmin and Strava have access to vastly more activity data, mapping information and engineering resources than most of us ever will, and even they do not use the same method.

That was one of the reasons I ended up researching this properly for Track3D.

What a GPX actually gives you

A GPX track is basically a sequence of recorded points.

Each point can include latitude, longitude and elevation. One point might say 842 metres, the next 844, then 843, then 846.

What the file does not give you is an agreed definition of how all of those changes should become one final number called total elevation gain.

The obvious calculation is to add every positive change.

That gives five metres of climbing.

But were those small changes really terrain?

Maybe they were. Maybe the trail actually rolled up and down by a metre or two. They could also be sensor noise, GPS altitude error, interpolation, rounding or the way the original track was sampled.

If you have thousands of points, adding every tiny upward movement can turn very small errors into a surprisingly large amount of climbing.

Why simply adding every climb goes wrong

This is the problem we originally had in Race Planner.

The raw GPX calculation was consistently producing totals that were higher than published race elevation on enough courses that it was clearly worth investigating.

My first instinct seemed pretty obvious, remove the little noisy movements.

Unfortunately the algorithm has no way of looking at a two metre rise and knowing whether it was noise or a real two metre rise.

That becomes especially important on long trail races where there can be hundreds of genuine little climbs that never appear as one big obvious hill.

The same problem exists in the other direction.

If the original file was sampled too sparsely, a hilltop can sit between two recorded points and never appear in the file at all. Once that information was never recorded, no amount of smoothing can put it back.

Why smoothing does not magically fix it

Smoothing definitely helps with noisy elevation, the problem is deciding how much.

Too little smoothing and you keep counting noise.

Too much smoothing and you start flattening real climbs.

A useful paper from 2010 looked at exactly this problem on a 42 kilometre route. The researchers changed the amount of averaging applied to the same elevation data and produced cumulative ascent estimates ranging from about 680 metres to 1,410 metres.

Some of those values were obviously unrealistic, but even after removing the extremes there was still no magic smoothing level where one unquestionably correct answer appeared.

The paper compared it with measuring a coastline, the smaller the ruler, the more little detail you measure.

That analogy is surprisingly close to what happens with elevation gain.

If you count every little rise, the total grows. If you use a larger ruler, some of those rises disappear, including some that were actually real.

What Strava does

Strava does not simply trust every elevation value inside every uploaded file.

For activities recorded by a recognised device with a barometric altimeter, Strava says it generally uses the barometric elevation in the original file, although it still applies smoothing and removes outliers.

When there is no recognised barometric source, Strava takes the GPS positions and looks up elevation using its own elevation basemap.

That basemap is particularly interesting because Strava built it using barometric elevation collected from its own community, rather than relying only on a traditional public terrain model.

Strava then applies its own processing rules. Its current documentation says climbing must continue consistently for more than 10 metres on activities without strong barometric data before it contributes to total gain, compared with more than 2 metres when strong barometric data is available.

Strava also openly says that its elevation can differ from the device, from another runner on the same route and from other platforms because GPS data, basemap quality, smoothing and calculation methods all vary.

That is not a hidden edge case, it is part of how the system works.

What Garmin does

Garmin makes a different set of choices.

For an activity recorded on a Garmin device with a barometric altimeter, Garmin Connect normally uses the elevation recorded by the device.

For devices without a barometric altimeter, Garmin says Garmin Connect uses its hosted Digital Elevation Model, or DEM, to estimate elevation from the recorded GPS positions.

Garmin also does something particularly relevant to race planning.

If you turn a recorded activity or GPX into a Garmin Course, Garmin says the original activity elevation is discarded and the course elevation is rebuilt using Garmin's DEM based map data.

So the GPX you downloaded from a race organiser can already have elevation values in it, Garmin can choose not to use those values for the Course, and Strava can process the same route against a different elevation database using a different algorithm.

Garmin's own support material explicitly says Garmin Connect and third party platforms can report different elevation when they use different datasets and methodologies.

So even Garmin's answer to “why does Strava disagree with Garmin?” is basically because they are not measuring it the same way.

It is not just Garmin and Strava

TrainingPeaks has an elevation correction tool as well.

Its current documentation says the correction takes the recorded GPS positions, looks up elevation from an elevation database and lets the athlete compare the corrected result before applying it.

TrainingPeaks also recommends keeping the original barometric data from a modern device unless there is an obvious problem.

The important part is the same, “corrected elevation” usually means another system has replaced or processed the original elevation using a different source and a different set of assumptions.

Corrected does not mean surveyed.

Why race directors can still disagree

The number published on a race website has to come from somewhere as well.

It may come from a GPS recording, mapping software, a route planning service, the event timing platform, a terrain model or a standardised course evaluation process.

ITRA is a good example of why the processing method matters.

ITRA says it has analysed more than 100,000 GPX files with Trace de Trail and developed a standardised evaluation system. Its published guidance includes smoothing the altitude curve and ignoring small elevation differences below a threshold during the calculation.

It also specifically notes that race organisers and runners often overestimate elevation when raw data is not properly processed.

So when a race director publishes 4,500 metres and your GPX adds up to 4,900, it does not automatically mean the organiser made a mistake.

They may simply be publishing the output of a different processing method.

Why barometric elevation still varies

Barometric altimeters are generally better for recording changes in elevation because they are not relying entirely on noisy GPS altitude.

But a barometer is not directly measuring the mountain.

It is measuring atmospheric pressure and using the change in pressure to estimate altitude.

That creates another set of problems because pressure changes for reasons that have nothing to do with whether you are climbing.

• Weather changes. A pressure system moving through can make the watch interpret changing pressure as changing altitude.
• Temperature changes. Garmin notes that ambient temperature can affect barometric altitude accuracy.
• Calibration. Two devices can begin the same race from slightly different calibrated elevations.
• Water, sweat and dirt. A partially blocked sensor port can distort pressure readings.
• Wind and clothing. Airflow or covering the sensor can affect some devices.
• Automatic correction. Modern watches may periodically use GPS or DEM information to correct barometric drift, which introduces another data source into the calculation.

Garmin even has support documentation explaining why total ascent and total descent can differ on a simple out and back route that should theoretically contain the same climbing and descending.

In the real world the pressure sensor and the environment are changing while you move.

That is also why two runners beside each other for an entire race can finish with different barometric elevation totals.

Why terrain models are not automatically truth

If GPS elevation is noisy and barometers drift, it is tempting to say forget both of them and just use a high quality terrain model.

We investigated that as well.

Terrain data can be extremely useful, especially good government LiDAR derived elevation, but the model is still describing a surface and your runner is travelling along a particular path.

A few metres of horizontal GPS error on the side of a steep mountain can move the route onto a very different elevation.

A bare earth terrain model also does not know that you ran across a bridge, along a boardwalk, through a tunnel or over deep snow.

Resolution matters, interpolation matters, datum matters and the age of the survey can matter.

Better terrain data gives you another source of evidence, it does not automatically turn the number into truth.

What Track3D found when we tried to fix it

This started because I wanted Race Planner to produce a better elevation number.

The raw GPX calculation was clearly high on enough courses that it seemed like a problem that should have an engineering solution, I love an engineering solutions because math doesn't take sides.

We tried the obvious things first, different resampling distances, smoothing and filtering, then kept going when those methods did not hold up across a larger set of races.

The final research programme ended up testing 26 prospectively frozen experiments using synthetic routes where we knew the true elevation, 40 real courses across 18 race families, published race and checkpoint elevation, different representations of the same GPX and independent terrain data.

We tested smoothing, wavelets, trend methods, pruning, terrain substitution, terrain fusion, statistical models, repeated observations and different ways of bounding what the real profile could be.

One result illustrates the problem really well.

A wavelet based candidate reduced average disagreement against published race elevation from about 9.7% to 3.7% across one comparison group.

On that number alone it looked like we had found the answer.

Then it failed other tests.

It could remove genuine elevation from clean profiles and it was not stable enough when the same underlying course was represented differently.

It was better at matching the published number, but we could not demonstrate that it was better at recovering the actual terrain.

The most important experiment went deeper than that.

We created cases where exactly the same observed elevation points could represent two different real worlds.

In one, the little ups and downs were real terrain.

In the other, the underlying route was flat and those same ups and downs were measurement error.

The file presented to the algorithm was identical.

There is no calculation that can look inside those identical observations and determine which world was real because the information required to answer the question is simply not there.

We also tested the reverse situation, sparse observations that completely missed real climbing between recorded points.

Once the hilltop was never recorded, an algorithm working only from the GPX cannot reliably recreate it.

That is where the research eventually landed.

So what will Track3D do?

For an arbitrary course file, the defensible starting point is the source elevation.

That is what the file says, so that is what we can describe honestly.

We can calculate gain and loss from those observations, but we should not pretend that automatically makes them surveyed truth.

If we later have independent information that genuinely improves the evidence, for example a properly matched terrain source, calibrated sensor information or repeated independent recordings, then another estimate may be justified.

But it needs to be labelled for what it is.

Terrain estimate is different from corrected elevation.

The first tells you where the number came from, the second sounds like we know the answer.

Which elevation number should you actually use?

If I am talking about a race, I normally start with the organiser's published elevation because that is the number the race is being described with.

I still treat it as an estimate.

If I am comparing my own training, consistency matters more than trying to settle a Garmin versus Strava argument after every run.

Use the same watch, platform and settings where possible, then compare like with like.

For race planning, I care about the shape of the course as much as the final number.

Where are the long climbs, where is the steep descent, what is left after 100 kilometres, and is the climbing concentrated into a few major sections or spread across hundreds of smaller rollers?

A course with 4,500 metres of climbing and another with 4,700 can feel completely different depending on where those metres occur.

The mountain did not change, the measurement did

The next time the race website says 4,500 metres, Garmin says 4,800 and Strava says 4,300, there may not be one broken system waiting to be identified.

They may be starting with different elevation sources, applying different smoothing, using different terrain models and making different decisions about which little changes count as climbing.

Even a barometric watch is still estimating altitude from changing air pressure while weather, temperature and calibration move around it.

The mountain stayed where it was.

We just measured it with different rulers.

Research notes and primary sources

Research snapshot: 1 October 2026.

Platform methods change, particularly elevation databases, correction algorithms and device calibration behaviour. The sources below were checked when this Guide was prepared.

Elevation gain is an estimate produced from recorded observations and processing choices. Race organisers, device manufacturers and platforms can change their methods over time, and event course information can also change. For a specific race, use the organiser's current course information as the event reference and treat individual device or platform totals as estimates produced by their respective systems.