OGC API query doesn't return all features

[claudiubsc]

Description
While using this dataset: https://demo.pygeoapi.io/master/collections/dutch_castles, OGC API query doesn't return all features. The query:
https://demo.pygeoapi.io/master/collections/dutch_castles/items?f=json&offset=90&limit=100&bbox=-179.9999999,-86.0,179.9999999,86.0 returns the "next" page but
https://demo.pygeoapi.io/master/collections/dutch_castles/items?f=json&offset=100&limit=100&bbox=-179.9999999,-86.0,179.9999999,86.0 returns 0 features.

If we tweak the bbox a little bit, like:
https://demo.pygeoapi.io/master/collections/dutch_castles/items?f=json&offset=100&limit=100&bbox=-173.9999999,-86.0,179.9999999,86.0 , then the features are returned.

Steps to Reproduce
Steps to reproduce the behavior:
Run query in browser:
query that works: https://demo.pygeoapi.io/master/collections/dutch_castles/items?f=json&offset=90&limit=100&bbox=-179.9999999,-86.0,179.9999999,86.0
query that should work but returns 0 features: https://demo.pygeoapi.io/master/collections/dutch_castles/items?f=json&offset=100&limit=100&bbox=-179.9999999,-86.0,179.9999999,86.0

Expected behavior
A clear and concise description of what you expected to happen.
This query should return features: https://demo.pygeoapi.io/master/collections/dutch_castles/items?f=json&offset=100&limit=100&bbox=-179.9999999,-86.0,179.9999999,86.0

Screenshots/Tracebacks
If applicable, add screenshots to help explain your problem.

Environment

• OS:
• Python version:
• pygeoapi version: 0.24.dev0

Additional context
Add any other context about the problem here.

[tomkralidis]

Transferring this issue for the demo repo, cc @justb4

[doublebyte1]

@claudiubsc please note that the queries are not expected to return all of the features in the dataset; they should only return the ones that match the query criteria. When you do spatial sub setting, the server will only return the features that are within the given bounding box.

In the case of your first query, you are passing a bounding box that does not contain any castles, as the castles in this dataset are all located in the Netherlands (see bellow). Therefore the server returns "0" features.

In the case of your second query, you are passing a very large bounding box, that does indeed include the Netherlands.

I hope this helps to clarify that there is no bug in the API, and it is behaving as expected. For more information, I would recommend to checkout the Standard, or the OGC API Workshop:

https://docs.ogc.org/is/17-069r3/17-069r3.html

https://ogcapi-workshop.ogc.org/api-deep-dive/features/#features

[ldesousa]

May I add that with EPSG:4326 the coordinate pair [-179.99, -86.0] is invalid. As so [179.99, 86.0].

[claudiubsc]

Hello all. Thank you for your comments.

@doublebyte1 My first and second query are using the same bbox: [bbox=-179.9999999,-86.0,179.9999999,86.0]. To give you the full context, I query the features page by page. So, all the queries are the same, except for the offset parameter. My first 9 queries (with the offset equal to 0,10,20...90) return features but when the offset is 100, no features are returned, but there are more feature in the given bbox to return. I'm trying to understand why the server doesn't return anymore features for the given bbox

@ldesousa I was under the impression that the correct format is: minLon, minLat, maxLon, maxLat. The server accepts my 9 first queries with the bbox declared like this.

[ldesousa]

@claudiubsc Since you do not specify a CRS for the bounding box in your query, pygeoapi is defaulting to CRS84 (apparently according to the spec), in which axes order is indeed inverted. Therefore that is not the issue.

However, the original dataset is defined on the Dutch CRS set on Amersfoort (EPSG:28992), which uses an Oblique Stereographic projection. As you query that dataset with a bounding box so far away from the central point of projection strange things are bound to happen. Try using cs2cs to compute one of those coordinate pairs (e.g. [-179.99, -86.0]) into the Amersfoort CRS and check the results.

[claudiubsc]

@ldesousa Indeed, strange things are happening :). While I agree with you that I could reproject the coords to Amersfoort CRS, this will only be a workaround for a strange behavior of the server. The reason the server stops after 9 queries could appear in other queries, if it's a bug on the server side.

[ldesousa]

@claudiubsc The server does not stop, and there is no bug, the server is doing pretty much what you are ordering it to do. You need to carefully review your queries and understand whether they are valid.

@tomkralidis @justb4 There isn't much way around this kind of "abusive" query. This same situation can easily happen with a CRS that applies the Gauss-Krüger projection on the Greenwich meridian. Any queries invoking bounding boxes with limits close to -180º longitude will too produce some kind of numerical overflow. Similar story with Mercator. If there is an issue it is with the spec. The co-domain of a map projection can be whatever, including infinite.

[claudiubsc]

@ldesousa Again, I do agree with your point that bounding boxes close to limits can produce numerical overflows. How do explain that 9 queries are successful and that 1 query is always unsuccessful and they all use the same bounding box?
In my opinion, in this situation, if this is an overflow it should return an error.