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

[code-akki]

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

Additional context

[dstenger]

Thank you for reporting.
We will do further investigation.

[bpross-52n]

@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?