Comments on: Elevation accuracy http://blog.mtbguru.com/2006/12/17/elevation-accuracy/ The MTBGuru weblog and forums Wed, 25 Jan 2012 22:41:08 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Gift Gourmet http://blog.mtbguru.com/2006/12/17/elevation-accuracy/comment-page-1/#comment-71852 Gift Gourmet Sat, 14 Aug 2010 19:52:35 +0000 http://blog.mtbguru.com/2006/12/17/elevation-accuracy/#comment-71852 helpful post. helpful post.

]]> By: MTBGuru blog » Elevation accuracy, revisited http://blog.mtbguru.com/2006/12/17/elevation-accuracy/comment-page-1/#comment-65783 MTBGuru blog » Elevation accuracy, revisited Tue, 12 Jan 2010 16:55:33 +0000 http://blog.mtbguru.com/2006/12/17/elevation-accuracy/#comment-65783 [...] to revisit a familiar topic: since a few months we’re using a different algorithm to extract elevation data from uploaded [...] [...] to revisit a familiar topic: since a few months we’re using a different algorithm to extract elevation data from uploaded [...]

]]> By: Cullen King http://blog.mtbguru.com/2006/12/17/elevation-accuracy/comment-page-1/#comment-47464 Cullen King Sun, 22 Mar 2009 21:02:27 +0000 http://blog.mtbguru.com/2006/12/17/elevation-accuracy/#comment-47464 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 :) 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 :)

]]> By: Idetrorce http://blog.mtbguru.com/2006/12/17/elevation-accuracy/comment-page-1/#comment-8565 Idetrorce Sat, 15 Dec 2007 23:06:26 +0000 http://blog.mtbguru.com/2006/12/17/elevation-accuracy/#comment-8565 very interesting, but I don't agree with you Idetrorce very interesting, but I don’t agree with you
Idetrorce

]]> By: mtbguru http://blog.mtbguru.com/2006/12/17/elevation-accuracy/comment-page-1/#comment-7025 mtbguru Mon, 12 Nov 2007 19:04:30 +0000 http://blog.mtbguru.com/2006/12/17/elevation-accuracy/#comment-7025 @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... @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…

]]> By: goroguz http://blog.mtbguru.com/2006/12/17/elevation-accuracy/comment-page-1/#comment-6855 goroguz Sat, 10 Nov 2007 21:48:09 +0000 http://blog.mtbguru.com/2006/12/17/elevation-accuracy/#comment-6855 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? 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?

]]> By: mtbguru http://blog.mtbguru.com/2006/12/17/elevation-accuracy/comment-page-1/#comment-26 mtbguru Sat, 30 Dec 2006 22:09:43 +0000 http://blog.mtbguru.com/2006/12/17/elevation-accuracy/#comment-26 @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 ;). @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 ;) .

]]> By: ragetty http://blog.mtbguru.com/2006/12/17/elevation-accuracy/comment-page-1/#comment-23 ragetty Fri, 29 Dec 2006 08:24:15 +0000 http://blog.mtbguru.com/2006/12/17/elevation-accuracy/#comment-23 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. 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.

]]> By: mtbguru http://blog.mtbguru.com/2006/12/17/elevation-accuracy/comment-page-1/#comment-22 mtbguru Wed, 27 Dec 2006 23:10:48 +0000 http://blog.mtbguru.com/2006/12/17/elevation-accuracy/#comment-22 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... 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…

]]> By: ragetty http://blog.mtbguru.com/2006/12/17/elevation-accuracy/comment-page-1/#comment-20 ragetty Tue, 26 Dec 2006 16:12:44 +0000 http://blog.mtbguru.com/2006/12/17/elevation-accuracy/#comment-20 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 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

]]>