The UK Geographic Search Engine / Guide was an idea whose genesis occurred whilst our team were having their pre-Christmas drink in The Park on the day before Christmas Eve, 1999. We'd been kicking around a number of ideas about how many of the Internet's users didn't `get' what it could really be made to do when the concept of removing the virtuality and injecting some reality just sort of bubbled up out of thin air. Fuelled with demob-happiness some crazy ideas got discussed and then the blinding flash of the obvious hit us: why can't you search the net based on how near things are to each other rather than the text that documents contain?

Going from the thought to the execution always takes time but we were lucky. As a hobby project (mainly to learn the Qt widget set) I had already built a moving-map GPS package to run on a Linux laptop while driving. Very basic, nothing flashy, but at least it had a crude mapping engine in it. About an hour of hackery on the code hooked it into our php3-based contact manager software and presto: all of our customers' offices popped up on the maps too!

By the end of January a rough prototype of Somewherenear had been built. The location data is stored in a MySQL database and distance-based searching performed very simply by using SQL `select' statements with `where' clauses that limit the latitude and longitude of the items sought. By late March we were ready to release the thing to the world and did, feeling pretty pleased to snaffle the domain name. We know that the radius-selection algorithms won't scale but after chatting with Stuart Green (thanks Stuart), ex Leeds University, we are confident that techniques used in molecular physics can be applied to give us very fast radius detection, at the cost of lots of disk space.

We had always planned to hook the database into location-aware devices. Whether they would be mobile phones or PDAs with GPS in them wasn't clear, but it was obvious that before long people would be out and about with devices that contain browsers and also know about their location. We knew that we would probably have to deliver the data out of the system in various formats. HTML was obvious, and probably WML too, along with other XML derivatives if we proved to have built a useful resource.

Our goal was to be able to go to a strange town, press the `nearest pub' button on whatever the device was and to get a map showing establishments nearby, together with visitors' ratings. Having gone there, you should be able to add your own vote on the quality of the beer, the food, the surroundings and so on, then ask for the nearest good curry house and cashpoint to pay for the food. (Non UK-readers may not be aware of the mystic significance of curry and beer, but believe me, it is extremely important to the UK software industry. Curry houses are by far the most common food outlets in Britain. Even Macdonalds have had to introduce Chicken McTikka to be able to compete; it's just as appealing as their other offerings.)

We had an architecture already prepared for this kind of project, based on CGI programs and pseudo-HTML templates. A description of the TrainingPages training search engine was written up some time ago and has been described in a number of talks I have given. The architecture has some known deficiencies so we thought it was time to move it up to its next stage. Its greatest weakeness is that HTML ends up embedded in the CGI scripts, making them specfic to the delivery format, plus the lack of enough intelligence in the template language itself. Moving on to the next step, I decided to replace the template language with php3 but to enforce a rigid separation of responsibilities. The CGI scripts must do all the data management, the templates must deal with presentation only. This rule is an absolute winner and has proved to be hugely effective.

We still write the CGI programs in C++. It's a proper heavyweight engineering language and frankly I still don't think that Java cuts it on the server side. C++ templates provide so much power to the designer and the ability to use exception-handling to catch errors has saved us acres of code, proving in my mind superiority over Perl or php3 for the core data engine.

This article copyright GBdirect Ltd 2000. All rights reserved. Reprinted from http://www.gbdirect.co.uk/ with permission.