if we just had an API conformance test suite.... dream dream..
I know we talked about this and there were small individual steps towards it,
but would it be time to take the issue seriously?
Gabriel
On Monday 10 September 2007 17:17:16 Andrea Aime wrote:
> 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
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
-------------------------------------------------------------------------
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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
