[Geoserver-devel] gt-property-ng migration - getBoundsInternal() implementations

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:

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

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

Torben

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.

Torben

···

On Mon, Dec 29, 2014 at 12:45 PM, Torben Barsballe <tbarsballe@anonymised.com> wrote:

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:

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

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

Torben

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

Here is an example:

ReferencedEnvelope getBoundsInternal(Query query) throws IOException {
SimpleFeatureCollection fc = getFeatures(query);
SimpleFeatureIterator fi = null;
ReferencedEnvelope result = ReferencedEnvelope.create(getSchema().getCoordinateReferenceSystem());
try {
fi = fc.features();
while(fi.hasNext()) {
SimpleFeature f = fi.next();
BoundingBox featureBoundingBox = f.getBounds();
if(f != null && featureBoundingBox != null) {
ReferencedEnvelope featureBounds = ReferencedEnvelope.reference(featureBoundingBox);
result.expandToInclude(featureBounds);
}
}
} catch(Exception e) {
if(fi != null) {
fi.close();
}
}
return result;
}.

···

On 29 December 2014 at 12:45, Torben Barsballe <tbarsballe@anonymised.com> wrote:

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:

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

  2. 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


GeoTools-Devel mailing list
GeoTools-Devel@anonymised.coms.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


Jody Garnett