[gdal-dev] Vector Tiles in OGR

Stefan Keller sfkeller at gmail.com
Mon Jan 29 07:21:13 PST 2018


2018-01-29 14:51 GMT+01:00 Even Rouault <even.rouault at spatialys.com>:

> Yeah, I didn't really found a specification for those. Just my experiments
> with various MBTiles / directory of tiles found in the wild, and those I
> produced with tippecanoe.

OGR has quite some impact and the announced availability of an MVT
reader and writer should be another motivation to update the MBTiles
and TileJSON spec. for MVT specs. as I suggested here [1]
(sorry Blake for pushing; don't take it personally. I'm really
frustrated by Mapbox not to update them since years :-().

>> Q3: Is this metadata.json accessible from an GDAL/OGR Python binding?
> The open option you mean ? Yes:
> ...
>> 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?
>
> Manually. By iterating on the OGR layer feature definition.

Do you suggest to simply use the MVT reader and the current OGR (or
Fiona) YPI in order to generate a single metadata.json file for all
zoom levels?

> Are there use cases where metadata.json is missing ?

Yes: A GeoServer-Extension, tilemaker, t-rex and ArcGIS-Pro can write
MVT compatible vector tiles to a directory (they say).
All these are working with JS lib like Leaflet just by assigning a
connection URL in the form {z}/{x}/{y}.pbf.

Now there are SW which need some metadata like layer names, their
fields, the geometry type, and the layer extent (see [1] for some
related issues):
Your OGR MVT reader?, t-rex tileserver, maptiler, my Vector Tiles
Reader QGIS plugin and even mbview and Mapbox Studio itself.

@Blake/Petr: I assume mbutil does not generate metadata.json in case
it does not exist?

:Stefan

[1] https://github.com/mapbox/tilejson-spec/issues/14#issuecomment-361065531




2018-01-29 14:51 GMT+01:00 Even Rouault <even.rouault at spatialys.com>:
> On lundi 29 janvier 2018 10:21:04 CET Stefan Keller wrote:
>
>> 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.
>
>
>
> Yeah, I didn't really found a specification for those. Just my experiments
> with various MBTiles / directory of tiles found in the wild, and those I
> produced with tippecanoe.
>
>
>
>>
>
>> > 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?
>
>
>
> Yes. Potentially with a limitation on the number of tiles to explore with
> the TILE_COUNT_TO_ESTABLISH_FEATURE_DEFN open option
>
>
>
>> 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?
>
>
>
> Not sure to understand your question. If you use JSON_FIELD=YES, it means
> that the driver will not try to establish a full schema that fit for all
> features, but just put the key/value pair it finds for each feature in a
> JSon dictionnary. So there's no metadata.json to write.
>
>
>
>> Q3: Is this metadata.json accessible from an GDAL/OGR Python binding?
>
>
>
> The open option you mean ? Yes:
>
> https://github.com/OSGeo/gdal/blob/trunk/autotest/ogr/ogr_mvt.py#L69
>
>
>
>> 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?
>
>
>
> Manually. By iterating on the OGR layer feature definition. Are there use
> cases where metadata.json is missing ?
>
>
>
>
>
> Note: I'm going to work on the write side of the drivers in the coming
> weeks.
>
>
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com


More information about the gdal-dev mailing list