ogcapi update / fixes required

[jerstlouis]

In the context of the OGC Web Mapping Code Sprint.
Related QGIS issue about better supporting OGC API: qgis/QGIS#50296 .
Note: OGC API - Tiles is now published.

Expected behavior and actual behavior.

First part: (out of date OGC API - Maps)

Using gdalinfo and ogrinfo with some OGC API collection end-points offering vector tiles reports a failure, and triggers invalid /map?f=json requests.

For example: OGCAPI:https://maps.gnosis.earth/ogcapi/collections/Daraa:AgricultureSrf

Note that the f= parameter is not specified by most OGC API (EDR being the one exception), and that clients should always use the Accept: header instead to negotiate a particular representation, or follow typed links (that would already contain the f parameter). The href in links must be treated as opaque and the client should not add additional parameters.

The map metadata resource is no longer part of the OGC API - Maps specification. Instead, the landing page and/or collection contains a link to a map resource with the [ogc-rel:map] relation type, which is directly the map itself.

Second part: (out of date OGC API - Tiles)

Furthermore, although both gdalinfo and ogrinfo on a multi-layer collection shows subdatasets in gdalinfo and ogrinfo, QGIS will report a failure to add the layer. It is unclear whether this is a GDAL or QGIS bug... It used to be that QGIS would show a dialog listing available collections to add.

For example: OGCAPI:https://maps.gnosis.earth/ogcapi/collections/Daraa

One change that has been introduced that may be the source of the problem is the separate tilesets-map / tilesets-vector / tilesets-coverage URIs for different tilesets types, as opposed to tilesets for all.

Also please note that the client should support both http:// URIs and CURIEs, e.g. [ogc-rel:tilesets-vector], for TileMatrixSets URIs as well (but see opengeospatial/NamingAuthority#211).

Note that both Map and Coverage collections still seem to work fine in QGIS, e.g.:

https://maps.gnosis.earth/ogcapi/collections/SRTM_ViewFinderPanorama

https://maps.gnosis.earth/ogcapi/collections/blueMarble

Steps to reproduce the problem.

First problem (single layer collection showing FAILURE: in ogrinfo and gdalinfo):

gdalinfo OGCAPI:https://maps.gnosis.earth/ogcapi/collections/Daraa:AgricultureSrf
ogrinfo OGCAPI:https://maps.gnosis.earth/ogcapi/collections/Daraa:AgricultureSrf

Second problem (neither multi-layer nor single layer collection offering vector tiles working in QGIS:

QGIS > Add Layer > Vector > File > OGCAPI:https://maps.gnosis.earth/ogcapi/collections/Daraa ; Add button
or
QGIS > Add Layer > Vector > File > OGCAPI:https://maps.gnosis.earth/ogcapi/collections/Daraa:AgricultureSrf ; Add button.

GDAL version and provenance

GDAL 3.3.1, released 2021/06/28
QGIS version | 3.22.2-Białowieża

[rouault]

and triggers invalid /map?f=json requests.

gdalinfo "OGCAPI:https://maps.gnosis.earth/ogcapi/collections/Daraa:AgricultureSrf" triggers a ERROR 1: <h1>GNOSIS Map Server (OGCAPI) - 406 Not Acceptable</h1><h3>Cannot return map in acceptable format</h3> because of the following snippet in https://maps.gnosis.earth/ogcapi/collections/Daraa:AgricultureSrf JSON response:

      {
          "rel" : "http://www.opengis.net/def/rel/ogc/1.0/map",
          "type" : "application/json",
          "title" : "Maps available for this dataset (as JSON)",
          "href" : "/ogcapi/collections/Daraa:AgricultureSrf/map?f=json"
       }

None of the following requests work:

$ curl "https://maps.gnosis.earth/ogcapi/collections/Daraa:AgricultureSrf/map?f=json"
<h1>GNOSIS Map Server (OGCAPI) - 406 Not Acceptable</h1><h3>Cannot return map in acceptable format</h3>

$ curl "https://maps.gnosis.earth/ogcapi/collections/Daraa:AgricultureSrf/map?f=json" -H "Accept: application/json"
<h1>GNOSIS Map Server (OGCAPI) - 406 Not Acceptable</h1><h3>Cannot return map in acceptable format</h

$ curl "https://maps.gnosis.earth/ogcapi/collections/Daraa:AgricultureSrf/map" -H "Accept: application/json"
<h1>GNOSIS Map Server (OGCAPI) - 406 Not Acceptable</h1><h3>Cannot return map in acceptable format</h

So this is a server error. The OGCAPI driver only follows the href as it is specified.

[jerstlouis]

@rouault Thank you very much for looking into this. Oops, apologies, there is definitely a server error that I am fixing right now -- that JSON link should not be included. I did not expect these to still be present, so that is why I made wrong assumptions about what the client might be doing.

However, there is no longer a separate JSON document describing the map, so the client should not be looking for or negotiating an application/json representation of the map. It should go straight for the PNG, JPEG or GeoTIFF at /map (linked directly from https://maps.gnosis.earth/ogcapi/collections/Daraa:AgricultureSrf).

EDIT: Fixed. -- The ?f=json are gone.

Now it fails with:

gdalinfo -oo API=MAP "OGCAPI:https://maps.gnosis.earth/ogcapi/collections/Daraa:AgricultureSrf" 
ERROR 1: API MAP requested, but not available

Most likely because it is looking for an intermediate JSON map metadata document that no longer exists.

gdalinfo -oo API=TILES "OGCAPI:https://maps.gnosis.earth/ogcapi/collections/Daraa:AgricultureSrf" 
ERROR 1: API TILES requested, but not available

Most likely because it is looking for the old tilesets link relation type instead of the newer ones:

• http://www.opengis.net/def/rel/ogc/1.0/tilesets-vector
• http://www.opengis.net/def/rel/ogc/1.0/tilesets-map
• http://www.opengis.net/def/rel/ogc/1.0/tilesets-coverage

It seems that the reason blueMarble and SRTM_ViewFinderPanorama still worked was because they went through OGC API - Coverages.

[rouault]

The churn in OGC APIs is quite concerning. #6881 tries to fix most issues reported here, but tilesets API don't work due to the JSON output of requests like https://maps.gnosis.earth/ogcapi/tileMatrixSets/WorldCRS84Quad having changed in incompatible way... Sigh^2. Hint for potential contributors: changes should be done in gcore/tilematrixset.cpp

[jerstlouis]

@rouault Thank you very much for the fixes.

Which change(s) do you refer too? I thought we had taken a great amount of care to minimize any changes, and I honestly didnt't think anything was changed about this since our last successful Tiles TIEs with GDAL.

Some things that might have changed since then in that particular file:

• type removed
• identifier -> id
• topLeftCorner -> pointOfOrigin
• bbox removed (it is optional, and for informative purposes only -- it should not be relied upon by clients)
• tileMatrix -> tileMatrices (I think that was already changed though)

[rouault]

Which change(s) do you refer too?

My guess is that GDAL expects the JSON profile of OGC Two Dimensional Tile Matrix Set v1.0 (https://docs.opengeospatial.org/is/17-083r2/17-083r2.html), whereas https://maps.gnosis.earth/ogcapi/tileMatrixSets/WorldCRS84Quad is probably v2 (https://docs.opengeospatial.org/is/17-083r4/17-083r4.html) (weird that the OGC ID of the doc is the same, except the revision number)

[jerstlouis]

@rouault Yes it is definitely 2.0, 1.0 is more or less abandoned.
I was under the impression the TIEs with GDAL we did back in March 2021 were already following the draft v2 though, I might be remembering wrong.

I personally prefer the version URIs like:

http://www.opengis.net/doc/IS/tms/2.0

I wish they did not re-direct to the OGC document numbers.

[jerstlouis]

Also note that a client is not actually required to parse the TileMatrixSet definition and can recognize a registered TileMatrixSet when the tileMatrixSetURI property is present for a tileset either in the list of tilesets or in a particular tileset metadata document.

e.g., when it recognizes http://www.opengis.net/def/tilematrixset/OGC/1.0/WorldCRS84Quad (CURIE: [ogc-tilematrixset:WorldCRS84Quad], GDAL could always parse its own embedded metadata in v1 format, or the one at https://schemas.opengis.net/tms/1.0/json/examples/WorldCRS84Quad.json, or use some other built-in understanding of WorldCRS84Quad.