I had to chat with Andrea a bit on IRC in order to understand this 
email; we ran into this problem on trunk and patched the GeoAPI BBox 
interface
to make getExpression1() and getExpression2() avaialble. I think we did 
this by changing the super class.

On trunk there are two "good" ways to create a BBox:
1) FitlerFactory will let you make a bbox with getPropertyName(), and 
minX...minY, getSRS
- the resulting bbox has getExpression1() as a PropertyName and 
getExpression2() as a Literal BoundingBox (usually a ReferencedEnvelope)
2) FilterFactory2 will let you make useful (but not strictly filter 1.1) 
box with for example Literal( geom1 ) BBOX Literal( geom 2)
- the resulting bbox has getExpression1() and getExpression2() used to 
access the two values

So when you are writing a visitor to generate SQL etc... you should be 
looking at getExpression1() and getExpression2() in order to get the 
complete story.

THE BOTTOM LINE
Filter interfaces are as advertised; they are more general prupose that 
the Filter 1.0 or Filter 1.1 specification (and we would like to keep 
them that way). If you need to make something strictly conformant to a 
specification read the javadocs; and recognize when you use 
FilterFactory2 that you ...

An example; Contains.getPropertyName() is only going to return a valid 
value when getExpression1() is a PropertyName (it is documented as such).
Jody

> Hi,
> today I've been trying to fix http://jira.codehaus.org/browse/GEOT-1736
> The thing is, there is code building bbox filters like:
>
> GeometryFilter filter = ff.createGeometryFilter(FilterType.GEOMETRY_BBOX);
> filter.addLeftGeometry((Expression) ff.property("geom"));
> filter.addRightGeometry(ff.createBBoxExpression(new Envelope(0,10,0,10)));
>
> and this code does not initializes the minx,miny,maxx,maxy fields
> of BBOXImpl at all, making it impossible to clone or encode the
> filter (at least when the filter encoder uses the BBOX interface,
> which is somthing only the DB2 module and the ArcSDE ones do afaik).
>
> That is, by using the old filter API and setting the expressions
> directly. Since it is still possible to use those code paths,
> I've tried to fix the code by getting minx/miny/maxx/maxy
> when the expression is set. This code requires that the first
> expression is a property name, and the second a literal that can
> be converted into an envelope.
>
> So far so good, the fix works in geoserver, but there are various
> tests in gt2 that do silly things, like:
> * build a bbox filter with two literals
> * build a bbox filter with the expressions exchanged, that is, first
>    the bbox and then the property name
>
> These are both invalid, and my take would be to just fix the tests
> doing so by recoding them to use a proper bbox building code.
>
> Any objections to that?
> Cheers
> Andrea
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to