New elevation data on this site

I had been pretty disheartened by the poor accuracy of the elevation data from my Magellan eXplorist 710. I guarantee there is no walk I’ve done that I couldn’t make a better estimate at the total ascent that this GPSr can. The device can take elevation readings from GPS, built in barometric altimeter or from it’s topographic maps. All methods are rubbish. I believe my old Garmin 60CSx used to massage the GPS and altimeter data to come up with something much closer to reality. I’d also tried other web sites, but their results were grossly exaggerated too, so I decided to build my own process. I had been using the geonames web service to return SRTM elevation data, but after some research found an excellent article entitled SRTM & Ordnance Survey Elevation Data in PHP. The process involves having the elevation data in files on the web server. The data is laid out in a very structured way within the files so a pointer can direct a call to the precise data elements required very quickly and requiring very little server resource. This is much quicker than loading the data into a database for instance.

There were two problems with geonames. Firstly it was relatively slow (it’s a web service) and secondly, there are limits to how many requests you are allowed to make. This isn’t a problem for this site, but it was for mapRoute.

SRTM data has data for pretty much the surface of the planet taken at 90 metre intervals. This should be enough for my purposes. There is some OS data that’s also freely available that details the UKs elevation at 50m intervals, but it requires the location to be sent in British Grid Reference format, which I haven’t got round to looking at yet and from brief research I know it won’t be easy. (Update: I have since implemented British Grid Ref. conversion in mapRoute, but to the OS elevation data).

The issue with map related elevation data often arises when you are walking at an angle to a very steep incline, say along a cliff top. The GPS measurement only needs to be a few feet out and it will report you as being at the bottom of the cliff, then the top etc. In fact, if you have elevation data for every 90m only you could still see this problem even with an accurate GPS track log. I walk a lot in the hills, so this is a significant issue for me.

Historically I have reduced my track log points to just 100 before uploading to this site as I didn’t want too much data slowing down the process. Imagine the situation when you’re walking along a concave cliff top or ridge. In reducing the track points a straight line between two separated points now has you down at the bottom of a cliff given the above example.

Another issue occurred when two points were at a similar elevation, but somewhere between them the elevation changed considerably. Imagine walking over the top of a hill, but the only elevations recorded were at the base of the hill on either side. This scenario would report no ascent being made. The code provided by osola allows for creating intermediate points every 3″ (seconds) of a degree, which equates to approximately 90m. This too makes the resulting elevation profile too jumpy for my purposes, so I added an option to alternatively display at 6″ intervals. There’s no precise science to this. It’s not always the same interval that works best for a route, hence leaving the option to the user.

Integrating the data into a graph meant I needed to return the distance of each point from the start of the route as each section is not of equal length. I would then plot a scatter graph and join the points, so it looks like a line graph. This is where the process fell down when I originally looked at it using GPSr elevation data. Then the graph looked great, but was not accurate. For instance, the peak of a hill may not appear to be the same distance into the route on the graph and on the map. The only point locations you could guarantee were the first and the last. Returning the distance for each point gets around this issue. Alternatively you could return points at fixed intervals only.

Along the way I Ajax-ified the returning of the data and returned the data as JSON. This led on to adding Ajax to much of the site (particularly the walk page). Then I noticed how all my pages were built on HTML tables. This is considered bad practice these days, so I then went about replacing them with DIVs and CSS. Finally, I unified my buttons and made may waypoints display on all relevant routes, not just the one they had been created against.

All of the above was a great learning process, which meant I could then plug in very similar code to mapRoute. The returning of data was so quick that I was even able to return the cursor location elevation as the user moves it across the map. Note: This is turned off for basic users. I only downloaded the data for the UK (344MB), but apart from disk space and download effort there’s no reason why you couldn’t get data for any location.

This entry was posted in GPS and Maps, Walking, Web site and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>