Hi, The Teamengine report is not most easy to interpret, but the test must be testing this part of the standard:
For WGS 84 longitude/latitude the bounding box is in most cases the sequence of minimum longitude, minimum latitude, maximum longitude and maximum latitude. However, in cases where the box spans the anti-meridian the first value (west-most box edge) is larger than the third value (east-most box edge). Example 6. The bounding box of the New Zealand Exclusive Economic Zone The bounding box of the New Zealand Exclusive Economic Zone in WGS 84 (from 160.6°E to 170°W and from 55.95°S to 25.89°S) would be represented in JSON as [ 160.6, -55.95, -170, -25.89 ] and in a query as bbox=160.6,-55.95,-170,-25.89. -Jukka- Lähettäjä: Seth G <[email protected]> Lähetetty: torstai 19. lokakuuta 2023 14.37 Vastaanottaja: Rahkonen Jukka <[email protected]>; MapServer Devs <[email protected]> Aihe: Re: [MapServer-dev] OGC API Features: some failures in CITE tests Hi Jukka, With regards to: * 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 Do you have a reference to why this should be HTTP 200 (Success)? If the bbox parameter is invalid then it is treated as other bad parameter settings and return HTTP 400 e.g. https://demo.mapserver.org/cgi-bin/mapserv/localdemo/ogcapi/collections/countries/items?f=html&limit=10&offset=a The spec also refers to HTTP 400 - https://docs.ogc.org/is/17-069r3/17-069r3.html#query_parameters Or have I misunderstood the issue? Seth -- 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 [email protected]<mailto:[email protected]> https://lists.osgeo.org/mailman/listinfo/mapserver-dev
_______________________________________________ MapServer-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/mapserver-dev
