Re: [Geotools-devel] trunk filter patch

[Jody G. <jga...@re...>]

Commit is set to go out; spent a lot of time stuck on filters that look 
like the following:
<Filter><PropertyIsEqual><PropertyName>foo</PropertyName><Literal>2</Literal></PropertyIsEqual><FeatureId>FID.1></Filter>

Cheers,
Jody

Jody Garnett wrote:
> I have prepared a patch to trunk to clean up a bit more of our filter code.
>
> Specifically:
> - SAX parser now uses org.opengis.filter.FitlerFactory2
> - DOM parser now uses org.opengis.filter.FitlerFactory2
>
> I am running into the following issues:
> - the DOM parser makes use of a JTS Polygon literal to represent a 
> bounding box (simply because the method expects to return a Geometry)
> - the XDO parser matches this uses (simply because it uses the DOM 
> parser to verify it is doing exactly the same thing GeoTools expects)
>
> I would like to match org.opengis.filter.FilterFactory2 use; and make 
> use of a BoundingBox (specifically a ReferencedEnvelope) literal when 
> representing a BBOX filter.
>
> I will not that the rest of our code base has a series of sometimes 
> amazing hacks to account for this use of a Polygon; often blindly 
> casting and using geometry.envelopeInternal().  Expression.evaulate( 
> object, Envelope.class ) is also used in order to let the converter api 
> handle the difference betwee 
> Polygon/Envelope/ReferencedEnvelope/BoundingBox.
>
> I will also note that we do not have consistent use in our library with 
> respect to GML srsName; so far we have seen the following:
> - FilterFactoryImpl.bbox( Expression, BoundingBox ) making use of 
> CRS.getSRS( ... )
> - a user stuck for a week until we digured out Geometry.setUserData 
> (srsName ) was *required* when using the XDO encoder with MultiGeometry
>
> Jody
>