Ridecast logo
December 17, 2006

Elevation accuracy

Filed under: General MTBGuru stuff,GPS — mtbguru @ 8:51 am

One of the perennial points of discussion when talking about GPS elevation profiles is the accuracy of the elevation measurement. Total elevation gain and loss on a given route can significantly deviate between various devices and from what you would calculate on a topographic map.

On our FAQ page we try to delve into this:

Most GPS devices use either the GPS signal (using triangulation), a built-in barometric altimeter or a combination of both to give you an elevation reading. The latter will generally give you the most accurate results, but unfortunately in many cases there will still be significant errors – for instance, the barometric pressure may change during your ride for other reasons than elevation change (i.e. weather changes), or the sensor itself can get out of calibration.

That being said, the devices with barometric sensors will usually give you reasonable results. There is however a problem that typically occurs on technical trails: all the tiny ups and downs of the trail result in minute elevation changes that are being recorded. These accumulate and on longer rides it will generally result in overestimates for the elevation change numbers compared to what you’ll see on a topographic map.

Accuracy is generally measured with respect to what your route mapped on a high resolution topographic map would read – this can be obtained by downloading your GPS track data and mapping the track on for instance National Geographic’s Topo! tool. Of course, the cumulative elevation numbers you will get this way are depending on the spatial resolution of the topographic elevation data – effectively resulting in some averaging. which numbers are best is in a way a mattter of taste: the topo value gives you an averaged and ‘reasonable’ looking number, but on the other hand, you did ride all those tiny bumps up and down (the problem statement is somewhat similar to the ‘length of a coastline’ problem).

We chose to apply some averaging in calculating the total elevation gain and loss from the GPS track data, in order to get fair agreement with values that are typically obtained using topographic data.

The best you get with a barometric sensor is probably a relative accuracy of half a meter or so. ‘Relative’, because in order to obtain absolute accuracy you would certainly need to recalibrate the sensor frequently.

The figure below shows some elevation data recorded on the Tahoe Rim Trail (fairly technical) using a Garmin Edge 305 in the ‘smart recording’ setting (in this setting, the sampling speed is adaptive), and it illustrates some of the minute, sub 1m elevation changes mentioned before.

GPS elevation data

12 Responses to “Elevation accuracy”

  1. ragetty Says:

    this is just scratching the surface.

    many barometer only devices smooth at up to 5m of vertical, i.e. only when cumalative changes reach +/-5m is a change registered in the log file. this is obviously too much smoothing.

    the GPS log files on my Edge 305 show discrete elevation steps of 48.07cm, and the calculated cumulative elevation gain always outstrips that shown on the Edge display (barometer?) at the end of a ride. to get the two values to match, you have to smooth the GPS data with a “4m filter”.

    notably an Edge 205 also shows these discrete steps, which rather indicates that the data in the log file is GPS-based.

    interesting – the discrete steps are also obvious in your graph, but they are only 0.5ft ?!?

    calculated total elevation gain is obviously a function of the trackpoint density, i.e. coarse data smooths, while high density picks up “vertical noise”, real or not. i like to make the distinction between real vertical noise (e.g. dominant on a trail) and measurement-based noise caused by drifting above and below a discrete altitude change (e.g. dominant on a flat road ride).

    the descrepancies between topos and calculated are highlighted by the Edge because the data density is so high. i would be willing to bet, that were the Edge to have a “dumb recording” mode (i.e. coarse), the cumulative elevation gain calculated from the GPS data would be significantly less, especially on technical rides.

  2. mtbguru Says:

    Yes, the data in the GPS log of my Edge 305 also shows steps (quantization noise) of 0.48m (like your 305), which implies this is the raw data coming from the A/D converter, and not the filtered data shown on the unit’s display.

    You catched an error on my graph, the units on the graph should be meters, not feet (I’ve just corrected it), thanks for spotting this and sorry for the mistake. Tahoe lies of course at 1800 meters, not feet…

    The best barometric sensors should be able to resolve changes a little better than this, which is why I mentioned half a foot in the text (I built an altimeter using MEMS pressure sensors myself at some point, and it had a resolution of about 20cm or so – though it was drifting pretty badly).

    Your distinction between the types of noise is a good way of looking at it indeed – on mountain bike rides you often end up with a combination of both – for instance, on longer rides I usually see a shift/drift (end point having different elevation than start point when they’re the same) in addition to the ‘trail bumpiness’ elevation noise.

    The problem/question we had was to decide which total elevation numbers to display in our ‘trip statistics’ summary – we choose to use a 2m filter.

  3. ragetty Says:

    a 2m filter is just about spot on, i think. with the Edge you could have a situation where anything > 48cm change in real altitude causes the Edge to shift 2 quanta, so a minimum filter of 1m is called for to ensure this sort of noise does get counted. a 4m filter is however too high IMHO for proper trail recording (better for road but still too high), although a slow (i.e. high) filter on the Edge *display* is appropriate, elsewise it would simply be annoying.

    technically speaking there is then (at least?) 3 sources of noise/drift in the elvation gain data – the real noise experienced on blocky technical trails, the resolution noise associated with the Edge’s sensitivity (0.48m steps) and rides then seeing a repetitive drift over and back across a threshold, and your last point, i.e. the metrological drift due to changing air pressure.

    as you say, an mtb ride probably has predominantly real noise and you could argue that the Edge (0.48m, or an applied 1m filter) is already well suited to the associated terrain. for road rides the predominant form of noise should be the resolution noise (especially in flat terrain, less so for mountain rides) and a higher filter presumably works better.

    btw – after changing the graph you now need to change the text to suit …

    ciao … ragetty

  4. mtbguru Says:

    Thanks for spotting that ragetty.
    Btw, concerning the resolution/quantisation noise of the Edge: I did a recent run with the Edge on fairly smooth terrain where it shows up quite obviously (as it would also do on road rides as you mention), check the elevation graph on http://www.mtbguru.com/trip/show/289-nachtengalenpark
    where you can see the discrete steps clearly. The graph btw plots the raw data, the 2m averaging I talked about is used to generate the trip summary data (total elevation gain and loss) in the text box on the left…

  5. ragetty Says:

    i’m having the same discussion with someone else writing GPS software – is there a need to differentiate (with the filter) between mtb, road rides & running/hiking? or does the 2m smooth do the job fine for your run?

    technically speaking, the smooth filter only needs to be a whole multiple of the Edge resolution.

    why not plot both data sets – raw and smoothed – or at least a line for the smoothed data – or is the plot then too busy? i originally used this some time ago to help identify an appropriate filter size – i.e. quantisation noise is obvious and easy to identify (e.g. in your run), but the filter shouldn’t be so high that real features (i.e. features in the plot that can be visualised on the trail) get smoother out – this was one method that helped me settle on 1m or 2m smoothing as being ideal.

  6. mtbguru Says:

    @ragetty: good points. What we settled with on MTBGuru for the time being is using the 2m filter to extract the total elevation gain/loss numbers but displaying the raw data on the plot.

    We assume the cumulative elevation numbers to be of most interest to cyclists and the 2m filter seems to give us ‘reasonable’ numbers for both road and mountain.

    Concerning the plots: we may prettify them in the future and get rid of the ugly quantisation noise you’ll see on flat rides or runs – showing the raw data has the advantage that it allows people to interpret the data for themselves and observe the quality of the data, and it was of course also simpler to implement ;) .

  7. goroguz Says:

    Just want to know if there is a way to add elevation to a road drawed with map surce, mean, a program to edit the .gdb or .gpx files? When I read my etrex vista, there is a part that only contains waypoints, I added the route with mapsource over the wayponts but don’t get the elevations to generate the perfil, how can I add the elevations?

  8. mtbguru Says:

    @goroguz: you won’t be able to do that in Mapsource. There are a number of other tools where you can get the elevation data though (technically, what you need is DEM data, DEM standing for Digital Elevation Model).
    For instance, check out Topofusion, which is a free download I believe…

  9. Idetrorce Says:

    very interesting, but I don’t agree with you

  10. Cullen King Says:

    First off, thanks for the *very* informative replies. I am using a very basic elevation gain/loss calculation when a user uploads a GPX/TCX to my site, and we have had reports from users about discrepancies between our calculated data and their GPS units reported data. I never realized the logged data may be raw, whereas the displayed is passed through a filter. We have the entire National Elevation Dataset (NED) at 1/3 arcsecond, which is supposedly accurate up to 1m vertically, with a point every 10m. The discrepancies between user reported numbers, our calculated numbers using their data, and calculated numbers using the NED aren’t HUGE, but I am not surprised to see a difference of 100 feet on a 15 mile ride. I will be investigating some ways to identify when a filter should be applied to certain logged data and see how that turns out.

    If anyone is interested in seeing these differences, jump over to http://ridewithgps.com/ and signup for an account. You can upload TCX, KML and GPX files. To see the difference between calculated using your data, and calculated using NED, edit a route/trip and select “refetch elevations”. This will overwrite the uploaded elevation data with 1/3 arcsecond data. Might play with a comparison so both can exist simultaneously.

    Thanks again :)

  11. MTBGuru blog » Elevation accuracy, revisited Says:

    [...] to revisit a familiar topic: since a few months we’re using a different algorithm to extract elevation data from uploaded [...]

  12. SergiooX Says:

    blog.mtbguru.com has potential, you can make your page go viral easily using one tricky method. Just type in google:
    Sulingi’s Method To Go Viral

Leave a Reply