add CITE setup for Tiles

[tomkralidis]

Our CITE configuration defines all standards which we support/are compliant to/are an RI for. We need to add an appropriate setup for OGC API - Tiles (perhaps https://github.com/geopython/demo.pygeoapi.io/blob/master/services/pygeoapi_master/local.config.yml#L128-L164).

• [x] update compliance wiki page
• [x] update CITE README in codebase
• [x] update CITE demo config
• [ ] verify demo.pygeoapi.io/cite is then compliant

[tomkralidis]

@doublebyte1 for review:

• compliance wiki page
• CITE demo config
• CITE README in codebase

[doublebyte1]

I think we need to wait for the CITE team to sort out this issue: https://github.com/opengeospatial/ets-ogcapi-tiles10/issues/28

[tomkralidis]

@doublebyte1 @PascalLike I tested both https://demo.pygeoapi.io/cite and a local pygeoapi build (based on the setup / instructions documented in https://github.com/geopython/pygeoapi/wiki/OGCCompliance), against a local master branch build of the OGC API - Tiles ETS with the following (2) failures:

Conformance class: Core: Requirement 5A states that a successful execution of the tile operation with content SHALL be reported as a response with an HTTP status code 200. However the respose code was 404.

Conformance Class: Dataset Tilesets: Requirement 11 states that if the API has a mechanism for exposing root resources (e.g. a landing page) the API SHALL advertise at least one URI to retrieve a tilesets list provided by this service with a link having a rel value: http://www.opengis.net/def/rel/ogc/1.0/tilesets-vector http://www.opengis.net/def/rel/ogc/1.0/tilesets-map or http://www.opengis.net/def/rel/ogc/1.0/tilesets-coverage. However the landing page did not have any such links.

Any idea?

[doublebyte1]

Hi @tomkralidis!

@doublebyte1 @PascalLike I tested both https://demo.pygeoapi.io/cite and a local pygeoapi build (based on the setup / instructions documented in https://github.com/geopython/pygeoapi/wiki/OGCCompliance), against a local master branch build of the OGC API - Tiles ETS with the following (2) failures:

Conformance class: Core: Requirement 5A states that a successful execution of the tile operation with content SHALL be reported as a response with an HTTP status code 200. However the respose code was 404.

Would it be possible to send the urls that are triggering the 404 error?

Conformance Class: Dataset Tilesets: Requirement 11 states that if the API has a mechanism for exposing root resources (e.g. a landing page) the API SHALL advertise at least one URI to retrieve a tilesets list provided by this service with a link having a rel value: http://www.opengis.net/def/rel/ogc/1.0/tilesets-vector http://www.opengis.net/def/rel/ogc/1.0/tilesets-map or http://www.opengis.net/def/rel/ogc/1.0/tilesets-coverage. However the landing page did not have any such links.

Any idea?

I think we are hitting this issue again. pygeoapi does not claim to offer any dataset tilesets and thus it should be not tested for that.

[tomkralidis]

Would it be possible to send the urls that are triggering the 404 error?

• GET /collections/COLLECTION/tiles/WebMercatorQuad/0/0/0
• GET /collections/COLLECTION/tiles/WebMercatorQuad/0/2147483647/2147483647

[doublebyte1]

• 0/2147483647/2147483647

I am assuming you are testing this collection on the cite instance.

In that case, the url template would be:

https://demo.pygeoapi.io/cite/collections/lakes/tiles/WebMercatorQuad/{tileMatrix}/{tileRow}/{tileCol}?f=pbf

This should trigger a 200 response:

https://demo.pygeoapi.io/cite/collections/lakes/tiles/WebMercatorQuad/0/0/0?f=pbf

curl -I https://demo.pygeoapi.io/cite/collections/lakes/tiles/WebMercatorQuad/0/0/0\?f\=pbf

HTTP/2 200
access-control-allow-origin: *
content-language: en-US
content-type: pbf
date: Thu, 22 Aug 2024 16:04:01 GMT
server: gunicorn
x-powered-by: pygeoapi 0.18.dev0
content-length: 2960

In the other case, a 404 is correct, because that tile does not exist.

https://demo.pygeoapi.io/cite/collections/lakes/tiles/WebMercatorQuad/0/2147483647/2147483647?f=pbf

curl -I https://demo.pygeoapi.io/cite/collections/lakes/tiles/WebMercatorQuad/0/2147483647/2147483647\?f\=pbf

HTTP/2 404
access-control-allow-origin: *
content-language: en-US
content-type: pbf
date: Thu, 22 Aug 2024 16:04:43 GMT
server: gunicorn
x-powered-by: pygeoapi 0.18.dev0
content-length: 97

According to section 7.17 of the Standard (Error conditions):

If the path parameter values tileMatrix, tileRow, tileCol for a tile request are out-of-range (outside the tile matrix set or tile matrix set limits of the resource), the HTTP response SHALL use a status code 404 or a 400. The response can also contain an exception report.

@tomkralidis let me know if I'm missing something here.

[tomkralidis]

@doublebyte1 for the first issue, it was a copy/paste error on my part (I've updated https://github.com/geopython/pygeoapi/wiki/OGCCompliance#ogc-api---tiles accordingly).

For the second 404, this is maybe not an ETS error (intentionally triggering a 404).

The remaining issue thus remains related to clarification of https://github.com/opengeospatial/ets-ogcapi-tiles10/issues/28

[doublebyte1]

@doublebyte1 for the first issue, it was a copy/paste error on my part (I've updated https://github.com/geopython/pygeoapi/wiki/OGCCompliance#ogc-api---tiles accordingly).

For the second 404, this is maybe not an ETS error (intentionally triggering a 404).

The remaining issue thus remains related to clarification of opengeospatial/ets-ogcapi-tiles10#28

@tomkralidis @dstenger I opened a new issue here. https://github.com/opengeospatial/ets-ogcapi-tiles10/issues/30 It is the same issue (the test suite expecting Dataset tilesets) on a different requirement (11),

[tomkralidis]

@doublebyte1 @dstenger FYI I now tested with the following setup:

• local pygeoapi build
• local branch build of the OGC API - Tiles ETS, but this time building against the issue#13 branch (which is not yet merged per PR https://github.com/opengeospatial/ets-ogcapi-tiles10/pull/29).

With the above setup, tests fully pass and the Dataset tileset Conformance Class skipped per the pending the PR.

This means that once the PR is merged and we have an associated release of the ETS, pygeoapi should continue to be compliant.

[tomkralidis]

I tested pygeoapi master against CITE beta (2024-12-08) and there is now a single (new) error:

None of the operationIDs matched those specified by Requirement /req/oas30/operation-id and Table 11

Looks like this requirement was added to OATiles CITE ETS recently. I've put forth a fix at #1863 for review/comment.

[doublebyte1]

• demo.pygeoapi.io/cite

@tomkralidis I tried to run the dockerized version of the test suite, but failed with this error: https://github.com/opengeospatial/ets-ogcapi-tiles10/issues/37

[tomkralidis]

FYI I tested both https://demo.pygeoapi.io/cite and https://demo.pygeoapi.io/master master against CITE beta (2024-12-21) and all previous failures are now gone (15 passed, 1 skipped, 0 failed) given #1863

@doublebyte1 :

@tomkralidis I tried to run the dockerized version of the test suite, but failed with this error: opengeospatial/ets-ogcapi-tiles10#37

Looks like the issue you have encountered is unrelated. I think we are okay to close this issue since the pygeoapi CITE demo now passes again?