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.

Starting out

One morning I woke up with an idea. Wouldn’t it be great to have a web application that allowed me and other walkers/hikers to plan routes. mapRoute was born. There are a few similar apps, but they are all pretty limited. I wanted better mapping (UK Ordnance Survey 1:25K), ability to create and edit routes easily, then store them on the server and download them at will so I can load them onto my GPS receiver. As the project progressed my requirements grew and grew, but this was the starting point. The project is about to go live, so I thought I would share the experience over the next few posts.

At the start I had to do some reading and quickly discovered that my minimum requirements would be an understanding of the following:

HTML

A few years ago this was all most web sites had. It’s just a markup language that allows you to create a simply formatted document on the web. I’d used this for years and there’s really not much to it. You can’t create a web app with HTML, but you do need it as a starting point. HTML5 is now available, which provides much more functionality than past versions.

JavaScript

This scripting language runs in your browser and brings a web app to life. JavaScript can interface to databases APIs, variable data and the Document Object Model (DOM), which is really the HTML. I knew a tiny bit of JavaScript, but I would have to learn much more. This was to be my steepest learning curve. Fortunately I saw my brother-in-law the weekend I started and he gave me a recent JavaScript book thick enough to club a bunch of 70′s DJs to death.

CSS

Cascading Style Sheets allow you to format web pages while separating formatting from content. You can do much more than you’d think with it, so it was important that I got to grips with CSS quickly.

AJAX

Ajax is cool. It allows you to communicate with a data source (database, API, web site) without reloading the page. Remember how you used to fill out a form, press submit and the page would re-load. This was the only way to pass data. Now think of when you type something into the Google search engine. After each character the page shows matches with what you’ve typed so far. Ever wondered how it does this? It’s Ajax. Each time a key is pressed Ajax sends the string back to the server, which returns a set of results… all without a submit key or a page re-load. The search button is now superfluous on that page. Another example relevant to my project is Bing maps. As you move the map more tiles automatically load. It’s not magic, it’s Ajax.

PHP

(PHP: Hypertext Preprocessor) is a pretty straightforward server-side language. All of my Ajax calls PHP code. The PHP code makes database calls, gets elevation data or makes calls to APIs. I needed to write some proxy code to allow calls to be make to external domains. As session variables are server-side I also use PHP to deal with these. When I started this site I originally used Perl as my server-side language. Personally I find PHP is much easier and have converted all Perl to PHP on this site now too.

mySQL

This is an open source database manager that is supported by many web hosts, including mine. As I am a SQL Server DBA, this should be a piece of cake for me. At last, an easy bit.

JSON

I am very familiar with XML due to my job, but all GPS users should know some xml, as gpx files are really XML data. It’s a method of representing data in text form, so it’s ideal for passing between applications. JSON is a lightweight and simple substitute for XML. It tends to be more popular for API and web services. It is pretty straight forward to pick up.

APIs and other stuff

Bing Maps 7.0 was chosen because of it’s ability to provide 1:25K OS maps, something that the Ordnance Survey themselves couldn’t do. Geocaching Live API was used to provide calls directly into the geocaching database, currently holding over 2M active geocaches worldwide (150K in UK alone).

There would also be various libraries to provide graphs, date entry and even a little jQuery to enhance the user experience, but I decided to keep this to a minimum.

Talk Talk were now listed as having an LLU here so I decided to give them a go though I quickly backed out of that when it became clear just how useless they were. A pushy helpdesk person with little or no knowledge tried to force me to take limited downloads against my wishes. Her explanation of why I couldn’t have the unlimited downloads promised until the point of payment were infantile. An indicator of what would come later was enough to end any ideas of using this ISP.

I then discovered that Sky had just put their equipment in my exchange too. I decided that their unlimited broadband and phone usage package was worth a try and signed up on line. I signed up in mid December, so due to the holidays my go-live date was 3rd Jan 2012. The modem/router (Sagem wireless N) arrived a few days before. It’s a bit annoying that I must use it (otherwise infringing Ts&Cs), but it doesn’t look terrible, unlike the AOL junk. My Netgear may find it’s way onto eBay.

On the agreed go-live date I returned to my desk from lunch to find my broadband disconnected and the phone line working. I nervously plugged in the Sky modem/router and away we went without the slightest hitch. The first 10 days are a tuning period, but the initial 2.1Mb/s where as good as I could hope for. Over the next couple of days the upload speed has increased to about 0.7Mb/s, so I’m pretty happy at the moment. Downloads are (apparently) truley unlimited and unlike AOL I can also download during peak times (evenings). I’ve downloaded several GB already and it’s all good. The router appears to compare adequately with my DGN 2000. This includes the wireless N signal.

Costs are :
Line rental £12.25 – a slight saving of BT line rental
Unlimited phone calls £5 – practically all calls apart from those to mobile phones
Unlimited Broadband £10 – uncludes £2.50 suppliment as I don’t have Sky TV
Withhold number and caller display are free

Total price is £27.25/month though it will only be £20 for the first six months. This is considerably cheaper that AOL (£33.50 including line renal) and additionally includes free calls at any time and a much faster Internet connection.

The final joke is that AOL emailed me 8 hours after the switch (and wrote a few days later) to say that they were aware I was leaving and it wasn’t too late to change my mind. Just the level of service I’ve come to expect from them. Good riddance to bad rubbish I say.

This post was made from an email sent to my WordPress email account. Nice!

After a rocky start with eHostPros back in 2006 I have had a pretty smooth time of it. In fact I hadn’t raised a support ticket since 2007. Maybe the grass isn’t always greener on the other side. I’ve always been told that if you don’t ask you don’t get, so I fired a quick support ticket requesting the 5GB disk space that new starters get, but also requesting to keep my ability to host multiple domains, which new users don’t get. There was an immediate reply that it had already been implemented. I wonder if I would have had the same response if my contract wasn’t up for renewal.

I’ve raised a few support tickets in the last few days. Most have been dealt with professionally and quickly. I was rather disappointed that they couldn’t get the Advanced Guestbook working, despite offering it from cPanel. It’s not a biggie though, and I knocked up a very simple one using PHP in a couple of hours.