BBox has two things that need to be fixed up:
- the javadocs need to be lined up against the specification and filter factory
- the BBox node should make available a PropertyName and Literal expression to make good on the FilterVisitor / ExpressionVisitor contract. Currently code is making these constructs inline which is error prone and hard.
BBOX acts as a node containing a PropertyExpression and a literal Bounds; because there is no way to access the information in this form as part of the geoapi interface I am stuck creating these constructs on the fly in order to have a successful walk of the data structure during FilterVisitor / ExpressionVisitor.
I would like to handle this interface the same way we handled the other spatial functions:
- GeoAPI BBOX:
Spatial operator that evaluates to true}when the bounding box of the feature's geometry overlaps the bounding box provided in this object's properties. An implementation may choose to throw an exception if one attempts to test
features that are in a different SRS than the SRS contained here.
- GeoAPI FilterFactory:
Checks if the bounding box of the feature's geometry overlaps the specified bounding box
Our geotools implementations check the geometry for not disjoint with the literal envelope. This does agree with our recent review of the Filter specification ....
- Filter Specification:
The BBOX element is defined as a convenient and more compact way of encoding the very common bounding box constraint based on the gml:Box geometry. It is equivalent to the spatial operation <Not><Disjoint> ... </Disjoint></Not> meaning that the <BBOX> operator should identify all geometries that spatially interact with the box in some manner.