UKC

My regular loop measured on Strava and on OS (online) comes out at 21.3 km (Strava varies slightly) - but ascent on Strava comes in at around 400m while on OS it is 659m. I know that GPS accuracy can vary but that is a massive difference over a short loop. Is the OS data more accurate than Strava.

In reply to EarlyBird:

I'd have thought the OS was accurate. Can you count the contours to confirm roughly?

In reply to EarlyBird:

I would have though that they use the same data* and it's the algorithm that smooths out the GPS data that might be different.

* I don't actually know.

In reply to EarlyBird:

Some of this might help:

https://strava.zendesk.com/entries/20965883-Elevation-for-Your-Activity

In reply to ChrisJD:
Hmm? "We have a 'threshold' where climbing has to occur consistently for more than 10m before it is added to total elevation gain"- that adds up to an extra 259m on my short loop. Perhaps Strava really is all about the segments.

I'll be using OS for accuracy I think.

In reply to EarlyBird:

Try importing your ride to ridewithgps.com. It has an option to re-fetch the elevation data from a real map. No idea how well this works, but worth a try.

In reply to wilkesley:

Cheers, I'll have a look at that.

In reply to EarlyBird:

Elevation is complicated. The ground is lumpy, and not mapped with adequate accuracy to reflect all the up and down bits you might actually take. For instance, imagine a set of sand dunes, just less than 10m high, and 10m contours. The dunes would not register, so counting contours won't work. But you gain about 10m every dune you climb.

Then there's the measurement issue. If you're recording with GPS, and using GPS altitude, then you'll be subject to errors in measurement, since GPS VDOP is about 3 times worse than HDOP (i.e. vertical errors are about three times the horizontal error). And, due to the semi-random nature of GPS errors, you will get a 'random walk' error, that would cause a straight line walk on perfectly flat ground to measure longer than it really is (adding up the distnaces between the 1 second interval position fixes).

You may also have loss of route data, if you lost signal due to obstruction; these are easy to spot by the 'crow flies' segments when plotted horizontally.

If you use a digital elevation model to compute the elevation, we're back to the problem of resolution, since the DEM will, at best, probably be no more than a 50m horizontal grid, so it can miss the detail. And the grid spot heights have an error. And, as you move between the points of the grid, you have to interpolate the height in some way. This might be simple bilnear interpolation, or it might be an nth order interpolation. Which might overshoot...

So, as I said, elevation is complicated, and you are unlikely to get agreement between any of the methods of calculating elevation gain and loss over a mapped route.

In reply to captain paranoia:

Only thing I would add is its also dependent on the sampling rate of your gps recording device. For example you will get poorer sampling rates on phones vs dedicated gps units unless you have a top notch phone.

In reply to balmybaldwin:

Really? I think most phones these days use a GPS receiver chip, rather than some 'interesting' combination of their RF chain (that's you, Apple), so should be getting fixes at the full 1 second rate available from GNSS constellations.

Not that I speak from experience of such modern phones (well, apart from using a Galaxy S4 for a GPS signal reception survey)...

There might be an option to reduce the logging rate, in an attempt to save storage, not that GPX files (or custom format files) are that big, in the context of a phone's multi-gigabyte memory.

In reply to EarlyBird:

In my experience GPS tends, if anything to underestimate height gain due to thresholding as discussed in other replies. However, particularly when traversing steep ground OS data tends to overestimate height ghain because pathes tend to try to be horizontal or uniformly sloped whereas and position errors introduce spurious height fluctuatiions. This becaomes particularly noticable if you try to plot the route out on a computer. The screen map is not the same thiuing as the underlying heght data model and is some cases is quite poorly registered with it. e.g in some anquet maps software I have yused if yu hover the cursor over a sharp summut the indicated height is several tens of meters to low. Moving around locates a high point offset from the displayed summit location but even this can be substantially different from the displayed summit spotheight. Try playing arouind with your own map software to see if it has these errors. I traced a line as accurately as I could around the edge of a reservoir in mid Wales and registered 400 m of height gain.

In my experience the computer map overestimation of height gain seems worse than the GPS underestimate. patrtrandparticularl

In reply to captain paranoia:
I think it's more about using smaller less effective gps sensors and saving battery life, but for example I get a much better gps trace from my Garmin than my phone over the same ride (and quite a wide variance in sector times and total ascent)
Edit: my phone is a Sony Z2 so not too shabby

In reply to EarlyBird:

My friend and I did a bike ride recently, I used my Garmin Edge 705 which recorded the distance as 27.2Km and the height gain of 225m. My friends used his tablet with Strava which recorded the distance as 27.6Km and the height gain of 231m.

Not sure which was more accurate, I am hoping it was my Garmin.

In reply to balmybaldwin:

On the other hand, I found my Hudl gave a better trace to ground truth than a uBlox GNSS evaluation module using an external active antenna.... Somewhat unexpectedly...

Mounting/carriage and antenna attitude may have a more significant effect on GNSS performance than the details of the chipset.

Not that I disagree with your comment about cheap GNSS receivers and battery saving; they may well be using receiver sleep/wake duty cycles to only get one in n GPS fixes, to save receiver power.

In reply to captain paranoia:

Some phones seem to have something wrong with their calibration. I had an Android phone that was consistently 80m too high, measured at places where there was a spot height or trig point. Initially I thought it might be using a different sea level datum, but I don't think that any of the UK datums vary from each other by 80m.

In reply to wilkesley:

Wrong geoid? WGS84 vs OSGB36? Haven't checked the numbers...

Getting a bit OT...

In reply to captain paranoia:

I can accept that data will be inaccurate - the loop I have referred to is one I cycle frequently and the distance/elevation as recorded on Strava (on an iPhone 4s) is unlikely to be the same twice, usually kinda similar though. What surprised me was the massive difference between OS data for elevation for the same route (from the online resource) and Strava's - particularly as it's such a short loop. 400m Strava or 659m OS over 21km (horizontal distance was about the same for OS and Strava) seems extreme.

Oh well, it's a trivial matter really.

In reply to EarlyBird:

Thanks all for the responses.

In reply to EarlyBird:

Does the route pass through any fairly narrow valleys, in steep hills? If so, a DEM may note you as climbing the sides of the hills, rather than passing along the valley floor (since the DEM doesn't have the resolution to map the valley floor; the valley doesn't exist in the DEM). Do enough of these passages, and you will quickly add up the extra height. Railway cuttings and embankments are a classic example. That's one possibility.

In reply to captain paranoia:

It's quite an open route over moorland. From Buxton, up Long Hill (A5004) to the crest and then down into the Goyt Valley - it then follows the Goyt Valley road up to Axe Edge and drops off the back of Axe Edge onto the A53 to roll back into Buxton. Have a look on Google Earth (or something similar) and and see what you think.