## Tutorial: Calculating Elevation GainLet's be clear: **GPS data**: This is the most common but least accurate. Because the GPS satellites are scattered throughout the sky in a more-or-less horizontal plane, the vertical accuracy is simply not very good. In a canyon or among trees, fewer satellites will be available (and/or the signal may bounce around), and it will be even worse.**DEM (Digital Elevation Model)**: A DEM is a database of known elevations for many points on the earth — ideally millions or billions of points — derived from topographic surveys and/or from orbiting radar or lidar. High-resolution DEMs can produce pretty good estimates, especially for roads and other places where the trees have been cleared and the remote-sensing spacecraft can see clearly all the way to the surface.**Barometric data**: Many GPS devices come with a built-in barometer/altimeter, and they use the barometer for elevation data — sometimes using GPS to perform auto-calibration along the way. This*can*be quite accurate, if the barometer is properly calibrated and if the weather doesn't change. Generally, altimeters do a pretty good job with*relative*elevation changes, so you probably don't want to replace barometric data with DEM data if your goal is calculating gain/loss.**Manual calculation**: If all else fails, you can find elevations to some of your trackpoints manually — using known points from high-quality surveys or topographic maps — and do some simple math. If you know exactly where your track changed from going uphill to going downhill (or vice versa), this is the most accurate method for calculating elevation gain; you don't have to know the elevations of*all*the points, just the places that it changed direction.
## A very simple exampleHere's a "reductio ad absurdum" example that illustrates some of the problem: Imagine that you're walking along perfectly level ground for 100 meters. You're carrying a GPS device that records the elevation every 5 meters, but the signal wanders up and down a bit; it thinks that each point is 2m above or 2m below the previous one. This is the resulting elevation profile: If you add up the gain from all of the blue ascent segments, you get 20 meters — as if you'd climbed up a six-story building. But in this case, we ## A real-world exampleNow let's look at some ## Manual calculationWe'll start with manual calculation, since it Of course, there's almost always at least a ## GPS dataCalculating elevation with GPS data seems straightforward at first: you simply calculate the elevation change between every point in the track. If it goes up, you add it to the "gain" total; if it goes down, you add it to the "loss" total. Here's an example from a spreadsheet that can perform these calculations: Simple, right? But here's the problem: if we continue this calculation for all 3805 trackpoints, we find an elevation gain of ## Improvement with DEM dataIf we simply replace the GPS elevation information with data from a Digital Elevation Model (in this case, the USGS's 30m-resolution National Elevation Dataset for the U.S.), the data looks much "smoother," because the elevation number isn't jumping up and down at random like it does on a GPS. Look at the ridiculous peak in the GPS line at around 8.2 km, where the GPS thought 60 meters were gained and then 40 meters lost, when in reality the trail steadily gained about 20 meters: The green DEM line is much more reasonable, and we can calculate its gain/loss using the same spreadsheet as in the previous example. This time, the total gain/loss comes out to But surely we can do better: how can we make the calculations even less sensitive to the jiggles and wobbles that are inherent in GPS tracks? ## Reducing vertical noiseGPS Visualizer's Here's a profile of a hypothetical track with eight points. The horizontal distance is irrelevant; we're just looking at elevation gain. The raw elevation gain (the sum of all the elevation increases) is 5m+2m+5m+3m = 15 meters. The raw elevation loss is -4m-2m = -6m. Now we'll apply the trackpoint elevation threshold algorithm, with the threshold set to 4 meters. This means that in calculating the gain/loss, we will ignore any point that is not at least 4m up or down from the In the end, we're left with just three points: ## Choosing an elevation thresholdIf the hypothetical example of points A through G is from an ascent with no downhill segments, then the elevation threshold algorithm has clearly improved the gain calculation, from 15m down to 9m. On the other hand, if the drop at point D was in fact a real loss of elevation, then we've oversimplified it. It's important to pick a threshold that works well with the data set in question. Let's return to the earlier example — the 16km Zigzag Canyon loop that So, in this example, applying an elevation threshold of about 10 meters gets us very close to an accurate result — if we use DEM data. Look what happens if we do the same trials with the original GPS numbers: Yikes, that's awful. We should probably stick with DEM! ## Reducing horizontal noiseSo far, we can see that using DEM elevation data is obviously a better solution than using the raw unfiltered GPS data. But why is the elevation gain estimate still too high until we apply an elevation threshold? Shouldn't the peaks and valleys be smoothed out Below is a trail along a hillside, as viewed from directly above. The green line represents something close to reality; it follows the trail very closely. The red one wanders a bit, but it's not ...until we look at it from the side. Now it's clear why horizontal wanderings can cause problems with elevation calculations when you use DEM data. The database doesn't know that the wiggles are caused by bad GPS data, and even if the DEM's information is 100% correct, it will lead to weird results. (Garbage in, garbage out, as they say.) Let's look at the elevation profile of these two tracks: The red line in this example has a calculated elevation gain/loss of 146/119 meters; the green line is 73/47. (And the reality is probably closer to 50/25.) The red line is just too wobbly; is there anything we can do to fix it? Yes, there is: GPS Visualizer has the ability to smooth/simplify tracks using a The difference is apparent in the elevation profile too. In fact, the red line's gain/loss is now 78/51 — very similar to the green line — and the total distance has been corrected too. So, clearly, using GPS Visualizer's trackpoint distance threshold function can help you find more accurate elevation gains — not to mention distances. In this example, we used a 20m distance threshold, which is pretty extreme and might remove important details, but a distance filter of 10m or less is usually pretty harmless. To get the most trustworthy results, you might want to apply both distance ## SummaryYour - Have your GPS data replaced with DEM data — unless your elevations come from a barometer/altimeter, in which case you might get better results from the barometric data.
- Apply a trackpoint distance threshold (5-10 meters).
- Apply a vertical elevation threshold (10 meters seems to be reasonable, but a lower number would make sense in flatter terrain).
All three of these can be applied at once, if desired, via any of GPS Visualizer's input forms. The result is still not Return to the main GPS Visualizer page |