Correct GPS Elevations
View Full Version : Correct GPS Elevations
Ok I an throughly confused.
Where can I get accurate elevations ?
Last weekend for example.
The Elk River Valley 100k Ride
They advertise 1736 feet climbing from MapMyRide.
I plotted it in MMR and got exactly 1736 also.
Took my Edge 305 and did the ride.
I got 3044 Feet climbing.
I even imported my ride data into MMR and came up with 1736.
Which is right ??
Ok I an throughly confused.
-- snip --
Took my Edge 305 and did the ride.
I got 3044 Feet climbing.
I even imported my ride data into MMR and came up with 1736.
Which is right ??
MMR showing the same # with the edge 305 is not surprising because it probably dumps the 305's elevation info. I'd be curious to see how the elevation shows up on (say) bikeroutetoaster.com or with sporttracks with the elevation correction plugin.
The garmin (https://buy.garmin.com/shop/shop.do?pID=331)site says that the 305 uses barometric info for altitude changes. So that might explain the disparity between what the 305 and mmr show.
Also try www.ridewithgps.com (http://www.ridewithgps.com)
I have done a few rides mapped out on that and it seems pretty acurate.
I have an Edge 305 and have always had discrepancies in elevation data on the device versus what shows up in Garmin Connect when I upload the data.
It used to bug me a lot when I uploaded rides to Motion Based, because the data from the 305 might say 6000 feet of climbing, whereas MB would say 7800. That's a big difference. Garmin Connect is not as bad. If the 305 says 6000, GC might say 6500 or so.
I have contacted Garmin about this issue, and there doesn't seem to be a real good explanation. I was told to trust the data after it is uploaded to Garmin Connect, because the software further analyzes and cleans up data from the device.
Having said that, the 305 uses GPS coordinates and Barometric pressure to determine elevation. This is as accurate as it gets as far I know.
I have an Edge 305 and have always had discrepancies in elevation data on the device versus what shows up in Garmin Connect when I upload the data.
It used to bug me a lot when I uploaded rides to Motion Based, because the data from the 305 might say 6000 feet of climbing, whereas MB would say 7800. That's a big difference. Garmin Connect is not as bad. If the 305 says 6000, GC might say 6500 or so.
I have contacted Garmin about this issue, and there doesn't seem to be a real good explanation. I was told to trust the data after it is uploaded to Garmin Connect, because the software further analyzes and cleans up data from the device.
Having said that, the 305 uses GPS coordinates and Barometric pressure to determine elevation. This is as accurate as it gets as far I know.
Barometric pressure is accurate. GPS elevation isn't nearly as accurate as barometric
As far as the differences you're seeing between what's on the 305 and what's on GC, that's the result of GC doing data smoothing.
Regarding elevation and the question 'why gps units use barometers', here is an interesting write-up (http://wiki.motionbased.com/mb/Barometric_Altimeter)
Hey all, I am one of the founders of [url]http://ridewithgps.com/[url] and wanted to chime in on elevation accuracy. I struggled for a while getting our stuff as accurate as possible, however, there will always be some discrepancy amongst the various sources of elevation. The elevation sources all the sites use (us included) is USGS provided data that is only so-so accurate. So when I am calculating aggregate gain/loss, the elevation source is fluctuating up/down because it's just inaccurate and gives an inflated gain/loss figure. I implemented some signal processing (electronics and heavy math) algorithms to smooth this out and pull out as much of the "real" data as possible, and got very good results IMHO.
Same goes with data reported from the Garmin device. Since it has flutter up and down, if you just naievely add up the gain/loss, it will be inflated. You have to smooth out the data and remove those high and low points. I used my garmin 305 as a baseline for tuning all these algorithms, with Zack's 305 and my friend Shaynes 705 as well. As a result, our numbers pretty closely reflect what you should see riding a route and logging with a 305.
For more details, including the math and code involved complete with pretty graphs, check out a writeup I did on it after finishing the work.
[url]http://cullenking.com/2009/6/12/using-gaussian-and-sinc-filters-on-elevation-data[url]
Hey all, I am one of the founders of [url]http://ridewithgps.com/[url] and wanted to chime in on elevation accuracy. I struggled for a while getting our stuff as accurate as possible, however, there will always be some discrepancy amongst the various sources of elevation. The elevation sources all the sites use (us included) is USGS provided data that is only so-so accurate. So when I am calculating aggregate gain/loss, the elevation source is fluctuating up/down because it's just inaccurate and gives an inflated gain/loss figure. I implemented some signal processing (electronics and heavy math) algorithms to smooth this out and pull out as much of the "real" data as possible, and got very good results IMHO.
Same goes with data reported from the Garmin device. Since it has flutter up and down, if you just naievely add up the gain/loss, it will be inflated. You have to smooth out the data and remove those high and low points. I used my garmin 305 as a baseline for tuning all these algorithms, with Zack's 305 and my friend Shaynes 705 as well. As a result, our numbers pretty closely reflect what you should see riding a route and logging with a 305.
For more details, including the math and code involved complete with pretty graphs, check out a writeup I did on it after finishing the work.
[url]http://cullenking.com/2009/6/12/using-gaussian-and-sinc-filters-on-elevation-data[url]
Excepting radar and/or laser range finding, nothing's going to beat barometric readings.
I only slightly skimmed your site, so I'll have to read later. At first blush, I would think for the typical home user a routine like the following would work alright and get rid of substantial noise: Start with a set of 5-10, or more, rides. Fourier transform the elevation data to get the power spectrum of altitude fluctuations. The power spectrum should show show some characteristic high frequency signals, over the entire sample set, which would correspond to the "flutter" you mentioned. You could apply some statistical analysis to more precisely identify the high freq noise band. Apply a low pass filter to make the high freq stuff go bye bye. Inverse Fourier transform the data, serve chilled with a side of parsley, and enjoy.
Wow, nice thorough response! I will admit, I am not a stats/math expert -- getting our current elevation stuff to the point it is at took me a bit of learning. When you say start with a set of rides, I am assuming this is a 'one time' sample set used to pull out relevant info for all successive smoothings?
Do you have any more detailed readings or links to help me out?
Excepting radar and/or laser range finding, nothing's going to beat barometric readings.
I only slightly skimmed your site, so I'll have to read later. At first blush, I would think for the typical home user a routine like the following would work alright and get rid of substantial noise:
Start with a set of 5-10, or more, rides.
Fourier transform the elevation data to get the power spectrum of altitude fluctuations.
The power spectrum should show show some characteristic high frequency signals, over the entire sample set, which would correspond to the "flutter" you mentioned.
You could apply some statistical analysis to more precisely identify the high freq noise band.
Apply a low pass filter to make the high freq stuff go bye bye.
Inverse Fourier transform the data, serve chilled with a side of parsley, and enjoy.
Automatic Translations (Powered by
):
vBulletin, Copyright ©2000-2009, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by
vBSEO 3.3.0
