[gdal-dev] Vector Tiles in OGR

[Stefan Keller]

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.rouault at 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