With some time off over Christmas I’ve managed to put together a demo of client-side rendering using kothic-js, available here. This will hopefully form the basis to the next revision of Freemap (0.6), which should also feature pgRouting-based walking routes. As you will see if you look at the demo, it is styled similarly to current Freemap and incorporates Ordnance Survey LandForm PANORAMA contours. Currently it covers certain parts of the UK only (in southern England, W Sussex, Surrey, Hampshire, Wiltshire, Somerset, in northern England, Derbyshire, Lancashire and Cumbria, and the whole of Wales); due to server constraints this state of affairs is likely to remain.
So how easy was this to do? Well firstly, OpenLayers has been replaced by Leaflet as the slippy map library, as Leaflet integrates well with kothic-js. Am impressed with Leaflet’s simplicity and clean API I have to say, it seems a very straightforward library to use and doesn’t try to do too much; in that respect it feels rather similar to the FLTK C++ GUI library that I used a number of years ago for the first Freemap editor, way back when Freemap was an entirely separate project to OSM.
Data is sent back from the server in “Google XYZ” tiles in a slightly-modified GeoJSON format, another recent development in geodata which has somehow passed me by until now, and another piece of the system which is impressive in terms of its cleanness and simplicity. The kothic-js Leaflet layer basically works by requesting data tile-by-tile on demand. I did have to make some small changes to the default L.TileLayer.Kothic class to allow user-specified URLs; the modified code is available here. The server-side code is available from Freemap SVN (can be browsed here).
How were the contours done? Basically they were sourced from the standard DXF files distributed with the OS LandForm Panorama download package, reprojected into Google Spherical Mercator and added to a PostGIS database with the lfp2pg tool, available from Freemap SVN (source code here). The intensive import was done at home, then a database dump was done and the SQL imported back into the Freemap database.
So what of the demo? Well it’s obviously a bit slower than static PNG tiles but the performance does not seem to be too bad, and it’s certainly usable. Of the browsers I’ve tested on (Firefox 8, Chrome 11.0, Opera 11.6) Chrome gives the best performance as it appears to cache the canvas tiles whereas Firefox and Opera appear not to. Some server-side caching occurs (namely with the contours, which will never change) which improves things; due to server space constraints I am unable to cache everything, and querying the database for contours appears to be the slowest part of the whole process. Also, it’s significantly faster than doing live Mapnik rendering from the database server-side; with contours, that is unacceptably slow, taking 5 seconds or so to render one tile.
Aside from performance there are one or two little issues at tile boundaries. As described on the kothic site, coordinates of features have to be supplied from the server relative to tile boundaries, where (0,0) is the bottom left and (granularity,granularity) the top right. However, line features with coordinates of 0 or the granularity appear to give some bizarre tile rendering artefacts, with features becoming disjointed and not rendering at their correct position. Consequently, coordinates of 0 are adjusted to 1, and coordinates of (granularity) adjusted to (granularity-1). This means some small gaps at tile boundaries; if anyone can shed some light on this issue I’d be grateful! The ST_Intersection PostGIS function is used to “crop” features at tile boundaries BTW.
So overall I’m quite satisfied with this experiment, and it’s likely that a kothic-based renderer will become the default view for Freemap 0.6. The SUCS tiles and, possibly, home-rendered Mapnik tiles will be still available as alternative layers but the kothic tiles will be most frequently updated and importantly, will exactly reflect Freemap’s underlying database.