I’ve been using my Garmin Edge 305 for a while, and I’ve always wondered how accurate the elevation gain is on the various applications used to track gps data. Using the same data, shouldn’t the elevation gain be the same, no matter which program you use?
I have 4 different applications to interpret gpx data … connect.garmin.com, Ascent, SportTracks, and ridewithgps.com. I took about a 2.5 week sample (some with deep canyons, others were just hill climbs), and I saw a huge variants. From this sample, connect.garmin.com seems to run low, http://www.ridewithgps.com seems to run high, while Ascent is the one that comes closest to the average.
| Description | connect.garmin.com | Ascent | GTC | SportTracks | ridewithgps | Average |
| Crown/Starlight Crest | 2465 | 2284 | 2420 | 1623 | 2416 | 2241.6 |
| Mt. Hamilton | 4892 | 4952 | 4973 | 4777 | 5052 | 4929.2 |
| Page Mill, OLH, Kings | 5743 | 6013 | 6148 | 5088 | 6270 | 5852.4 |
| Morgan Territory, Mt. Diablo | 5855 | 6167 | 6286 | 5189 | 6344 | 5968.2 |
| Montebello, Mt. Eden | 2670 | 2820 | 2932 | 2432 | 2943 | 2759.4 |
Taking a look at Morgan Territory/Mt. Diablo. This had climbs mostly out in the open, without too many shades. However, notice the big difference between http://connect.garmin.com and http://www.ridewithgps.com
The average is 5968 feet, with Sport Tracks at a low of 5189, and ridewithgps at a high of 6344. Ascent seems to be the closest, being a little higher than the median, followed by connect.garmin.com (although it is a little on the low side).
Based on this, I think the most accurate reading will be from Ascent. Talking to Marco, it seems that some software applications use digital elevation model underlay, and depending on which version each application uses, the resulting elevation gain may vary, even though the same source data (from the gpx file) is used.
Even though http://www.ridewithgps.com reads overly high, I still like to use it, because when you hover over the elevation profile, you can actually see the percent grade of the hill you were climbing, speed, and distance. Ascent is more accurate, and I like the way the graph are more vectored, and yes, more geekly looking than connect.garmin.com is. If there is one thing I wished Montebello Software could do with Ascent, is to give you a summary, in table form, giving you at a glance, stats like elevation gain, speed, distance, etc. Right now, you have to click the calendar, and drill down to the data you want.
Now what am I getting at? Well, from an Engineering standpoint, it doesn’t make sense. If you have the same data file (gpx file), and same data points, why shouldn’t you get the same elevation gain? Or maybe the gpx file does not give you the actual elevation data … who knows, and that elevation data is based on something else? Who knows????
Sevencyclist's Blog 
Doesn’t gpx just give you X-Y location data? I believe that the only real-time record of altitude is from your barometric altimeter, which is why I note that down after my rides.
One fun thought just to make this even more interesting – although Ascent came closest for you on Morgan Territory/Mount Diablo, who’s to say that the same package is always the most accurate for every route?
Hey there I am one of the founders of ridewithgps and just noticed this post and wanted to chime in. Elevation stuff is HARD to do correct for several reasons. First off is: what the heck can I compare to in order to get a baseline of the right/wrong values??
First off, let me shortly explain why it is not trivial…to calculate a gain/loss figure, you could easily just take the difference in elevation from one point to the next and if it’s positive, add it to a cumulative gain otherwise to the cumulative loss. However the problem is that elevation data is inaccurate! GPX files can embed the elevation data from the device which acquires the elevation, but those devices are hit and miss. If you have a Garmin 3/6/705 you have a reasonably accurate barometric sensor based altimeter. Most other units just use GPS which is horribly inaccurate for elevation. So, imagine you now have an up and down flutter of one or two meters even if you are riding along a perfectly flat ride. If you do the naive calculation, you may end up with 1000 feet of gain and loss! So, you have to apply some filtering to the data. The Garmin stuff does that filtering in the display you look at while riding, but logs the raw data to the file, so I tend to use three Garmin units as my concept of baseline for any ride.
Ok, so the other problem is that filtering is tricky because the spacing between logged points can vary from every meter to every 50 meters. If they were regularly spaced the filtering would be much easier.
What it boils down to is these filtering mechanisms require fine tuning, and I just have no idea the proper target to fine tune towards! I am in a college town with a large GIS department, so will try to find some fancy equipment and a helpful professor when I get some spare time, however it’ll be a couple months out. The good thing is that we store all your original data, so if we change the averaging stuff, your old files will benefit.
Finally, when you are mapping a ride before going on it we use some USGS provided elevation stuff which is much less accurate. As a result, it becomes difficult to corroborate the logged stuff and the USGS stuff, but I have done the best I can up to this point. I have a few more tricks up my sleeve, but I am holding out until we get a couple more pressing matters taken care of on the site.
To get this concept in full, including math graphs and code, check out a post on it at my blog, http://cullenking.com
Thanks for the excellent comments. I noticed that Garmin download is now added to the site. It’s great! Now I won’t have to import gpx or tcx data anymore.
I love the fact that I can hover graphically and get data instantaneously, and better yet, share it for everyone to see. Kudos for providing such a great product.
Ron, if you go into SportTracks, click on Settings –> Display –> Analysis. There you can see how changes in Data Smoothing can impact the final values, especially for Elevation Gain.
I forget what the default value for E.G. smoothing is on SportTracks, I think it’s 20. After a bit of trial & error I’ve now set it to 10, that seems to give EG values that agree well with what I had seen previously on my Ciclosport computer, the direct EG display on my Edge 305, and the EG value I get using Ride With GPS.
We discussed the matter a bit on this thread on BikeJournal as well. http://bikejournal.com/thread.asp?ThreadID={A326184F-66D2-4B1A-87BA-8D308534B2EB}&numPost=91
It’s a bit of a black hole. 😀
Good description of the issue, Cullen.
I obsessed about this a lot in my Bikejournal journal in Aug & September. For Aug 23, this is what I saw for a short ride I took to Mission Coffee & back:
The Random Elevation Gain Stats from the exact same gps data —
off my Garmin screen: 668 ft
according to GTC: 620 ft
according to Garmin Connect: 801 ft
according to SportTracks (smoothing =10, elevation correction off) 508 ft
according to SportTracks (elevation correction on) 815 ft
according to Plus 3 Network: 1223 ft (whee!)
This isn’t a good example since the overall gain is so small. But in the end I just decided to pick one way of measuring it and stick with it. Variations of a few hundred feet don’t matter all that much in the long run I suppose.
Ascent lets me set the “Filter altitude changes of less then” value as well as”default altitude smoothing.”
Messing with these really changes the numbers on a 100 mile ride, and trying to guess what the “best” settings are is… for me.. just a shot in the dark.
I take this approach: Anything that says I did more work is more accurate. It just must be.