[MapServer-dev] OGC API Features: some failures in CITE tests

Wed Oct 18 04:29:40 PDT 2023

Hi Seth,

The pygeoapi has vendor specific parameters defined in the api
https://demo.pygeoapi.io/cite/openapi?f=json
and it accepts extra parameters https://demo.pygeoapi.io/cite/collections/canada-hydat-daily-mean-02hc003/items?foo=bar. Because that service is named "cite" I believe that it is an OGC compliant way to allow extra parameters.

The issue with invalid geometries comes from testing. The test compares if the returned geometries (or bboxes, I am not sure) really intersect with the bbox that was used in the query. But if the Teamengine compares a bbox polygon that it knows by itself with an invalid polygon from OGCFeat, and ST_Intersects or some equivalent function says No, then the test is failed. I made my own test with those geometries with PostGIS and the result was indeed false, so no intersection=>failure.
I believe that for the standard it is OK if server sends invalid geometries so no need to throw an error on Mapserver side. However, because it is impossible to test geometric relations if geometries are invalid we should use valid data for CITE tests. And also check that data stays valid when converted into GeoJSON. Of course also from user point of view it would be nice to get good geometries. Could we push the output through MakeValid? Does Mapserver have MakeValid?

-Jukka Rahkonen-

Lähettäjä: Seth G <sethg at geographika.co.uk>
Lähetetty: keskiviikko 18. lokakuuta 2023 13.15
Vastaanottaja: Rahkonen Jukka <jukka.rahkonen at maanmittauslaitos.fi>; MapServer Devs <MapServer-dev at lists.osgeo.org>
Aihe: Re: [MapServer-dev] OGC API Features: some failures in CITE tests

Thanks Jukka for testing with the validator.

The extra parameters issue has been discussed before - a major issue is that all cookie parameters are seen as request parameters. See [1] and [2]. I'm not sure if it has been addressed in pygeoapi which is the reference implementation. MapServer also uses parameters for runtime-subsitution so enforcing no extra parameters will break a lot of MapServer workflows.

I think it was suggested adding a "strict" WEB METADATA item that would return a 400 error when extra parameters were encountered - this would allow tests to pass fo a particular server.

What is the service meant to do with invalid geometry such as that polygon - throw an error?

It would be good to open the other items as issues on GitHub to fix.

Seth

[1] https://lists.osgeo.org/pipermail/mapserver-dev/2021-September/016620.html
[2] https://github.com/MapServer/MapServer/pull/6400#issuecomment-936458600

--
web:https://geographika.net<https://geographika.net/> & https://mapserverstudio.net<https://mapserverstudio.net/>
twitter: @geographika

On Wed, Oct 18, 2023, at 9:21 AM, Rahkonen Jukka via MapServer-dev wrote:

Hi,

I used the OGC Teamengine for testing our OGCFeat demo at https://demo.mapserver.org/cgi-bin/mapserv/localdemo/ogcapi.

The validator found a few issues:

  *   Wrong http status code: returns 400, should be 200

https://demo.mapserver.org/cgi-bin/mapserv/localdemo/ogcapi/collections/countries/items?bbox=177.0000000%2C65.0000000%2C-177.0000000%2C70.0000000

  *   Some tests fail because the service returns invalid geometries. Mapserver actually works right but because of invalid topology the validator fails. For example a geometry of the France multipolygon, somewhere near the French Guiana is invalid due to duplicated vertices at  POINT (-52.939657 2.124858). The BBOX in the test was BBOX= -1.5000000,50.0000000,1.5000000,53.0000000. There are other similar geometries showing self-intersection.
  *   If query contains an unknown parameter then our server sends data, but it should error out and send a http 400 error.

Test request: https://demo.mapserver.org/cgi-bin/mapserv/localdemo/ogcapi/collections/ocean-labels/items?unknownQueryParameter13515=1

  *   The Content-Crs header is missing when the request is using the default crs. Test query: https://demo.mapserver.org/cgi-bin/mapserv/localdemo/ogcapi/collections/ocean/items?f=json

I have looked at the extra parameter thing from the standard and from the discussions in the OGC GitHub. Notes from the research:

The server SHALL respond with a response with the status code 400, if the request URI includes a query parameter that is not specified in the API definition. For omitting unknown "vendor specific" parameters is must be defined in the API as

in: query

name: vendorSpecificParameters

schema:

type: object

additionalProperties: true

style: form

If a server wants to support vendor specific parameters, these have to be explicitly declared in the API definition. If OpenAPI is used to represent the API definition, a capability exists to allow additional parameters without explicitly declaring them. That is, parameters that have not been explicitly specified in the API definition for the operation will be ignored.

With minor changes Mapserver could get the certificates for OGC API Features Core and CRS. But I wonder what to do with the demo service. The server that is used for the CITE tests must be available online. We could try to fix the existing Natural Earth data and service so that it sends topologically valid geometries. Another option would be to set up another service instance for CITE tests with some known valid datasets.

-Jukka Rahkonen-
_______________________________________________
MapServer-dev mailing list
MapServer-dev at lists.osgeo.org<mailto:MapServer-dev at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/mapserver-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20231018/0bff0340/attachment-0001.htm>