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
