[vector-tiles] RPC and MVT Layers

[Alexander W. Rolek]

Roy -

If I understand what you're saying, instead of expecting a RPC data
provider to return a MVT Layer, just fetch MVT Tiles from already
implemented providers, decode them and extract whatever you want for your
mashup. I like this idea. The pros and cons I see:

Pros
- Does not require any additional implementation from an MVT server. This
is pretty big as MVT servers are already in the wild.
- User could easily define which layers they want to extract so they don't
have to merge entire tiles together.

Cons
- Possibly unreliable if a data provider changes the name of a layer in a
tile or removes that layer. This could also happen when returning MVT
Layers, but the explicit implementation of the MVT Layer response might
result in more integrity from the data provider.
- Larger payloads.
- As you mentioned, this might result in layer name collisions during
merging which could cause more complex server config rulesets.

Thoughts on other pros / cons?


On Tue, Sep 13, 2016 at 5:38 AM, Rory McCann <rory at technomancy.org> wrote:

> 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
> >
>
>


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