Part 1 ATS / ETS: Missing antimeridian test?

[jerstlouis]

While working on CQL2 Spatial Operators, I am realizing that /collections/cql2-test:ne_110m_admin_0_countries/items?bbox=150,-90,-150,90 should probably be returning more than only Antarctica.

It does not seem that CITE/TeamEngine test was able to detect that problem in our implementation.

Although the text immediately before Example 6 about New Zealand talks about the antimeridian bounding boxes, the Requirement 23 /req/core/fc-bbox-response does not have any specific clauses about it.

The Abstract Test 19 in turn does not say anything about it, and this translates in the ETS not testing this properly.

Might be related to https://github.com/opengeospatial/ets-ogcapi-features10/issues/187 that mentioned a test that used to be Abstract Test 13.

There were also other problems not detected, where more features than expected were being returned where the bounding box of the geometry would intersect, but not the actual geometry (the ATS / ETS could actually really check that all returned feature geometries do intersect the requested bounding box).

[cportele]

Yes, there is more than Antarctica in that bbox. Here is what our server returns: https://cql2test.ldproxy.net/ne110m4cql2/collections/ne_110m_admin_0_countries/items?bbox=150,-90,-150,90.

Maybe we should add to /conf/core/fc-bbox-definition that there should also be a test with a bbox that crosses the anti-meridian. However, I do not see, how returning only Antarctica would be detected as an error, because for this the test would have to know the dataset.

The only way to test this would be with a test dataset like in CQL2. Then we could also make the requirement /req/core/fc-bbox-response, item A, more strict ("OnlyAll features that have a spatial geometry that intersects the bounding box SHALL be part of the result set, if the bbox parameter is provided").

There were also other problems not detected, where more features than expected were being returned where the bounding box of the geometry would intersect, but not the actual geometry (the ATS / ETS could actually really check that all returned feature geometries do intersect the requested bounding box).

The ATS does that already (see /conf/core/fc-bbox-response, item 1), but obviously the ETS does not.

[jerstlouis]

@cportele Thanks, I did fix that in our implementation (with some difficulties left with the paging):

https://maps.gnosis.earth/ogcapi/collections/cql2-test:ne_110m_admin_0_countries/items?bbox=150,-90,-150,90&limit=20

However, I do not see, how returning only Antarctica would be detected as an error, because for this the test would have to know the dataset.

I was just thinking of an easy way a moment ago. We could compare the requests for ?bbox=90,-90,180,90 and ?bbox=-180,-90,-90,90, and make sure that all of those features are included in ?bbox=90,-90,-90,90. This should work assuming there are not way too many items compared to the limits.

Re: "Only/All features", is "All" really more strict than "Only"? Perhaps it should be both "Only" and "All"?

The ATS does that already (see /conf/core/fc-bbox-response, item 1), but obviously the ETS does not.

Right. (EDITED -- sorry I realized later you were talking about the spatial geometry here, not the antimeridian). Maybe the ATS could explicitly clarify (not only its bounding box), that might better catch the attention of ETS developers.

Also realized that a basic LineString / BBOX intersection (rivers) was not working either (false negative when line fully within BBOX), so the ETS might possibly not be testing that well either.