<div dir="ltr"><div style="font-size:12.8px">Greetings OSGeo - </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">For the last few months I have been working on a MVT server written in Go called Tegola (<a href="http://tegola.io/" target="_blank">http://tegola.io</a>). 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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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!</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">The intent here is to minimize data duplication and fragmentation while also simplifying data mashups and "getting started" time for MVT servers.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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. <br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Looking forward to the discussion.</div><div><br></div>-- <br><div class="gmail_signature">Alexander W. Rolek<br></div>
</div>