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;
}.
--
Jody Garnett
On 29 December 2014 at 12:45, Torben Barsballe <[email protected]>
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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
