David Adler ha scritto:
From my perspective, the OGC specification is a bit ambiguous, although maybe I just can't find the appropriate section.
The appropriate definition should be the one in the Filter Encoding 1.1 spec:
"The <BBOX> element is defined as a convenient and more compact way of encoding the very common bounding box constraint based on the gml:Envelope 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."
The description of a GeoTools BBOX filter at
http://docs.codehaus.org/display/GEOTOOLS/Using+a+bounding+box+Filter
refers to "features returned to those which are not wholy (sic) outside the bounding box".
Same semantics as the spec it seems
The DB2 implementation will return a diagonal line outside the bounding box but whose envelope intersects
the bounding box.
That's what we call the "loose bbox" filter in the postgis datastore.
If you enable loose bbox in the settings you'll have the same behaviour
as EnvelopesIntersect. This is good for WMS bboxes, but not compliant for WFS GetFeature requests I fear.
It isn't clear whether there is an intention for a bounding box filter to be semantically different from an intersects
filter with a target polygon which is a rectangle.
In DB2, we tend to treat "bounding box filter" as the implementation in our EnvelopesIntersect predicate which returns
all features whose envelope intersects a rectangular window defined by the lower-left and upper-right coordinates.
If a spatial index is defined, we return all rows resulting from a successful index scan. (GeoTools BBOX equiv)
For the intersects predicate, we do first filter using an index scan but then each candidate geometry needs
to be compared precisely against the target geometry which is orders of magnitude more computationally intensive.
That's what Postgis is doing as well. The spec is the spec, there's not
much we can do about it. One possible option may be to allow the WFS
to handle bbox predicates in a less strict way, that is "loose bbox" at the WFS level. It may be a reasonable option for WFS that is run
in house, in a controlled environment. I would not say the same for
a public facing server, where standard compliance is more important.
I assume that it has been brought up before that each spatial query needs to be done twice, once for the bounding
box at the beginning of the GML and then again to get the actual features.
In fact I'm not happy about it neither, but we cannot stream out results
and do a single query at the same time. By the time we have read all features, the GML has already taken the way of the client.
Yet, it seems to me the GML spec leaves a door open in order to avoid
computing the bbox:
"BoundingShapeType
This property describes the minimum bounding box or rectangle that encloses the entire feature. Its content
model is as follows:
<element name="boundedBy" type="gml:BoundingShapeType"/>
<complexType name="BoundingShapeType">
<sequence>
<choice>
<element ref="gml:Envelope"/>
<element ref="gml:Null"/>
</choice>
</sequence>
</complexType>
The gml:Envelope element is defined in clause 9.1.5. A value of gml:Null may appear if an extent is not applicable or not available for some reason."
Well, the reason for putting a GML:Null in the bbox may be a that the admin set a configuration option in the administration panel so that the bounds are not computed :-p
I would like to hear people opinion on both configuration options.
Cheers
Andrea
