Hi Even Great news about this MVT reader!
The docs [1] says: > The MVT driver only uses the "json" key to retrieve the layer names, their > fields and the geometry type, and the "bounds" key for the layer extent. I just wanted to point you to the spec. discussion of MBTiles and TileJSON metadata [2] and I hope the SW keeps aligned with it. > If this file cannot be found, the layer schema is established by scanning the > features of the tile(s). Q1: So the reader scans all tiles on the one given zoom level and generates an internal metadata structure for that zoom level? Q2: Option JSON_FIELD=YES says "put all attributes as a serialized JSon dictionary"; Can a metadata.json file also be written to disk in case it was generated? Q3: Is this metadata.json accessible from an GDAL/OGR Python binding? Q4: Ultimately I'd like to get a metadata.json (TileJSON compatible) from the above mentioned MVT input for all zoom levels (at least for the json key): How could I achieve this? :Stefan [1] http://gdal.org/drv_mvt.html#metadata_json [2] https://github.com/mapbox/tilejson-spec/issues/14#issuecomment-361065531 2018-01-23 13:29 GMT+01:00 Even Rouault <even.roua...@spatialys.com>: > On mardi 23 janvier 2018 13:10:30 CET Jaak Laineste wrote: > >> Hey, > >> > >> I read the drv doc, it was not completely clear how OGR handles exactly > >> multi-resolution specifics; as OGR data model does not really “support” > >> multi-resolution vector in data model level AFAIK. > > > > Indeed, there's no particular handling of multi-resolution in the MVT > driver. Meaning it is the responsibility of the user to open the zoom level > it is interested in. > > > > ( For the MBTiles driver, I've added a ZOOM_LEVEL_AUTO=YES open option: > > """Whether to auto-select the zoom level for vector layers according to the > spatial filter extent. Only for display purpose. Defaults to NO""") > > > >> > >> I guess it works in this way: > >> a) if you set Z= option, e.g. Z=10, then it takes data for zoom 10. > > > > No, X, Y, Z open options are only useful if you point to a single .pbf / > .mvt file whose path + name doesn't contain any hint on the tile coordinate. > > > > To point to a tileset at a particular zoom level, you need to open > "directory/{zlevel}" > > > >> b) in other cases it extracts data for all zooms, which means with typical > >> multi-zoom/resolution tileset you end up with up to N (=number of zoom > >> levels) geometries per object. If geometries would have generated field >> for > >> tile address (xyz) then consumer can decide which copy to be used, > >> otherwise it may become quite unusable mess. > > > > No, only one zoom level is opened. See above > > > >> > >> p.s. there is no geometry merging across tiles, right? > > > > Yep, that's what i meant with > > """Note: When opening a zoom level of a tileset, the driver will make no > effort of stiching together geometries for features that overlap several > tiles.""" > > > >> I imagine this to be > >> useful either based on coordinate connections, and/or unique object id > >> field. > > > > Geometry merging could potentially be done, but it was left aside for now, > because it can involve huge processing time. Imagine in the worst case, you > have a single polygon covering the whole world at zoom level 15: to read it, > you will need to merge the 2^30 tiles ... > > So geometry merging should probably be an option not enabled by default, and > used together with reasonable spatial filter. > > > > Even > > > > > > -- > > Spatialys - Geospatial professional services > > http://www.spatialys.com _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
