[gdal-dev] Vector Tiles in OGR

[Even Rouault]

Hi Stefan,

> P.S. @Even: Any news on a GDAL/OGR MVT reader?

No activity on this front as far as I know. There was a possible funding opportunity recently 
for a project that would have involved integating such a driver with QGIS, but the odds for it 
to come true seems to be very low according to the latest updates I got.
And your plugin might actually solve the needs of this project !

Quick question: from my test of the plugin, I see it converts the whole mbtiles and optionnaly 
merges geometry chunks of the same feature spread over several tiles into a single 
geometry, right ? In the preliminary discussions for the project I mentionned, it was not clear 
if there was a need for doing just a decoding & rendering of tiles that intersect the window of 
interest (could make sense if using very large mbtiles or using remote tiles), instead of a 
whole mbtiles conversion. Partial decoding, with merging of the tiles intersecting the 
window of interest, seems to be a bit at odds with the (implicit ?) assumptions of the QGIS 
vector layers that assume that the geometry of a feature will always be the same when it is 
returned, and not clamped to the window of interest.

Even

> 
> 2016-01-31 23:22 GMT+01:00 Flippmoke <flippmoke at gmail.com>:
> > All,
> > 
> > The first thing that is going to be required likely is a good generic c++
> > library for encoding and decoding vector tiles IMO.
> > 
> > I have spent a lot of time working on developing the mapnik vector tile
> > library to be a solid implementation, especially around all the work done
> > for 2.0 of Mapbox vector tile specification. I would love to eventually
> > help make this a generalized implementation so that it is portable to a
> > library like GDAL.
> > 
> > We have talked about doing something like this at Mapbox but will require
> > a good deal of time, so it hasn't been pushed forward yet. The other
> > issues that come to mind to me is that some of the libraries that mapnik
> > vector tile depends upon most likely need good custom implementations if
> > we wanted to make it more generic.
> > 
> > The reason for this is that I would prefer for it to be a header only
> > library with no dependencies. Adding more dependencies for GDAL seems
> > like it could be a mess.
> > 
> > Blake Thompson
> > 
> >> On Jan 31, 2016, at 10:10 AM, Stefan Keller <sfkeller at gmail.com> wrote:
> >> 
> >> Hi Petr, Blake, Even and everybody
> >> 
> >> I'm (besides Petr) the other maintainer of OSM2VectorTiles.
> >> I'd already asked Even a similar question.
> >> I'm advising now an intern to implement such a MVT Vector Tiles reader
> >> client in Python if possible as part of a QGIS plugin.
> >> And I'm interested not to do redundant implementations.
> >> Are there any news on this matter?
> >> 
> >> :Stefan
> >> 
> >> Prof. at HSR and leader of Geometa Lab
> >> 
> >> @Even: Regarding OGR MVT development can you send to me (directly) a
> >> contact name of the group which won the bidding?
> >> 
> >> 2016-01-06 15:24 GMT+01:00 Petr Pridal <petr.pridal at klokantech.com>:
> >>> Hi everybody,
> >>> 
> >>> thanks for the comments. Regarding the technical details:
> >>>> Each Tile is its own discrete dataset therefore the hardest part would
> >>>> be
> >>>> merging of features into the original features across tiles. You could
> >>>> use
> >>>> some complicated merging technique, but that could be very expensive.
> >>> 
> >>> The driver could require "id" parameter, which specifies name of an
> >>> attribute with unique identifier on the features shared across the
> >>> tiles.
> >>> Both MapBox vector tiles and OSM2VectorTiles tiles have an unique
> >>> non-zero
> >>> "osm_id" in place. The first version of driver could read only features
> >>> with such ID. The identifier does not have to be always filled, but
> >>> often it is, especially in deeper zoom levels derived purely from
> >>> OpenStreetMap - but yeh, a completely general stitching would be much
> >>> harder.
> >>> 
> >>> The clipping + merging of shapes itself can be implemented with
> >>> underlaying
> >>> GEOS library functions.
> >>> 
> >>> BTW It is possible to examine vector tiles data in pure JavaScript X-Ray
> >>> viewer (no WebGL support on browser required) made in OpenLayers3:
> >>> http://klokantech.github.io/ol3-sandbox/vector/xray.html
> >>> 
> >>> or with WebGL-enabled webbrowser with higher performance MapBox GL JS
> >>> powered X-Ray:
> >>> http://klokantech.github.io/mapbox-gl-js-offline-example/xray.html
> >>> 
> >>> A debug viewer for each vector tile (made in OL3) decoded in pure
> >>> JavaScript:
> >>> http://klokantech.github.io/ol3-sandbox/vector/tile-inspector.html
> >>> 
> >>> The OGR driver could be also practical for the unsimplified /
> >>> ungeneralised
> >>> MBTiles with OSM data available at:
> >>> http://osmlab.github.io/osm-qa-tiles/
> >>> 
> >>>> If you wanted to simply view vector tile data it could get confusing as
> >>>> well since most vector tiles need a buffer when they are used for
> >>>> visualization programs. This is important for things like labeling on
> >>>> maps
> >>>> etc. Therefore, you could get a large amount of overlapping data on
> >>>> tiles if you loaded them all in at once.
> >>> 
> >>> Clipping on border of each tile must be applied before stitching the
> >>> vector
> >>> features together  - so the buffer is removed. Buffer is there only for
> >>> visualisation and labeling.
> >>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170417/3932580a/attachment-0001.html>