Peter Robins, his website

General strategy

Until a few years ago, geographical software (GIS) was more or less exclusively used by large corporations - government bodies, utilities and similar organisations with facilities they needed to keep track of geographically. Consequently, much of it is heavy-duty and not really suited to my small-scale needs. It assumes that such corporations produce and maintain all their own data, and if they publish on the web this is only a small part of their activities; their employees and contractors are their main users. It's not oriented to collating and combining data from other sources which is what I wanted to do. It is also largely proprietory. However, the popularity of browser-based mash-ups, as particularly promoted by Google, plus the increasing availability of open-source projects, is now changing that.

My basic objectives were to:

• use the national/regional topo maps as a base layer; most of these use either WMS or some similar kind of tiling system; they are also in a variety of projections
• overlay this with detailed route lines
• overlay also with POI info
• provide an overview map of routes at a European level
• provide this in a standard web browser, run from a standard LAMP-style web server (so no ability to run heavy-duty corporate-style GIS programs)

Having line and point data entails having:

• somewhere to store it, i.e. a database of some sort
• a means of maintaining it; as I don't have the time to maintain all the features myself, this also entails a system for different people to collaborate in the maintenance
• a means of querying it, either geographically or according to attributes or tags

Running 'mash-ups' in the browser means thinking carefully about what is best run in the browser and what on the server. Geographical data can consist of large datasets - a detailed linestring can easily be many thousand kB in size, and it's important to reduce data transfers between browser and server to the minimum to cut down on bandwidth usage and reduce the latency (time taken for user to see results in the browser). For an overview map of routes, transmitting all the route details every time and expecting the browser to render them all in a reasonable timespan is not realistic, so having this entails rasterising the detailed lines into images that can be quickly sent to and rendered by the browser. On a corporate system, this might be done on the fly, but pre-creating them in a tile cache is also a possibility.

Google Maps

I started off, like many others, with some small experiments with Google Maps. In essence, this provides:

• world-wide base layer maps: a street map, satellite imagery, and a combination of the two
• the ability to take vector data, such as points and lines, and display them on top of these base maps; these vectors can be either created in the browser or read in from a file
• the ability to display further information on these vectors in a separate pop-up window
• there's also the ability to display icons for places that have a wikipedia page or panoramio photos
• there are also some other geo-services, such as for geocoding (converting addresses to geographical coordinates), displaying traffic information, and driving directions, none of which are all that interesting to me

To some extent, this meets my objectives, in that you can display vector data over base layer maps. However, there are plenty of limitations:

• the street maps are fine in towns and cities which have streets, but are pretty useless out in the country where there are no streets
• the satellite imagery is good for getting the lie of the land, but is of limited use for actual route-finding in the country; for this, you need topo maps
• although there is some capability for adding your own base layer, this is limited, for example, Google only supports one projection, which isn't much help if you want to use topo maps; it doesn't support WMS or other tiling systems
• although there's some support for reading in vector data from outside, this is limited to kml and georss. The usefulness of these only goes so far; they cannot be used, for example, for querying and selecting on certain attributes or tags. Rather curiously, there's no support for GeoJSON which would seem to be ideal for data transfer to and from the browser

Open-source alternatives

Investigating further, I found quite a lot of work being done on open-source projects. I also found that quite a few national mapping agencies were setting up publicly available servers for their data, including topographical maps; these were often based on open-source software.

For the browser side, the obvious open-source alternative to Google Maps is OpenLayers, which is intended for precisely the sort of mash-ups that I wanted. It's oriented to open standards, such as WMS and GeoJSON, so unlike Google it works with most of the main file formats and web-service protocols; it also dovetails nicely with Proj4js to allow any projection. It is designed to be flexible and, this being Javascript, you can essentially override any property or method to do whatever you please. The choice of OL became even more obvious when I found that both the OS in Britain and the IGN in France were basing their APIs on it, and some of the other map agencies, such as the Catalans, were using it for their online map viewers.

For feature storage, also from the Metacarta stable is FeatureServer, a simple Python system for providing geographical features as a web service, including selection on both attributes and geographical bounds. This can use a variety of back-ends for data storage; the most-used is probably PostGIS, but that's generally not available on a standard LAMP web host. MySQL would be better for that, but unfortunately there is currently no driver. I could have written one myself, but decided to use SQLite instead; this has the advantage of being very portable. As for output, the FeatureServer default is GeoJSON, but it can also output in various file formats such as KML, or act as a WFS server. It also has the useful ability to process the output, for example, apply the Douglas-Peucker algorithm to simplify linestrings.

Although FeatureServer works nicely, using it does mean that the feature data is stored on my server, which increases the load on that. As this is for the most part not my data, but simply data I have collated from elsewhere, it would be better if this could be stored elsewhere. There's also no built-in collaboration facility. So another possibility for feature storage, even if not open-source, might be Google's recently announced Maps Data API, which is intended to provide query capabilities, and would mean storage and bandwidth issues would be Google's responsibility, not mine. Collaboration would also be included. Normally, fetching data from another server would not be allowed by the browser; I could set up a proxy on my server to pass requests on to Google, but Google also provide a cross-server mechanism which gets around this restriction. However, at the moment, the API is very limited in what it can do, so is a possibility for the future rather than for now.

The final part, creating the overview map, is more complicated. As stated above, this cannot be done in the browser. There are various open-source server programs which can read rasters from WMS and other servers, combine them with vectors from files or WFS servers, just like OpenLayers, but then output the result as a JPEG or PNG image instead of displaying in a browser. GeoServer is a Java program which does this, but I chose to use MapServer, which is a C program. This, of course, won't run on a standard LAMP stack, but it can be run offline, and the images stored in a cache, which is later read by OpenLayers. Metacarta also produce TileCache, another Python program, which can be used for this. Fortunately, the route lines do not change very often, so the cache does not need to be regenerated very often either. For the map base, the national topo maps can't be used, as they are not Europe-wide (and are also copyright), so I use the SRTM rendering from the CEOS server at UCL instead.

The final picture

• the route line and POI data are stored in SQLite files and managed by FeatureServer
• for the overview map:
  1. TileCache runs offline, and uses MapServer to generate a cache of tiles
  2. MapServer in turn reads the simplified line data from FeatureServer and generates the PNG tiles for TileCache
  3. when generated, this cache is copied to the webserver
  4. the browser then uses OpenLayers to fetch the appropriate tiles from the cache and lay them over the SRTM rendering
• for the detailed route lines, OpenLayers runs in the browser, and fetches:
  1. the topo map rasters from the map agency WMS or map-tile server (it can also fetch Google and OpenStreetMap layers if required)
  2. the appropriate feature data from the FeatureServer database
  it then displays one on top of the other

Popups

One of my pet hates with Google Maps is those infuriating popups; you carefully pan the map to display the area you're interested in, click on an icon, and the stupid popup jerks itself into the centre of the viewport - grrr! OpenLayers also has popups but, fortunately, as it's flexible you don't have to use things you don't like. So I decided to use the Prototype Window class for popups instead. This provides movable window overlays and looks nice, but is rather bloated, so I may change to something more lightweight in the future.