/ Height gain query (run mapping on UKC)

This topic has been archived, and won't accept reply postings.
ksjs - on 06 Apr 2013
So, just mapped a run around Llyn Padarn and apparently I achieved height gain of 199 metres. I understand this might be cumulative i.e. all small increases may add up but this just seems wrong (way too much).

Is the height gain figure in fact correct or is the data the map uses wrong? By the way I ran the edge of the lake (rail track opposite Llanberis) not up Fachwen.

This should show the entry: http://www.ukclimbing.com/logbook/e.php?d=20130406&u=32582

Thanks.
captain paranoia - on 08 Apr 2013
In reply to ksjs:

There are a number of possible causes for the error, depending on how the height is calculated.

If it's calculated from the GPS track data, using the altitude values, it's likely to have significant 'random walk' errors due to the random variation in position fixes the a GNSS receiver produces. This is even worse for altitude than it is for distance, because the vertical error is larger due to the geometry of the satellite constellation (in geodesy parlance, VDOP is greater than HDOP).

If it's calculated from a terrain database using a lookup with the horizontal position values, then there will be errors associated with the resolution of the terrain database, and the fitting functions used to estimate the height from this data. At transitions between flat surfaces (e.g. lakes) and hilly terrain, there will be 'jagged edges', where the terrain appears to extend into the lake (and vice versa); a feature of the terrain mapping process and resolution. So, as you run around this transition zone, you appear to go up and down all these intrusions, and these soon add up to 199m.

The other thing to consider is how to distinguish between one 'up' and then next; if you go down by even a tiny amount, do you consider that you then go up again afterwards? If we're being strict about how much we have had to climb against gravity (not caring about coming down), then the answer is yes; we have to add up every little bit of up after any bit of down. Take enough of these tiny ups, and you find that they soon add up to 199m too...

Apparent discrepancies are one common complaint made about GPS data logging, but there's usually a good explanation, and the system is quite often correct, if contrary to 'common sense'. For instance, consider contour counting, which people often quote as the 'correct height'. You could envisage a surface which undulates between two contour values, but never crosses either contour. From the map, it would appear that you had to climb no distance at all, but, on the ground, you might have to climb nearly 10m for each undulation. Those 10m undulations would quickly add up to a considerable height climbed.

To answer your final question, is the map wrong? Well, probably not, but it's of finite resolution (probably a 30m grid of height values), and you need to understand the implications of that finite resolution.
Run_Ross_Run - on 08 Apr 2013
In reply to ksjs:
Ive had errors with height calculations on ukc before. I think there may be a bug or something in the calculations.

More so with out and backs but not tried on circulars.
IainRUK - on 08 Apr 2013
In reply to ksjs: Even the hilly version of round the lake is barely 150m of ascent... strava tends to give more reliable data for height.
IainRUK - on 08 Apr 2013
In reply to IainRUK: Sorry if you aren't using GPS though.. ignore that one..
SteveRi - on 08 Apr 2013
Sometimes you just have to shrug your shoulders and move on. FWIW strava seems to cross reference and defer to mapping data - this is not infallible. There's a hill round the corner I do reps on that has an unexplainable dip on the map. There's nothing in real life, it's just a steady climb. Garmin and Strava GPS tracks always show a descent in the middle of the climb.
IainRUK - on 08 Apr 2013
In reply to SteveRi: Strangely whenever I ran over ben Franklin bridge in philly I always, everytime, got a sudden 30% 40m high incline then steep descent... never understood why it happened.. must also come from other mapping sources..
SteveRi - on 08 Apr 2013
In reply to IainRUK:
Mm, daft isn't it. My two most repped hills are both dodgy. Steep climb in in the forest nearby always comes up short.
captain paranoia - on 08 Apr 2013
In reply to IainRUK:

> Strangely whenever I ran over ben Franklin bridge in philly I always, everytime, got a sudden 30% 40m high incline then steep descent... never understood why it happened

If you go over a man-made feature like a bridge, that feature will be largely invisible on terrain databases (it's too small to be seen by the mapping technologies such as the SRTM radar). So you will see the underlying geomorphology. Or, if the bridge is just big enough to be visible in the database, you are likely to keep 'falling off it' as your position moves through the approximated feature. It may be illustrative to turn on terrain representation in your mapping system; you will probably see a strange, lumpy feature that is trying to represent the bridge.

Is the bridge about 40m high...? Looks at Wikipedia; oh yes, it's about 41.2m high.
harold walmsley - on 08 Apr 2013
In reply to ksjs:

I had a heart rate monitor with an altimeter function. I found typically a 30% discrepancy between this and map software on MTB rides. It was much more than this initially with the default settings for data logging on the HRM because the logging rate was so slow it missed a lot of ups and downs. After fixing this (still not quite fast enough but better) the discrepancy seemed to be worst on horizontal/traversing routes with steep terrain on at least one side so I blamed map errors of the type Cpt Paranoia described.

Ultimately if you were an ant you could log an enormous amount of up and down by adding increments on a sub mm scale. For humans I think you need to decide how much up constitutes a significant effort. For biking I think this should be roughly what you could roll up at a slightly faster than average speed (assuming you arrive at a dip going faster than average and then the height you can coast to is the minimum height to bother with). Based on 12 mph (~6 m/s) I reckon this is about 2 m. The mapping and altimeter resolutions were both way worse than this with errors in opposite directions so it was good to have both. For walking or running you might want a slightly lower ideal threshold?
captain paranoia - on 08 Apr 2013
In reply to harold walmsley:

> It was much more than this initially with the default settings for data logging on the HRM because the logging rate was so slow it missed a lot of ups and downs.

That's another cause of error, yes.

> Ultimately if you were an ant you could log an enormous amount of up and down by adding increments on a sub mm scale.

'The fractal geometry of nature'

The same problem as above; how long a path appears to be (when measuring natural, crinkly paths) depends on how big your ruler is. With a big ruler (long sample interval), you get a smaller value than if you use a small ruler and measure all the small variations along the crinkly curve.
ads.ukclimbing.com
ksjs - on 10 Apr 2013
In reply to ksjs: Some good replies - thanks all. Sounds like, regardless of whether it's GPS or simply adding your run / ride to a map, there's going to be some error. I still think 199m is way out for a run that practically has zero ascent!

This topic has been archived, and won't accept reply postings.