[vector-tiles] RPC and MVT Layers

[Alexander W. Rolek]

Greetings OSGeo -

For the last few months I have been working on a MVT server written in Go
called Tegola (http://tegola.io). One of the design goals for Tegola has
been to support multiple data providers (i.e. PostGIS, Geopackage, etc.).
As anyone who works with geospatial data knows, a good chunk of time is
dedicated to the extract, transform and load (ETL) pipeline. For many
situations it's unnecessary to replicate a data layer from a data authority
so you can have it in your own database. This unnecessary data duplication
got us thinking about the possibility of a RPC data provider that would
return MVT Layers instead of MVT Tiles.

The MVT spec basically consists of a Tile, which is made up of Layers,
which are made up of Features. A typical request to a MVT server includes
Z, X and Y values (Slippy map tilenames) with an expected response being a
protocol buffer encoded MVT tile. At a high level, a RPC data provider
would still expect ZXY values in the request, but instead of returning an
encoded MVT Tile it would return an encoded MVT Layer.

With this approach, a MVT server configuration could point to various
remote data providers and make requests for MVT Layers that it would then
combine into a MVT Tile and deliver to the client. This would allow MVT
servers to combine numerous data sources without needing to host the actual
data!

The intent here is to minimize data duplication and fragmentation while
also simplifying data mashups and "getting started" time for MVT servers.

The possibilities are pretty wild and there is still quite a bit to think
through. I'm hoping we can use this thread to discuss the strengths and
weaknesses of the concept.

Looking forward to the discussion.

-- 
Alexander W. Rolek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/vector-tiles/attachments/20160912/695aff4b/attachment.html>