opengeospatial/ets-ogcapi-features10

Bounding box numberMatched test failures due to loss of precision in extent coordinates

Opened this issue · 2 comments

code-akki commented

Describe the bug
The precision of coordinates (> 7 decimals) returned in the actual extent of FeatureResponse is rounded off to 7 digits by the compliance test which leads to inconsistency in the response returned by the validateFeaturesWithBoundingBoxResponse_NumberMatched. The round off might be the consequence of this.

The extent returned in the featureResponse is (-7.557159806905192, 49.76680723514262, 1.112473832170855, 57.70488356766183) [see Parameter No. 1 in the image below] is rounded off to (-7.5571598,49.7668072,1.1124738,57.7048836) [see Parameter No. 2 in the image below]

The above issue is not the same as the one mentioned in #188, but rather due to the truncation of digits during a round-off. The missing points fall just outside the bounding-box because the extent is rounded-off.

To Reproduce
Steps to reproduce the behavior:

  1. Test against our test server

Expected behavior
NA

Screenshots
ogc_compliance_error_1

Additional context

dstenger commented

Thank you for reporting.
We will do further investigation.

bpross-52n commented

@code-akki I used the following request, wich contains the bounding box taken from the collection metadata without any rounding of the coordinates:
https://ogc-compliance.iudx.io/collections/1e7f3be1-5d07-4cba-9c8c-5c3a2fd5c82a/items?bbox=-7.557159806905192%2C49.76680723514262%2C1.112473832170855%2C57.70488356766183
This returns 29994 features:

{
    "numberMatched": 29994,
    "features": [
        {
....

As the collection contains 30000 features and the extent from the collection metadata was used for the request, we would expect that all 30000 features are returned by this request. Would you agree to that?