Gabriel Roldán ha scritto:
> 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?
Yes, in my opinion this is overdue. We could try to put togheter
something during the code sprint if we finish the feature model
switch earlier, what do you think?
Cheers
Andrea
> 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
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
> !DSPAM:4022,46e661d9161161015089218!
>
-------------------------------------------------------------------------
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
