MVT driver: Changes to support loading MVT endpoint in QGIS

[jpalmer]

It would be good to improve the MVT driver so it's possible to add a TileJSON endpoint in QGIS via OGR and have the driver automatically load the correct zoom level for the given map canvas scale (as WMTS and TMS drivers do). At the moment only specific zoom levels can be loaded.

Maybe something like this using the TileJSON metadata file:

ogrinfo -so -al MVT:http://localhost:32769/data/parcels.json

and then the tiles URL {z}/{x}/{y} variables in the metadata file can be substituted per OGR API or OGR tool request. The vector_layers key with the metadata file can also be used to advertise the layers that are possible for all zoom levels within the TileJSON endpoint.

[Even Rouault]

The problem is that the vector model in OGR and QGIS is fundamentally not zoom-level oriented, contrary to the raster one.

For the MBTILES driver, there's the ZOOM_LEVEL_AUTO=YES open option (or the MVT_ZOOM_LEVEL_AUTO=YES configuration option) that accomplishes what you mention here, but this results in some inconsistant behaviour. For example, if the max zoom level is 10 and you display at zoom level 8 and select an object with the Identify tool, this will be the feature at zoom level 10 which will be selected.

So either the OGR and QGIS abstractions should be enhanced to have a concept of zoom level that can be changed dynamically.

Or to use the current abstractions, QGIS would open as many datasets as there are zoom levels and configure minscale/maxscale rules to switch between those datsets.

[jpalmer]

For the MBTILES driver, there's the ZOOM_LEVEL_AUTO=YES open option (or the MVT_ZOOM_LEVEL_AUTO=YES configuration option) that accomplishes what you mention here, but this results in some inconsistant behaviour. For example, if the max zoom level is 10 and you display at zoom level 8 and select an object with the Identify tool, this will be the feature at zoom level 10 which will be selected.

Is this also possible with just the MVT driver with a URL endpoint? Seems pretty good solution, and in many cases doing the object identify ok the max zoom is ok. I think this identify behaviour will however be a problem if the layers attributes change between the zoom level and the max layer.

So either the OGR and QGIS abstractions should be enhanced to have a concept of zoom level that can be changed dynamically.

In the case of TileJSON endpoint I think only web mercator tilegrids schemas are support. So in that case wouldn't the QGIS scale be enough to pass to the OGR driver as an config option? The scales could then be mapped zoom level. Beyond web mercator then it wouldn't work for TileJSON, but metadata link Esri's vector tile service (​https://developers.arcgis.com/rest/services-reference/vector-tile-service.htm), or WMTS (as geoserver does)

[jpalmer]

Or to use the current abstractions, QGIS would open as many datasets as there are zoom levels and configure minscale/maxscale rules to switch between those datsets.

Do you mean open dataset within all zoom levels? If so then yes I think this is an ok approach.

[Even Rouault]

Is this also possible with just the MVT driver with a URL endpoint?

Not at this time

So in that case wouldn't the QGIS scale be enough to pass to the OGR driver as an config option?

Could be done, also somewhat hacky

Do you mean open dataset within all zoom levels?

I was thinking to having a QGIS layer for the OGR dataset "MVT:http://foo/0", another one for e OGR dataset "MVT:http://foo/1", etc...

[jpalmer]

I was thinking to having a QGIS layer for the OGR dataset "MVT:http://foo/0", another one for e OGR dataset "MVT:http://foo/1", etc...

Ok I understand now. What about querying the TileJSON metadata file using the vector_layers extension to determine what layers exist and at what scales for the whole cache at all zoom levels? e.g:

"vector_layers":[  
      {  
         "id":"parcels",
         "description":"",
         "minzoom":0,
         "maxzoom":8,
         "fields":{  
            "appellation":"String",
            "id":"Number",
            "parcel_intent":"String"
         }
      }
   ],
   etc..

OGR could then report those layers? Obviously no data would be returned for a zoom level that doesn't contain that layer.

Really what is needed here is a more mature standard approach to serving vector tiles and styles with multiple projections. I think WMTS 2.0 needs to deal with this! Any get capabilities responses could return the tilegrid information, vector tile services (or raster + vector tile services as package) and the layers of information and applicable scales held within those services.

[tomchadwin]

Speaking as an interested non-expert, have the additions to the metadata section in the recent mbtiles spec v1.3 helped at all?

"The metadata table SHOULD contain [...]: minzoom, maxzoom" (​https://github.com/mapbox/mbtiles-spec/blob/master/1.3/spec.md#schema)

"In a future revision of this specification, the bounds, minzoom, and maxzoom rows of the metadata table will be mandatory." (​https://github.com/mapbox/mbtiles-spec/blob/master/1.3/spec.md#future-directions)

How about the new Vector tileset metadata section?

"Each layer object MAY also contain the following key-value pair[s]: minzoom, maxzoom"(​https://github.com/mapbox/mbtiles-spec/blob/master/1.3/spec.md#vector-tileset-metadata)

[Even Rouault]

Ticket retargeted after milestone closed

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.