The current PropertyFeatureSource.getBounds implementation performs a basic bounds check for an include filter. Certain tests (GeoJSONTest.testGetFeatureLine3D) in the geoserver wfs module show that this method fails when given a 3D geometry, as the existing getBounds implementation constructs bounds assuming a 2D geometry.

In accordance with the CsvFeatureSource implementation, I have updated PropertyFeatureSource.getBoundsInternal to always return null, under the assumption that handling different CRS’s is too expensive for the getBoundsInternal() implementation and should instead be handled by a full feature scan.

This does produce a few errors in downstream geoserver tests, where they are not expecting getBounds to return null, but this should be easy enough to fix.

In this case, what is the better route:

Have PropertyFeatureSource.getBoundsInternal() always return null, and update geoserver tests to account for this.

Update PropertyFeatureSource.getBoundsInternal() to check the CRS for number of dimensions etc. and perform a proper bounds calculation.

Testing the first implementation against geoserver, I am geting upwards of 30 different test failures among a few different modules. The second option would probably be easier to implement, although I don’t know which one would be more correct.

The current PropertyFeatureSource.getBounds implementation performs a basic bounds check for an include filter. Certain tests (GeoJSONTest.testGetFeatureLine3D) in the geoserver wfs module show that this method fails when given a 3D geometry, as the existing getBounds implementation constructs bounds assuming a 2D geometry.

In accordance with the CsvFeatureSource implementation, I have updated PropertyFeatureSource.getBoundsInternal to always return null, under the assumption that handling different CRS’s is too expensive for the getBoundsInternal() implementation and should instead be handled by a full feature scan.

This does produce a few errors in downstream geoserver tests, where they are not expecting getBounds to return null, but this should be easy enough to fix.

In this case, what is the better route:

Have PropertyFeatureSource.getBoundsInternal() always return null, and update geoserver tests to account for this.

Update PropertyFeatureSource.getBoundsInternal() to check the CRS for number of dimensions etc. and perform a proper bounds calculation.

Tricky tricky - the ReferencedEnvelope implementation has been set up to fail if the CRS does not match the data. And a ReferencedEnvelope3D for use if needed.
There is a ReferencedEnvelope.create( CRS ) factory method which you can pass a CRS and it will create the correct ReferencedEnvelope implementation as required, you can see it in a lot of the FeatureCollection implementations where we first encountered this issue

The current PropertyFeatureSource.getBounds implementation performs a basic bounds check for an include filter. Certain tests (GeoJSONTest.testGetFeatureLine3D) in the geoserver wfs module show that this method fails when given a 3D geometry, as the existing getBounds implementation constructs bounds assuming a 2D geometry.

In accordance with the CsvFeatureSource implementation, I have updated PropertyFeatureSource.getBoundsInternal to always return null, under the assumption that handling different CRS’s is too expensive for the getBoundsInternal() implementation and should instead be handled by a full feature scan.

This does produce a few errors in downstream geoserver tests, where they are not expecting getBounds to return null, but this should be easy enough to fix.

In this case, what is the better route:

Have PropertyFeatureSource.getBoundsInternal() always return null, and update geoserver tests to account for this.

Update PropertyFeatureSource.getBoundsInternal() to check the CRS for number of dimensions etc. and perform a proper bounds calculation.

Torben

Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net