Vector Tilers

By extending the WebGL visualisation system outlined in the previous section, an al- ternative technique is to use a method called ‘Vector Tiling’. At present, there are two vector tile formats in common use, utilising GeoJSON (Mapnik) and Google Proto- col Buffers (MapBox GL). The idea behind vector tiling comes from the cartographic base maps using OpenStreetMap data, where vector data for the map is delivered to the WebGL browser which then renders the tile directly on the client rather than the tile rendering happening on the server. This means that the raw vector data is now avail- able on the client, enabling the map to be styled on a per-user basis locally. When this is extended to maps containing data, the ability to manipulate and style the geometry locally means that the technology has taken the final step towards a true web GIS. This section takes the MapTubeD image tiler, which used late binding of data on the server to create its maps, and adapts it into a late binding vector tiler, where the spatial and aspatial data are delivered to the client separately and joined on the client browser.

The internal architecture of the vector tiler is similar to the MapTubeD image tiler,

which was part of the ESRC GenESiS project5 _{and is not open source. The project}

has 13,363 lines of code written in C# and uses Microsoft’s Windows Communica- tion Foundation (WCF) library to supply the tiler’s web service. In order to create an open source project, a new vector tiler project called MapTubeV6 _{has been started. In}

architecture terms, the only common elements between the two systems are the tile referencing and geocoding (numerous published algorithms exist), the circular buffer which is central to the performance (a standard design pattern) and the tile caches, which are unique key based disk caches of rendered tiles. The structure of a vector tiler is greatly simplified compared to an image tiler as, without the requirement to render the tiles, the style does not need to be passed to the web service any more and large parts of the code are now redundant.

The design of this web service can be described in one sentence as follows: “Take a shapefile referenced by a unique URI and build a web service that can return the vector data for any of its map tiles based on a quad tree hierarchy”. While shapefiles are mentioned here, the idea can be extended to any form of spatial data. The key to performance is the same as for the image tilers, where the first request for a new shapefile blocks all other load requests until it is loaded into the circular buffer, re-

5_{Project: GenESiS, ‘Generative E-Social Science’ ESRC RES-149-25-1078.} 6_{MapTubeV is named for ‘V’ meaning vector tiler.}

projected if necessary and indexed to allow for fast envelope tests. The amount of time taken to download the remote file to the local staging area can not be controlled, so the reprojection task is the next obvious candidate for optimisation. In the code on GitHub, the ‘MercatorProjection’ class performs the reprojection using ProjNet and the standard GeoAPI interfaces. It was discovered early on that, while extracting all the points from a geometry collection, reprojecting and replacing the points is a simple and effective method, it can also be exceptionally slow for complex geometries. This is because the GeoAPI ‘Coordinates’ are stored internally for every ‘multi’ feature and numbered geometry. This means that extracting and replacing coordinates individually, or as a block, requires walking the ‘GeometryCollection’ hierarchy, which takes time. The recursive implementation used in the code is at least an order of magnitude faster, which is crucial to the vector tiler implementation. The naive implementation has been left in the code base as ‘MercatorProjection.ReprojectOldAndSlow()’ to enable comparisons to be made. Depending on performance tests, any future improvements are likely to come from increased parallelism, either on the CPU or GPU.

The data flow diagram for the system is shown in figure 5.11, with algorithm 3 listing the processing steps involved. Breaking the system down into basic design patterns, the system is built with a file cache, circular buffer and a library to create vector tiles from a tile bounding box and feature data source. This then forms a crucial architectural element in a distributed WebGIS system. A WebGL enabled browser can now use the MapBox GL JS library to load a shapefile directly by specifying the MapTubeV service as the data source. Taking this a step further, the MapBox code has been modified to include aspatial data attached to the vector data source and ‘late joined’ with an area key on the point of loading into the browser. This enables the vector tiles to be re- used with different datasets, so, for example, with the 2011 Census at MSOA level, the vector tiles containing the MSOA boundaries can be re-used for every one of the Census tables. This makes for an efficient system for caching boundary data and builds into a web based exploratory GIS system.

The MapTubeV vector tiler code is available on GitHub at the following address: https:// github.com/ maptube/ MapTubeV.

5.1. Example 1: Data Exploration and Web GIS 193

Figure 5.11: Data flow diagram for the MapTubeV system showing the tile requester, caching, building and data staging systems.

Algorithm 3 MapTubeV Vector Tiler

Require: U RI, location of shapefile on the Internet

Require: ZXY , tile code Z (zoom level), X and Y numbers uniquely identifying a map tile Require: V ectorT ileCache, file cache of vector tiles keyed by U RI and ZXY

Require: F eatureBuf f er, circular buffer of feature data keyed by U RI

1: if Tile ZXY for U RI is in V ectorT ileCache then

2: tile ← cached tile from V ectorT ileCache

3: return tile

4: else

5: if Dataset U RI not in F eatureBuf f er then

6: Download .shp, .dbf and .prj files from U RI and stage locally

7: Reproject shapefile into Spherical Mercator

8: Store reprojected features in F eatureBuf f er

9: end if

10: envelope ← ZXY tile code converted into geographic bounding envelope

11: f eatures ← all features intersecting envelope from F eatureBuf f er for U RI

12: tile ← new vector tile

13: for all f in f eatures do

14: clip f to envelope

15: simplify f to appropriate scale for Z

16: add f to tile

17: end for

18: return tile