[vector-tiles] RPC and MVT Layers

[Rory McCann]

Hi,

This is a very interesting idea, and something I had thought would be
good to have.

Rather than inventing a new file format, you could write something which
"merges" vector tiles together. Take all the layers from tile A, then
append (or overwrite) the layer(s) from tile B (etc).

This way you could (say) easily add contour (vector tile) data to a data
source which didn't have that.

On 13/09/16 04:57, Alexander W. Rolek wrote:
> Greetings OSGeo - 
> 
> For the last few months I have been working on a MVT server written in
> Go called Tegola (http://tegola.io <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
> 
> 
> _______________________________________________
> Vector-Tiles mailing list
> Vector-Tiles at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/vector-tiles
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/vector-tiles/attachments/20160913/3f44778e/attachment.sig>