Andrea you make a very good point:
- Expression.NULL (ie unspecified) is the correct representation of
check against the "default geometry" when working with spatial filters
- My hack to let PropertyExpression("").evaualte( feature,
Geometry.class ) is nice + scalable interpretation so PropertyAccessor
does not need to gain a new method (but this hides a problem that we may
be able to make explicit)
BUT:
- Justin needs all geometries (for reprojection he says - but my guess
is reprojected feature collection bounding box calculation)
- Spatial Filters implementations need to call PropertyAccessor code
when Expression.NULL is provided (not unreasonable)
So if we keep doing default geometry:
- Object PropertyAccessor.getDefaultGeometry() - grab a default geometry
(of whatever representation we are running)
- Envelope PropertyAcessor.getBounds() - grab bounds of default geometry
(because filter code cannot depend on geometry implementation quite yet)
In the new feature model the bounds are available as part of the
GeometryAttribute used to hold the value (so this code will not go unused)
We could roll these up (and make it clear that "default" is different
from xpath=""):
- Object PropertyAccessor.getDefault( Class type ) - takes a Geomery
class or an Envelope and is expected to do the right thing, or
Envelope.class for the bounds I guess
Jody
> Hi,
> just yesterday I stumbled on an inconsistency between the
> geometry filters implementations and the sql pre/post splitter
> in 2.2.x (and maybe in 2.3.x, unless someone fixed this).
>
> The geom filter implementation turns null expressions into
> default geometries, but the pre/post splitter
> (PostPreProcessFilterSplittingVisitor, what a name :-) )
> states a geometry filter with null left/right expressions
> cannot be encoded (which means the filter will have to
> run in memory, so much for your bbox filter that becomes
> totally useless from a performance point of view).
>
> Yet, this does not surprise me much: the GeometryFilter
> behaviour is coded in the implementation, but I could not
> find it cited anywhere in the javadocs.
>
> So, there is a bug, but I'm not sure if it's in the spec
> or in the splitter... all in know is that WFS GetFeature
> requests that do use bbox filters are hellish slow in
> Geoserver because of this...
>
> Opinions?
>
> Cheers
> Andrea
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
