Part 1 of this series took a look at some of the technical history of developing the webmaps project. This part will discuss some of the present and future challenges in the NZ Rail Maps Webmaps.
As the initial stage of putting all of NZ online in the webmaps is nearing completion, attention will soon shift from creating maps to improving them. At the moment we are aware of three particular areas of concern with the maps:
- Source content. These are issues to be resolved in the GIS and range over a number of areas such as correct alignment to the current aerial photos, level of detail such as current station/yard facilities, captions and styles of captions, missing information such as bridges and tunnels, and overall corrections. The initial stage of creating webmaps has focused on adding all maps at their current stage of development. Some maps are already at an advanced stage having been recently revised; others need a lot of work on them. Improvements in this area will be ongoing and incremental. This also includes adding the historical aerial photos to the maps.
- Capture issues. There are a range of issues with the capture tools which are used to create the web tiles from the GIS content. The most obvious ones you will see on the website are cut off captions, which is extremely common. Right now there is not a whole lot we can do about that except by sitting down and doing some work on the capture script, which is a third party plugin to Qgis and requires us to have a more indepth knowledge of how it operates. In short, to display full captions will require adding more tiles to each capture that include the cut off parts, as it is always happening where a caption goes over a tile boundary. An issue for the capture operator is how long it takes to update the website with new content. A script that could service the mbtiles db for each webmaps layer and just update changed tiles would save a lot of time over having to recreate the database from scratch every time. However in the short term having another script to automate the rebuild is the more likely scenario. Being able to service each layer’s database remotely so that there is just a simple sync process instead of a full db replacement every time is also an attractive consideration to reduce uploading time – at the moment it takes hours to upload a new version of each db.
- Website issues. These are mostly down to either the Leaflet javascript client that runs in your browser, or the tileserver script that delivers the tiles from the web server. The main issue we’re seeing with the tileserver (it’s been shown not to occur in testing with direct tiles) is apparently how it handles missing base layer tiles, as you are supposed to see a green background when this happems and often, with some tiles at the edges of the base layer, instead you will see a missing image icon, which varies depending on browser. Firefox just displays a depressed grey square, but other browsers will have a prominent X or other graphic that looks quite ugly. Leaflet on the other hand delivers a peppermint green tile to fill in the missing tile gaps around the edges and that’s a lot nicer to look at. As the tileserver is opensource and has next to no support we shall have to spend some time learning how it works and testing it to see what is happening. The main things we want to resolve with Leaflet are for user convenience like being able to bookmark a particular location and come back to it later on, maybe a legend and maybe a scale although we prefer not to have scales on the maps as they are severely inaccurate.
So hopefully that gives a reasonable idea of where we hope to make meaningful improvements to some technical issues with the NZ Rail Maps Webmaps site.