Hi,
it is a well known issue that all our datastores are working
properly only if the filters used to access them are expressed
in the same CRS as the data.
This in a way mimics what the underliying storage do: shapefile
spatial index are expressed in the same CRS as the geometry,
try to access postgis with a geometry filter in a CRS other
than the one of the compared geometry field and you'll get a
straight error ("cannot compare geometries with different srid"
or something like this).On the other side, OGC filter spec allows bbox and geometry literals to be specified in whatever CRS the user likes. This hasn't been a great problem so far, but things are changing in GeoServer land because WFS 1.1 promotes a way to specify filters that assumes lat/lon axis ordering, while all the underliying data is in lon/lat. So, I need to handle this somehow to have GeoServer handle this. Now, for the short term I'm going to write a filter transformer that will reproject geometries and bboxes to the native crs before passing them to the datastore. This is a sorry fix, and also a fragile one, since it has two working assumptions: * one side of the geometry filter is a property name, which is something I can assume given that GeoServer filters are coming from compliant OGC filter, that asks the first side to be a PropertyName element. * the second side is a geometry literal, which is again guaranteed by the xml schema These two assumptions do not work in the general GeoTools case, where the spatial comparison filters do take two generic expressions. A full fix would require that all in-memory implementations of filters, as well as all the datastores encoding them somehow to access the storage more efficiently (jdbc, shapefile) will have to learn how to handle geometries and bboxes in a CRS other than the native one. This is no small task, all datastores are involved, and would require some days of work just to make the modifications, let alone testing them (since we would have to setup appropriate unit tests for the mismatched crs case, that we don't have at the moment). Wondering how could we handle this one... Cheers Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
