/ Height gain query (run mapping on UKC)
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
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.
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.
Mm, daft isn't it. My two most repped hills are both dodgy. Steep climb in in the forest nearby always comes up short.
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.
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?
That's another cause of error, yes.
'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.
Elsewhere on the site
Over the years I've been asked many times about work as a Rope Access technician, often by Instructors and Guides working for... Read more
Make the most of this months HALF PRICE OFFER on the Five Ten Guide Tennie Mid!! Designed as a hybrid approach and... Read more
2014 has been a bumper year for climbing publications. Here's a few of the ones that we have either read, or ones that we... Read more
Hot Aches Productions premiered their latest film Redemption: The James Pearson Story at Kendal Mountain Festival on... Read more
Nikwax’s uncompromising environmental ethos has once again been recognised and rewarded by a trusted authority in... Read more