Altitude measurement - who to believe!

[Jaded]

Yesterday's Gospel Pass ride, my Garmin Edge reports climbing of 2,250m, but Tracklogs reports 2,920m.

Hmm, I think, Tracklogs is over reporting climbing?

Then, today I go out for a run that is 21 miles then a loop, then back. So the last 21 miles is the reverse of the first, for distance, route and height.
But it isn't.  It says I started at 36ft and ended at 215ft. So while I was out my house rose up by 179ft.

On this route Tracklogs says the climb was 672m and the Garmin says 462m.

The location of the waypoints on the GPX exported from the Garmin is perfect, absolutely matching the 1:25,000 OS map on Tracklogs. The average moving time on the Garmin and the distance are within 1% of my bike computer's data.

So the Garmin altitude is fundamentally flawed on today's ride - is it fundamentally flawed on climbing total too?

[Zoidburg]

This is why I like the old fashioned OS map

[rogerzilla]

Is the Garmin doing altitude by GPS or by barometric pressure?

[Jaded]

Is the Garmin doing altitude by GPS or by barometric pressure?

A mixture of both, I believe, with some temperature adjustment.

[Jaded]

This is why I like the old fashioned OS map

Inch to the Mile? They were works of art. Mine are in the loft.

[Greenbank]

Distance traveled and elevation gains are particularly hard for GPSes to calculate.

Even at highest accuracy, each individual point the GPS logs has a possible error of about 4m.

If you walk along the flat for a mile it could think you're climbing and falling 4m on alternating logged points. For the correct figure of 0m climbing to be logged the GPS will need to log the same elevation for every point along a section, which is unlikely. The compounding addition of possibly inaccurate values just makes it worse. The GPS applies a smoothing algorithm, but this is just applied guesswork.

A 60km section of Romney Marshes (almost pan flat) on the Flattest Possible 300 gave me 250m climbing as it flits betweeen 1m, 2m, 1m, 0m, 1m, 2m, etc...

I ignore the climbing figures that GPSes give. Just get to the elevation plot and find the bottoms and tops of each major hill and add up the differences. The odd 2m or 5m climbs are not really noticeable on the bike.

Tracklogs will also be innacurate as it calculates its climbing figure using a Digital Elevation Model based on elevations on a 50m grid. For any points not on a grid point it interpolates (i.e. guesses based on an algorithm) the height. If you cycle through a valley you'll often get spurious elevations from the higher points up the valley, or lower points further down.

[frankly frankie]

If you cycle through a valley you'll often get spurious elevations from the higher points up the valley, or lower points further down.

Yes there are some roads where the map-based DEM way of calculating the climbing just ain't gonna work ...

[frankly frankie]

Is the Garmin doing altitude by GPS or by barometric pressure?

A mixture of both, I believe, with some temperature adjustment.

Don't have a barometric model but AFAIK, from the manual and elsewhere, unless the barometer has been forced into 'Fixed elevation' mode eg to track pressure changes overnight, the elevations recorded into the tracklog are barometric ones (albeit the barometer is subject to periodic recalibration using GPS data).

If OTOH the barometer is in 'Fixed' mode, then the elevations recorded in the tracklog are GPS ones, which as mentioned above are likely to be smoothed (as are the horizontal co-ords).

[andrew_s]

My 60CSx, and I believe that other garmins with a barometric altimeter are the same, will only give the barometric height. You can go into setup and display the current GPS height, but that's a 1-off query and doesn't update.

When you turn it on, it goes into an auto-calibrate of the barometric altimeter. I believe that what it's doing is to monitor the difference between an averaged GPS height and the barometric height, and then adjust the barometric altimeter calibration to eliminate the difference. It will take a few minutes to get enough GPS height data to give a decent average, and another few minutes to bring the two figures together. If you are riding during this period, it will take longer than if stationary, as it's going for a moving target. Once it's done with the calibration it sticks with what it's got - it doesn't continue to check the barometer against the GPS.

If you want good heights, then you should either wait 5-10 minutes between the GPS getting a fix and actually starting to ride, or manually calibrate to the known height of your house before setting off. This is what I do, as it's a lot quicker.

For Jaded:
there's a 73.0m spot height (239ft) in the middle of the road outside your garage door (from OS MasterMap at work), so it's the initial 36ft height that's wrong.
I'd guess that if the heights in the track log are checked against OS heights, they will be correct within 20 mins of starting the ride, and then gradually drift off.

[Jaded]

Thanks Andrew!

and to all answerers. 

[Chris S]

In recent weeks I have come to the same conclusion as Greenbank - don't use the figure on the GPS unit itself, but believe the figure worked out from a tracklog.

The Haslingfield 200 last weekend was a good example. The GPS measured 2140m of climb. The tracklog showed 1780m when loaded into GPS Altitude Chart. I believe the latter figure more - even though when I finished I wanted to believe the GPS figure!

[GruB]

I've set my Tracklogs to use the OS altitude.  Are you saying that then over reports?

[Chris S]

We're at crossed purposes.

You are referring to Tracklogs^TM - the software.

I am referring to the track log of a ride.

[pdm]

Depends....
The "top of the line" GPS units with auto correcting barometric sensors are pretty good IME. You do need to be sure the starting altitude is correct when setting off unless the unit has been running for about 30 minutes or more to allow auto correction. I have done several hilly rides in the Peaks on repeated occasions and all are within 1-3% of each other and within 1-3% of contour counting. On a GPS unit without a barometric sensor, errors are much larger.
I have found most online mapping programs with elevation data way off.
I have no experience of Tracklogs.

[Jaded]

You do need to be sure the starting altitude is correct when setting off unless the unit has been running for about 30 minutes or more to allow auto correction.

This seems to be the answer.

I shall experiment.

[TimC]

Hmmmm. GPS altitude is somewhat inaccurate for a number of reasons, most obviously because the earth model it uses is imperfect. There is also a degree of scatter in any instantaneous GPS 3D position, and at the speed of the average cyclist this can be significant (though much less than it used to be when Selective Availability was used to degrade non-military receivers). It's perfectly adequate as a broad-brush measurement of altitude, or altitude change, but don't expect too much of it. Equally, the barometric altitude measurement which may or may not take precedence in your particular instrument will be a less-than-perfect example of the breed. It will be affected by temperature, density, humidity and calibration, and by manufacturing imperfections inherent in what is without doubt an extremely basic type of altimeter. To get a height gained/lost within 20% of the accurate figure by either method would probably be about the best you can reasonably expect.

Believe your Tracklogs or MemoryMap calculation - it uses data acquired with much more accurate instrumentation.

[The Mechanic]

Use the biggest value.  Your mates will be well impressed in the pub when you tell them you just climbed 10,000 feet on your bike.

[red marley]

I shall experiment.

So did I. By riding 100 laps of the old Eastway cycle circuit with an Edge 305... Accuracy of Elevation Measurement Using GPS

[frankly frankie]

I wouldn't argue with jwo! [bows to ultimate authority]

You do need to be sure the starting altitude is correct when setting off unless the unit has been running for about 30 minutes or more to allow auto correction.

Counsel of perfection though - what cyclist switches a GPS on for 30 minutes prior to moving off?  More often I reckon, I set off on the bike and then realise I haven't switched the GPS on ...
Interesting, jwo's conclusion No.3 in this context.

When you turn it on, it goes into an auto-calibrate of the barometric altimeter. ... Once it's done with the calibration it sticks with what it's got - it doesn't continue to check the barometer against the GPS.

If this is the case then I'd see that as a basic flaw in the way it all works.  The barometer is calibrated at, or soon after, start-up which is when the GPS data is at its least reliable - in many situations it would even be better not to calibrate at all (eg, if you switch on in the same location where it was last switched off).

Granted that 'leisure' GPS devices (and wrist altimeters) are nobbut toys, I don't see any evidence to take TimC's pessimistic view of their accuracy. 
Pre-GPS days, I used to tour the Alps wearing a Casio wristwatch/altimeter and, given that in most of the French Alps you get a roadside altitude check every km, I never ever, over several years, saw a discrepancy of more than 7m between my wrist and the road signs.  OK, so I wouldn't want to use it to land an aircraft on a foggy day, but short of that, I trusted it.  Similarly with the Etrex GPS positional info (not elevation), OK I might not be able to use it for a land survey, but for anything short of that it seems cock-on.

I have noticed, using non-barometric GPS, that if Sheila and I are climbing a long drag together, we never ever have the same height displaying on our GPS.  That in itself is explainable (my body blocks a lot more sats than hers does!), but what I find much more odd is that over a long climb the offset, whatever it may be (usually around 3m), seems to persist all the way up.

[frankly frankie]

Believe your Tracklogs or MemoryMap calculation - it uses data acquired with much more accurate instrumentation.

But the accuracy of the GPS data collection is still just as much an issue.  You have to make an intelligent decision about which method is likely to work best, given the circumstances.

The photo I posted upthread was intended to illustrate the sort of situation that Greenbank mentioned, where the DEM just doesn't work.  Albeit a very extreme case.
Riding alongside a sheer cliff, the positional info in the recorded track is likely to be quite poor.  And the road is a narrow one - a variation in the recorded track of say 5m either side would, using the DEM, result in about 200m too high (up a cliff) or 400m too low (down a sheer drop).  The elevations written into the track, OTOH, might be rubbishy but they probably would at least be within 50m of correct.

That's extreme but the same applies to some degree in any rugged terrain - Winnats Pass for example, or Cheddar Gorge, or wooded lumpy terrain like the North Downs.

Another case where the DEM falls down, even in the most exposed situation with excellent sats view - if you cross a valley on a high bridge - say you cross the Millau Viaduct - your actual elevation plot should be quite flat but the DEM will take you down to the valley floor and back up again.

[Greenbank]

Believe your Tracklogs or MemoryMap calculation - it uses data acquired with much more accurate instrumentation.

SRTM derived DEM data may be accurate, but only on the measurement points of a 60mx90m grid. The in-between bits are just guesswork.

Scottish Mountaineering Club

"
Contours are now derived from a finer height grid. The 3 arcsecond * 3 arcsecond SRTM grid (about 60*90m at our Latitude) has been subdivided into 2 wide by 3 high (thus about 30m square) points, which are interpolated using a 36-point spline (i.e. taking account of the nearest 6*6 grid of SRTM datapoints). The resulting finer grid was then contoured as before (using 3DEM and DEM2TOPO). This gives 'rounder' contours, which take account of local gradients and gradient changes .. however small features will still be missing, since you can only 'round' what was seen to be there, not 'invent' things which were too small to get measured in the first place.
"

Compare these two profiles:

DEM data: L-E-L GPS resources - L-E-L 23rd - 28th July 2005 (last one on the page)

Actual GPS track: http://www.greenbank.org/misc/lel_profile_final_section.jpg

The saw tooth profile between major peaks in the first half is an artifact of DEM interpolation. I rode that route and can guarantee it's as my GPS profile shows.

[Chris S]

You've probably mentioned this elsewhere, but what software do you use to create those plots Alex?

[Greenbank]

GPS Trackmaker (Free) from http://www.gpstm.com/

Load in GPX (it's picky about the input formats¹). Select the segment and plot the elevation.

It can only plot one trkseg at a time, so I usually combine the entire file into one <trk> when using it.

1. Make sure, just inside the <gpx> tags that you have a <metadata></metadata> tags, they need not contain anything, but they need to be there.

[Chris S]

Thanks  .

[red marley]

SRTM derived DEM data may be accurate, but only on the measurement points of a 60mx90m grid. The in-between bits are just guesswork.

Actually, there are no 'measurement points' in the SRTM data used by profiling software. The SRTM cells are themselves interpolated from the average of several finer resolution rasters that in turn were derived by interpolation of the original sensor data. And that is before the whole grid is again reinteroplated when projected onto the UK national grid. An additional problem with SRTM is presence of voids in the original data requiring further interpolation. These are produced over some water bodies and on steep sided slopes. See Importing SRTM data for more details.

So while absolute accuracy of the original SRTM heights might be reasonably high, their effective spatial resolution after all this processing is much coarser than the nominal resolution of 60x90m.