NZRM Progress Report 2023-09-05: Main South Line, North Island Main Trunk, Webmaps

Since the last update report, random work has been done on sections of the Main South Line (specifically Timaru Station Yard) and North Island Main Trunk (Ohakune-Horopito, Raetihi Branch and Marton, with a look as well at some of the stuff previously done for Mangaweka-Utiku). The focus on what is now being shared with Facebook groups is changing into high resolution mosaics of specific station yards, rather than actual drawn maps, because although these sections have been mosaiced, they haven’t yet been mapped. There is in fact no current plan for drawing any new maps, the work with the GIS of late has been updating the various map projects (V1-V12) to fit the new volume boundaries issued on 1 July and be updated to the new view-supporting data structure. This means the views feature will be more widely used in the future as it has become much easier to create the specific views due to having the new production scripts that automate the display of views when producing maps.

The big topic of late has been the webmaps, and how to update them. Technically the two different styles widely available are raster and vector tiles. The current NZRM webmaps use raster tiles. Each XYZ raster tile is 256×256 pixels. They are generated automatically by productions scripts running in the GIS that output all of the tiles at every required zoom (currently up to 20 in the current version of the webmaps). As a user zooms in or out of the webmap client (Leaflet), the tiles for the current zoom level are loaded in from SQLite databases on the webserver (MBTiles files). This gives the illusion that the zooming in or out is dynamic when in reality the tiles are pre-generated.

Vector tiles offer a lot more client capability because the rendering is done within the client rather than being pre-rendered as with raster tiles. The tile files that are stored on the server, rather than containing the physical pixels to be drawn on the screen, just contain the information that tells the client how to draw the pixels itself. This should overcome many of the technical limitations seen in the current client that majorly affect the quality of what is being displayed there.

However, inasmuch as there is purported to be a quantum leap in usability and quality for vector tiles, to achieve this requires a similar quantum leap in development of a new vector tile compatible web client and the associated back end processing. For example – styles have to be created to tell the web client how to draw the pixels. This is a new design paradigm that isn’t able to be automated from the current GIS styles in the way it is at present when the raster tiles are generated. Another issue is that a different web client has to be used (OpenLayers seems the most likely to be used at the present time). Also to be considered is how to get the data out of the GIS into the vector tile files – whether it can be done from the GIS, or whether some other form of software will be needed to create the web tiles.

At the moment therefore the decisions about how to proceed forward and implement the proposed webmaps upgrade have not been taken. There is still more investigation needed and it is presently more or less 50/50 as to whether to go ahead with a webmaps upgrade or just update the tiles for the current webmaps format and continue to maintain that. Whilst those questions are being mulled over, the focus has also shifted somewhat into using this pause to address other project resource issues, mainly computers and working environment related. The primary mosaic editing computer has had its Pentium G6400 CPU replaced by a Core i5 11400 that has resulted in greatly reduced file save times in the mosaic projects thus improving productivity. This computer’s role will become secondary when the other computer that creates mosaics is upgraded next year (the Project’s oldest computer is now almost 10 and the work will benefit from replacing it).