​​​​​​​

MESSAGE BOARD

THE CHALLENGE COMMUNITY, ON-LINE!

FRIENDLY ASSISTANCE AND ENCOURAGEMENT AVAILABLE FOR CHALLENGERS OLD AND NEW,

FROM FRIENDLY AND ENCOURAGING CHALLENGERS, NEW AND OLD

PLEASE USE YOUR OWN NAME WHEN POSTING. THANK YOU!

Download route sheets, admin forms, event documents here

Any queries? Email the coordinators  Sue, Ali & Mick at tgochallenge@gmail.com 

The TGO Challenge Message Board
Start a New Topic 
Author
Comment
View Entire Thread
Re: Accuracy of OS Maps total ascent data?

A few years back Lord Elpus and I had lengthy discussions on this subject, that came about because a very experienced Challenger had had his route rejected with an undue amount of red ink on account of his ascents being deemed to be heavily underestimated. (I would point out that this was by no means the only reason his route was rejected.) It transpired that he had indeed contour counted and the Vetter had used digital mapping.

I checked the entire route myself using my RouteBuddy mapping software. I use the 1:50k version, which whilst not as accurate as a 1:25k map can actually be massively more accurate. RouteBuddy absolutely shines because you can switch between the mapping view and the aerial view. Using Aerial view you can zoom right in and actually plot your route on every single wiggle of each footpath. This means that you are actually plotting your route as it is on the ground, rather than the best estimate that mappers have used for their dashed line.

Of course, the Very Experienced Challenger's height estimates were much more accurate than the Vetter's, who quite obviously had not plotted the route accurately and perhaps had not had the benefit of using RouteBuddy. If he had, I surmised that he had not used Aerial view.


However, no matter how accurately you plot your route on digital mapping, you are using a digital product whereas contour counting is an analogue solution.

As I understand it (please correct me if I am mistaken here) Ordnance Survey releases a set of height cells for the whole of Britain to the mapping software companies. Each cell is 5m x 5m in size and given a height to 1m. That's a colossal set of data. As an aside, from reading the O.S. blog the accuracy of this height data in moorland areas is less than that of rural areas, which in turn is less accurate than urban areas. This can be verified quite easily by hovering over a spot height and noting the often quite large discrepancy.

Imagine now plotting a route as a shallow diagonal up the side of a steep-sided valley oriented at say a WSW - ENE direction. Let's assume that the O.S height cell grid is oriented in a N/S - E/W arrangement. If we ignore the inaccuracies of route plotting it becomes apparent that our route is now cutting across and clipping a lot of height cells. Some of these cells, as you advance up the side of the valley will quite probably have a lower given height than the preceding cell as the height given to it will be the height at the centre of the cell and your route is higher than that centre. Because of this, over a longish walk up this valley side your software will see the route as mostly up hill with a very occasional drop every now and then, (which has to be addressed with an increase in ascent) whereas in real life there could be no drops at all. This results in a slightly higher ascent figure than contour counting will produce.

Couple this inherent digital error with the map-makers line of best fit on 1:50k maps for the footpath and then add in sloppy plotting and you arrive at inevitable large errors. Colin is spot on saying great care should be taken plotting in complicated terrain as the digital errors can make massive differences to the calculated ascent.


Having said all that, I agree with Ian: If your legs know how it feels to climb 2,000m of mapping ascent, it's not that important in the overall scheme of things. However, I believe its quite important to show the Vetters that you have taken care in preparing your route; sloppy ascents will be a red flag signalling that there may well be all sorts of other errors throughout your route.

Re: Accuracy of OS Maps total ascent data?

An interesting discussion - thank you all. Since I originally posted, I did a little investigating of my own. Without getting into detail, I've concluded that (1) the discrepancy between CalTopo and OS Maps is likely due to different sampling inervals. CalTopo seems to adjust the sampling interval to a point where the shorter the track, the more accurate the elevation data; (2) OS Maps does not seem to suffer nearly as much from the same sampling interval problem, for reasons not entirely clear (different algorithm), and (3), in conclusion I think the OS Maps numbers are closer to ground truth. As they say, all models lie...but some can be useful anyway.

Agree that track accuracy is important. And, yes, a single total ascent number hardly tells the story. In fact, I've never paid attention to a "total ascent" figure before now. I generally pay attention to the bigger picture of when and how much the ascents and descents occur and how steep they are, over what terrain etc.

Experience is the key. We know what a 230-mile +/- 50,000 ft trek and 26-mile +/- 5,000 ft day feels like, so as long as we can keep our mental metric conversion algorithms online, I suspect we'll be be ok. :wink:

Re: Accuracy of OS Maps total ascent data?

I am getting a slight feeling of deja vu.

Re: Accuracy of OS Maps total ascent data?

Indeed Emma - it's déja vu all over again! :upside_down_face:

But this is a favourite old chestnut, so let's not spoil the fun. For completeness I'll add to the posts above by repeating my own observation regarding graphic representations on maps with regard to ascent figures - from my blog way back in 2008!

The big problem seems to be with roads, tracks and paths. Any road on the map is merely a graphic, scaling at maybe 30 m wide on a 1:50,000, and, crucially, unconnected to the height data. This is why, on Memory Map, the occupants of the cottage near Braemar at NO127909 are apparently faced with the problem of the opposite side of the road being 16 metres (52 ft) higher than it is outside the house (must be a problem backing the car out of the garage!).

Thus any route plotted along this road, if it deviates slightly from one side to the other, will record 16 metres of additional ascent at this point alone - and along its length these errors will add up to a great deal.

Zoom in on Memory Map and pick any land rover track contouring around a hill, between contours. Using a paper map, we will say that the ascent here is zero, and so it is. But check the height on the left and right hand sides of the track, and you will find that it often apparently slopes by as much as 3m or 4m. The same applies to canals - sloping water!

When we plot a route we might stay within the confines of a road or track, but it is simply not possible to get an accurate ascent figure whilst the software is incapable of recognising that a track or road is (mostly) flat from side to side.

That said, our 'paper' method does not take account of undulations along the track that do not break the contour line. However, I reckon that any underestimation that this might produce is relatively insignificant.

One for the boffins to work on, but for now ..... count those contours!!!


Plus ça change and all that.

Happy New Year - although it's probably just a repeat of the old one. :wink:

Re: Accuracy of OS Maps total ascent data?

Hi Phil,

I certainly have no wish to spoil such innocent fun – and with all the boys and girls playing together so nicely. I think I have seen that house outside Braemar. I wondered why they were parking on the road.

2018 does seem to have a lot in common with 2017 (it is raining in a very similar way), but I feel it is going to be much better. Happy New Year to all! :champagne: