Re: [Geotools-devel] Sad state of bbox/geometry filters using foreign CRS

[Justin D. <jde...@op...>]

Well given the current state of affairs its uncertain we will actually
be working on feature model :). So it might be a good idea to start
brainstorming on this one.

Andrea Aime wrote:
> 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
>>> Geo...@li...
>>> 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
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
> 
> !DSPAM:4007,46e6638d162871804284693!
> 


-- 
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org