Part 2/bbox-crs validation: Using transformed extent as bbox fails in many cases

[jnystad]

Describe the bug

Not entirely sure this is a bug or intended behaviour.

Transforming the extent given in WGS84 to any other projection will in many cases produce invalid or wrong bboxes.

For global datasets that a service wants to provide (a subset of) in various projections, this test suite will fail unless said projections are split into separate collection endpoints.

I don't see any mention of this in the spec, so I assume it is not required to have a collection extent that is valid in all supported transformations.

While it is debatable if a collection should support projections they cannot fully be represented in, this should in my opinion be allowed for practical reasons (e.g. GIS software can usually be expected to request the data with valid bboxes).

To Reproduce Steps to reproduce the behavior:

Have a collection with extent [-180, -90, 180, 90] that supports "http://www.opengis.net/def/crs/EPSG/0/3857".

Example request query params:

Request params: bbox-crs=http://www.opengis.net/def/crs/EPSG/0/3857
                                bbox=-20037508.3427892,-∞,20037508.3427892,238107693.2649677

Have a collection with extent [-180, -90, 180, 90] that supports "http://www.opengis.net/def/crs/EPSG/0/32633".

Example request query params (zero area bbox due to out of bounds latitude):

Request params: bbox-crs=http://www.opengis.net/def/crs/EPSG/0/32633
                                bbox=500000.0000000,-9997964.9430210,500000.0000000,9997964.9430210

Examples are extreme, but this also happens for more probable extents.

Expected behavior

1. Tests should validate bbox-crs support with valid bounds for all supported projections.
2. Tests should not expect all features to be represented in these responses

[dstenger]

Thank you for reporting. We will do further investigation.

[aaime]

We are seeing failures in transformed bbox tests as well, with the same issues reported above, including bbox values that include infinite sign. For this case, the system should probably be checking if the bbox coordinates are within the valid area for the target projection.

In addition to that, there are other failures where the test is getting less features than it expects. The test counts how many features are found in the original data set, and expects to find the same count using the reprojected bbox.

However the reprojection is performed in a way that's too simplistic, assumes that the min/max corners will be again the min/max corner after reprojection.

Here is a simple example of what can happen, assuming the transformation just applies a rotation and a stretch:

The dashed lines shows the bbox computed by the current algorithm, the dotted line the actual bbox of the transformed features. This is just a simple example, transformation can also bend lines and cause the extreme points not to be in the original vertices anymore. And more, like polar stereographic can cause one of the vertices to be folded in the middle of the target shape (if it happened to be a pole).

In GeoTools there is a class dedicated to bounding box reprojection that tries to be more robust, using densification and handling a variety of corner cases, but even with that one, the result is just an approximation: one could not use it, and then assume to have the transformed bbox catch all of the original features. In the common case, it will catch most of them, but there might be residual odd cases that are not yet handled, where the resulting bbox is still significantly wrong.

I would suggest dropping the count equality test and just checking that the features returned, are part of the original set, instead.

[ghobona]

@jnystad Could you please provide a URL of an API that we can use to reproduce the issue?

[aaime]

The service at https://gs-main.geosolutionsgroup.com/geoserver/ogcapi/ogc/features/v1 offers an example of bbox reprojection failure, the tests end up producing this URL:

https://gs-main.geosolutionsgroup.com/geoserver/ogcapi/ogc/features/v1/collections/tasmania_roads/items?bbox-crs=http%3A%2F%2Fwww.opengis.net%2Fdef%2Fcrs%2FEPSG%2F0%2F3857&bbox=-20037508.3427892%2C-%E2%88%9E%2C20037508.3427892%2C238107693.2649677

whose bbox is bbox=-20037508.3427892,-∞,20037508.3427892,238107693.2649677.

In this case the bbox has been expanded to cover an area larger than the actual data, but one can get the same issue with data actually spanning from pole to pole.

[jnystad]

Thanks @aaime. I was running this towards an internal API, so I have no example for you, I'm afraid.

[dstenger]

@bpross-52n Can you please try to reproduce the reported behavior with the provided API? We will discuss further steps in an upcoming CITE meeting.

[aaime]

The API I've shared shows some of the reprojection issues. I don't have an API that shows the issues with the rotation (which results in fewer features being returned) yet, I cannot promise I'll have time to set one up, but hope the explanation and drawings can be bring the point home.

[ghobona]

@aaime The API currently appears to be offline.

[aaime]

@ghobona the server redeploys 3 times a day and picks up the latest build from the GeoServer development branch. It can be occasionally down. (but it's up for me now).