Read Tileset information from OGC API Tiles

[doublebyte1]

ogrinfo should be able to read the information about a vector tile dataset, when pointed to the collection page.

This works as expected:
./ogrinfo -oo API=TILES "OGCAPI:https://maps.gnosis.earth/ogcapi/collections/Daraa:AgricultureSrf"
INFO: Open of OGCAPI:https://maps.gnosis.earth/ogcapi/collections/Daraa:AgricultureSrf' using driver OGCAPI' successful.

However, this does not work

./ogrinfo -oo API=TILES "OGCAPI:https://demo.ldproxy.net/daraa"
ERROR 1: API TILES requested, but not available
ERROR 1: API TILES requested, but not available
ogrinfo failed - unable to open 'OGCAPI:https://demo.ldproxy.net/daraa'.

Despite the dataset being advertised here:

    "rel" : "http://www.opengis.net/def/rel/ogc/1.0/tilesets-vector",
    "title" : "Access the data as tiles",
    "href" : "https://demo.ldproxy.net/daraa/tiles"

In the case of gnosis, the links to the actual data are already advertised in this page, but is that required?

         "rel" : "item",
         "type" : "application/vnd.mapbox-vector-tile",
         "title" : "AgricultureSrf (individual feature as Mapbox Vector Tile)",
         "href" : "/ogcapi/collections/Daraa:AgricultureSrf/items/{featureId}.mvt",
         "templated" : true

I think that the client should follow the link to the tileset metadata on the next page, instead of giving up here.

@rouault @jerstlouis @cportele

Operating system

Ubuntu 22.04.2 LTS

GDAL version and provenance

GDAL 3.8.0dev-23d309f3f4, released 2023/05/02 (debug build)

[jerstlouis]

Note I get the same result pointing GDAL directly to the collection (which also has a tilesets-vector link) with:

ogrinfo -oo API=tiles "OGCAPI:https://demo.ldproxy.net/daraa/collections/AgricultureSrf"

Neither works, but the server responses are fine.

In the case of gnosis, the links to the actual data are already advertised in this page, but is that required?

That is an optional thing for requesting a single Feature ( /items/{featureId} ), so unrelated to OGC API - Tiles (despite the MVT option there -- probably it should not even be offered as MVT since there no hint as to what the extent of that MVT is).

[jerstlouis]

@rouault My hunch is that GDAL is looking for a "type": "application/json" for the tilesets-vector rel and does not find one.

As a general rule for OGC APIs, if a single URI supports multiple formats using HTTP content negotiation, a single link can be provided without specifying a "type" property, and the client can simply use e.g., Accept: application/json.

e.g., see OGC API - Tiles 8.2.2 Requirement 8 F (about the tiles template, but same idea):

If a tiles link template is specific to a particular format, the link SHALL contain the media type for that format in the “type” property. Otherwise, normal HTTP content type negotiation rules apply (Accept: header).

[doublebyte1]

@jerstlouis @rouault apologies to put this here, but I am unsure whether this is an ogr or pygeoapi issue. This kind of works:

./ogrinfo -oo API=TILES --config CPL_DEBUG ON "OGCAPI:https://demo.pygeoapi.io/master/collections/lakes

But then it fails because it cannot find a link for the tilese on the tiles page:

HTTP: Establish persistent session named 'OGCAPI:0x557993ca9230'.
HTTP: Fetch(https://demo.pygeoapi.io/master/collections/lakes)
HTTP: libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.14
HTTP: Fetch(https://demo.pygeoapi.io/master/collections/lakes/tiles?f=json)
HTTP: Fetch(https://demo.pygeoapi.io/master/collections/lakes/tiles/WorldCRS84Quad?f=json)
ERROR 1: Missing links for tileset
HTTP: Ended persistent session named 'OGCAPI:0x557993ca9230'.
HTTP: Establish persistent session named 'OGCAPI:0x557993ca9230'.
HTTP: Fetch(https://demo.pygeoapi.io/master/collections/lakes)
HTTP: Fetch(https://demo.pygeoapi.io/master/collections/lakes/tiles?f=json)
HTTP: Fetch(https://demo.pygeoapi.io/master/collections/lakes/tiles/WorldCRS84Quad?f=json)
ERROR 1: Missing links for tileset
HTTP: Ended persistent session named 'OGCAPI:0x557993ca9230'.
ogrinfo failed - unable to open 'OGCAPI:https://demo.pygeoapi.io/master/collections/lakes'.

This is the offending tileset:

    "tilesets":[
        {
            "title":"lakes",
            "tileMatrixSetURI":"http://schemas.opengis.net/tms/1.0/json/examples/WorldCRS84Quad.json",
            "crs":"http://www.opengis.net/def/crs/OGC/1.3/CRS84",
            "dataType":"vector",
            "links":[
                {
                    "type":"application/json",
                    "rel":"self",
                    "title":"lakes - WorldCRS84Quad - json",
                    "href":"https://demo.pygeoapi.io/master/collections/lakes/tiles/WorldCRS84Quad?f=json"
                },
                {
                    "type":"text/html",
                    "rel":"alternate",
                    "title":"lakes - WorldCRS84Quad - html",
                    "href":"https://demo.pygeoapi.io/master/collections/lakes/tiles/WorldCRS84Quad?f=html"
                }
            ]
        },

On the links it exposes a JSON self representation and a html alt representations. However, when I look at the gnosis links, I also see this link:

               "rel" : "http://www.opengis.net/def/rel/ogc/1.0/tiling-scheme",
               "type" : "application/json",
               "title" : "WorldCRS84QuadTileMatrixSet definition (as JSON)",
               "href" : "/ogcapi/tileMatrixSets/WorldCRS84Quad"

I have been looking through the OGC 2D TMS spec, but I cannot find the explanation for this. Is this mandatory?

I am on GDAL 3.8.0dev-360a9aea02, released 2023/06/24 (debug build).

[doublebyte1]

I realized that ogr is failing because of something else. The tileset links are missing from the TMS page: https://demo.pygeoapi.io/master/collections/lakes/tiles/WorldCRS84Quad?f=json

[jerstlouis]

@doublebyte1 That response is not at all the 2D Tile Matrix Set and Tileset metadata JSON encoding.

It seems to be TileJSON, although I believe the bounds should be an array, not a string in TileJSON, so probably also invalid for TileJSON 3.0.0.

[doublebyte1]

@jerstlouis Thank You, I am investigating that.

Not related to the error, but it guess it is still useful to have the http://www.opengis.net/def/rel/ogc/1.0/tiling-scheme link relation type to describe the TMS?
I see here it is a requirement: https://docs.ogc.org/is/20-057/20-057.html#toc32

[jerstlouis]

@doublebyte1 Yes, Requirement 8D. That is the most important thing that every tileset metadata needs to include: a link to the 2DTMS definition (regardless of whether it is a custom 2DTMS or a registered one).

[doublebyte1]

Thanks a lot, @jerstlouis ! I address it here: geopython/pygeoapi#1290 👍🏽