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 <flippm...@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 <sfkel...@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.pri...@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. > >>>
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
