PART 1 I am both grateful and full of admiration, Captain Paranoia, for your lucid explanation of the mathematics involved.
I appreciate that it is the size of the grid that affects height data but I have read that an additional factor is that the SRTM (Shuttle Raster Topographical Mission) radar used by NASA in its survey could not penetrate dense tree cover. If this is correct, it means that a further inaccuracy can occur because measurements are being taken from the tops of trees, which can be 25 metres high, rather than at ground level.
Here is more background to Roger's piece. I prepared a leaflet for my Wilderness Travel clients for use on their Coast to Coast walk. My fellow guide, Peter Goddard, whom some Challengers may know, checked my mileage and total height gain for each day using MemoryMap. The height gain on one particular day differed significantly from my calculation based on counting contours. It was an easy route to check as it followed an abandoned railway line and then climbed steadily before descending to Kirby Stephen. Apart from the main climb, there is another which crosses one contour line and one short descent which does not cross a contour. Here are the total height gain results:
Note that the contour interval is 10 metres and that, according to the OS which monitors the accuracy of its maps, each contour is accurate to half the contour interval which, in this example, is 5 metres. The altimeter is accurate to within 5 metres and was regularly checked against known heights. With these factors in mind, the figures for contour counting and the results from the altimeter are in remarkable agreement with the latter probably producing the more accurate figure. This shows that, in this particular example, MemoryMap's figure is wildly inaccurate.
Peter reported our findings to Roger who promised to raise the matter in his column.
PART 2 It would be interesting to compare MM's results with other software mapping. The Explorer map is OL19 Howgill Fells. If you don't have the paper map or the software for this area, you can access it at http://getamap.ordnancesurvey.co.uk/getamap/frames.htm. Enter the grid reference NY706057 (exactly as printed here) which will centre the map on Brownber which is the start of the route. Go east to join the abandoned railway line which should be followed to the road at NY739082. Follow the road south past Smardale Hall to pick up the bridleway. At the start of access land at NY736072, leave the bridleway and follow the wall south-east to join the Coast to Coast path at the bridleway at NY738070. This is the highest point reached. Follow the bridleway east to the junction with the road at NY747072, then south-east to the first road junction at NY748071, turn north-east to the footpath at NY748073. Follow the path ENE to Greenriggs at NY764077, then take the enclosed path via Croglam Castle (NY768078) into Kirkby Stephen.
I contacted MemoryMap, Anquet and TrackLogs and all admitted that the total height gain obtained from their software was not always accurate. They all explained that their products do not calculate height gain from OS contours, which are based on vectors, but on a raster, which is a grid.
Anquet's rely was the most revealing: Anquet calculates height gain using a digital terrain model which covers the whole of GB with readings at intervals of 50m across the country. The height of any given position is calculated by measuring the distance to each of the four corners of the 50m grid in which that position falls and using that distance, combined with the altitude at each corners, to extrapolate the height at the intermediate point. It follows that, the more level the ground, the more accurate the figure will be. A reading for the summit of Hellvellyn (a flat plateau) will be more accurate than for the summit of the Inaccessible Pinnacle on Skye. I suspect that I know the manufacturer of the software that gave a grossly inaccurate height reading. Most software manufacturers use a similar method of height calculation to Anquet and I know of a manufacturer who, until recently, was believed to be using a DTM [Digital Terrain Model] with intervals of 500m instead of 50m. This, if true, would result in errors of the magnitude you describe.
I believe that the result given by MM is distorted because one part of the route along the disused railway line runs through deep cuttings with high hills on each side, and in another section it is high above Smardale Gill. I suspect that that the raster could not cope with this difficult situation.
Hugh, allowing for not being exactly the same as described the Quo software gives a similar figure to the Memory Map. It would certainly be worth discussing this with mapyx the developers of Quo. They are a helpful lot.
I believe that Anquet are referring to Fugawi when they mention the 500m DTM. As long as the 50m DTM is the best available, all the mapping products will suffer from this inaccuracy.
Druidh: When I comtacted Fugawi, I got this reply:
Hello,
Fugawi UK does not include a height gain tool to calculate the information you are inquiring about. Fugawi UK does included elevation data. The elevation data can be displayed in the bottom left corner of the screen as your cursor moves over the map. Or, a track profile can be generated.
The elevation data included with Fugawi UK is from a third party. It is not the official UK OS elevation data.
Please email me if you have any further questions.
I suspect, that your are correct in the assumption that the errors are worst when the path runs close and parallel to steep slopes.
Out of interest, what are the results of contour counting if each route leg is a straight line (as for mapping software) and so may 'clip' a few extra contours?
This would indicate whether the errors are differences in elevation data, or minor differences in the route itself depending on how it is used.
I use mapping software and an altimeter watch (calibrated against the map at the start of a walk) and rarely get more than 10-20% difference, which I consider to be not that significant.
A point I noted in the Anquet reply referred to the fact that individual heights will be more accurate in a flatter area: It follows that, the more level the ground, the more accurate the figure will be However for total ascent/descent, the figure will be less accurate in flatter routes (as there are less contours crossed/mapping heights, and so any individual error is more significant). Also, the greater number of ascent 'laps' (periods of discrete ascent/descent) the greater the error in either method, as any errors are not 'corrected' in subsequent height measurements. For instance a route that only gains 10-50m per ascent with multiple ascents is prone to large errors, but a route with the same total ascent, but all in one go, is likely to be much more accurate using either method.
I have just checked the route in Memory Map, and it does indeed report approx 280m of ascent. However 130m of this is along the stretch of the railway, where the software profile is quick undulating. (whereas I assume the actual track is actually quite level - railways generally are, and as the start and end of this section are within 20m with the end actually lower), This seems to be mainly due to the approximations of a route (made of straight lines between waypoints), especially around Smardalegill Viaduct where the contours are very close together (steep sides), and the railway appears to be in a deep cutting (whereas the software assumes the elevation is that of the 'land' around. The map countours offer no indication of depth - this must be assumed from knowledge that railways are generally quite level.
When the contours are counted one knows this and assumes the path/track will basically contour round. If the same is done when reviewing the Memory Map figures, the totals appear very similar.
I think this reiterrates the apparent excessive errors when reading the software figures blindly, especially on a low-level route (for me a 10k walk with 300m or with 150m of ascent are both essentially flat).
Finally though, the significant differences between the elevation data can easily be seen by viewing the software elevation at points along contour lines where the 2 figures rarely match (often upto 10m difference). On routes with more or longer ascents, these differences would generally even themselves out.
A final thing to consider is that a GPS elevation profile (from a recorded track after the event), based on GPS elevation, should actually (assuming no strange readings caused by proximity to steep slopes - which occasionaly occurs) give pretty accurate results. I have found the GPS elevation to generally be very accurate (+- 5m), as long as the signal is good.
SRTM data isn't perfect, that's for sure. There are anomolies, such as voids and 'black holes', so that most programs using the data have filters to detect these sort of problems (although the latest STRM V2 has been processed to remove many of the errors). The SMC Topo website I posted earlier discusses some aspects of the conversion of SRTM to Topo data.
It's entirely possible that the radar is unable to penetrate tree cover, although this would tend to have more significance in lowland areas; above the treeline this obviously isn't a problem.
Looking at your route, I notice that the disused railway line runs through some considerable cuttings in that section. I'd agree with your suggestion that these cutting influence the readings, because they will be missed on the SRTM Digital Elevation Model (DEM), as the features are too small.
The section running alongside Scandal Beck is also a relatively narrow valley; it would be interesting to see what the 3D plot generated by the mapping tool looks like.
To see what your mapping tool thinks the route terrain is, use it to plot a route profile. On the section of railway bed, this should be a nice, gentle slope or flat section. If it isn't, you've confirmed the problem.
I'm a little confused by your mentioning an altimeter. Does this log ups and downs? Because I can't recall seeing one that does (although I've not looked very hard). I know they do delta height between a start point and current point, but not sure about logging. I'm pretty sure that electronic mapping will do both functions; delta between two spot points, and the total height climbed on the route between two points.
p.s. I don't have any mapping software, so I can't try this out... I have played with digital elevation models, though, such as LandSerf, a freeware tool for playing with DEMs. You can use this to display the SRTM data, create contour data, and even make your own maps. If you google for SRTM, you'll find lots of these sorts of things to play with, and sources for the SRTM data (or this tells you how to get SRTM data)
Regarding the altimeter - in my case this is an altimeter in a digital watch, which does log total ascent and number of ascent/descent laps (which is where I borrowed the term from in a previous post).
Many thanks Rob and Captain Paranoia for your interesting and helpful observations.
I am a dirty Macintosh man and so I cannot use, and am, therefore, not familiar with, mapping software. I don't quite understand all the points made by Rob. 'Out of interest, what are the results of contour counting if each route leg is a straight line (as for mapping software) and so may 'clip' a few extra contours?' Are you really saying that height gain is calculated in series of straight lines using waypoints? If so, who inserts the waypoints? Or have I misunderstood and you are referring to the raster?
Close examination of the Explorer map reveals that, where there is a break when contour lines cross railway lines, this indicates that the trackbed is up to 10 metres higher. This appears to be OS practice because I have found an example on another abandoned line where the contour line is shown on the trackbed. I suppose that it is relatively rare for contours to coincide with the trackbed because the change in altitude on a railway line is slight. With roads the gradients are much steeper, and where the road surface coincides with a contour, then it is shown on the road, although it only shows up clearly on the lighter-coloured minor roads. Unfortunately, I have highlighted my route on my copy the Explorer map so it is not clear how many contours actually coincide with the trackbed. Get-a-map, to my rheumy old eyes, does not have quite the definition of the paper version. Nevertheless, you are correct in your deduction that I assumed the route to be level.
I also checked the height gain using my GPS receiver. Unfortunately I have lost my record of the data and can only remember that it was close to the result given by my altimeter. I shall check this again when I walk the route again next summer.
The altimeter reading was obtained from my Suunto Vector Wrist Computer (fancy name for a multi-function watch) which records both cumulative height gain and cumulative descent. I have found it to be very accurate.
I shall follow up the information on the websites you kindly suggested, mein kapitain (do you remember the Goons?).
Hugh, Height gain is calculated along the 'route' defined in the mapping software (in the same way as you would count contours along the route on the map).
The route is defined by straight lines that join a number of waypoints/marks - the software cannot 'guess' how you get from A to B, so assumes a straight line.
When calculating your route details I created 40 waypoints along your described route, which make the 'route' follow, as closely as is reasonable, your described routes (albeit with no nice curves :).
I could have added numberous more points to get even closer to the actual route, but as it became obvious that the software height points do not exactly match the contours this did not seem worthwhile.
I also considered counting the contours that this route crossed, but then gave up as I was making too many 'well obviously the route doesnt go up the side there - it goes round' assumptions, as you would do. It also gets very messy in the railway cuttings, and wouldn't fancy counting contours along there if the had not been the elevation handrail of the railway (i.e. if we didn't know the path was level).
Now, have I got this striaght? In order to calculate height gain and distance using MemoryMap, you have to insert waypoints at significant points along the route and then the software does the calculations? Already I see possiblities for error! I assumed that all that was necessary was to run the cursor/pointer over the route, using the mouse, and everything was done automatically.
Can you insert a waypoint with a click of the mouse, or is it more complicated?
The route is created by repeatedly clicking the mouse along the proposed 'route' to create the waypoints.
In Memory Map a route is a simple point to point 'path' (with straight segments) - suited to downloading to a GPS to allow waypoint to waypoint navigation. Memory Map has another 'path' type referred to as a track. This is essentially a route, but with many more 'marks' along it (and so more detail), but each mark cannot have extra information added to it. This 'path' corresponds to the saved track on the GPS. Memory Map does not however show total ascent for tracks - I am not sure why.
Looking at the source of the errors though, the 'resolution' of the route/track is not the only source. The mapping software elevation data does not directly match the map image contours. So if a path were created which followed a contour (when one knows the stage of the route is level/contouring) this would not follow equivalent 'contours' in the mapping elevation data.
This is very evident when the maps are viewed in 3D, as the contours do not remain level. This is not a surprise though, given that the contours are just lines on an image, which is overlaid onto a 3d model using elevation data from a different source , as described earlier in the thread.
As stated earlier though, in my experiences the 'crude' mapping software calculations are 'good' enough - and much quicker and easier than counting contours! The information does need to be taken in context, as with contour counting. However with mapping software this is a separate stage, in contour counting it is part of the actual process.
