In reply to Steven Feldman on Twitter why do i object to vector tile services, it will definitely take more than 140 characters to explain, and then only partially explain.

The statement that i find vector tiles objectionable was triggered by a positive reaction nonetheless to Mapzen’s Vector Tile Service. I’m fascinated to see it serving up GeoJSON according to a tile-based URL scheme like that in use for raster, imagery tiles.

VectorMap District is an underrated Ordnance Survey Open Data project for mid-scale views of maps. You can get it from the OS open data download pages, selecting from a series of National Grid tiles from what may be a horribly familiar image:

The National Grid tiles that we download with clenched teeth today come from grids and scales designed to be read on paper maps.

Registers of Scotland are my employers and they are well known for being some distance from completing a full “cadastral map”, registering the ownership of all land and property in Scotland. Their Geographic Information Systems were probably once pioneering early-adoption when originally designed. But the database systems weren’t strong enough to handle data on more than a county basis, so that’s how the data got distributed amongst systems. Each county stores a set of overlapping tiles of OS data. It’s converted back from modern data format into an archival format the old systems can understand. There is quite a maintenance load involved in this process alone.

When the organisation systems really were paper maps, tiled and scaled to the National Grid, Registers stored its model of land in the form of “parcel books”. Chunks of OS maps, cut up and pasted onto cloth, painstakingly annotated with land ownership where it was registered, with extra copies at different scales describing “Research Areas” where work was ongoing and more than usual was known. The parcel books are beautiful, and in many ways more appropriate to the shared tasks of land registration and research than the GIS systems that are worked with today.

What does this have to do with vector tiles? My point here is that you get artefacts of the limits of the delivery system taking over the delivery system, being unnecessarily preserved. In addition, real problems are being masked by overdelivery of data, with a lot of detail unnecessarily handed over, or a lack of subtlety about what is appropriate scale in a given area. Standards evolved for raster data are a long way distant from what is now possible given the browser capability and bandwidth available in many places today.

Consider the OpenStreetMap API which limits data download to a maximum area or 50000 objects, whichever occurs the sooner. It doesn’t serve up neat square fragments, but sections of longer ways are spilling out the edges of the request. It’s hardly subtle as a regulating mechanism, but it’s effective enough. The query support in Overpass API is much more powerful, and an application of sufficient size is likely to want its own cached store of GeoJSON, not depend on a third-party service for fundamental mapping.

What I would prefer to see than vector tiles is a data generalisation service that would produce the equivalent of products like VectorMap District & Local from OpenStreetMap data, making it all easier to work with at different scales. Clear annotations about what data sources have been subjected to what algorithmic processes. I also want to see clearer integration with QGIS and other open-source desktop tools. And I think these things will make more difference to delivery and to re-use than vector tiles.