Hi,
I was also thinking about using some default geometry if no property is given but then I had a look on the FES 2.0 standard. I says about BBOX filter, by using language which is a bit hard to understand for layman like I:
"If there is only one argument (i.e. one child element specified for the operator, the calling service shall apply the operator to the geometric values of all the spatial properties of the resource[11]. In this case, the operator shall evaluate to true if all tested spatial property values fulfill the spatial relationship implied by the operator. Otherwise, the operator shall evaluate the specified arguments (i.e. the two child elements) and test whether their geometric values satisfy the implied spatial relationship. "
The same applies to DWithin and Beyond operators. For the rest operators FES refers to ISO 19125-1:2004, 6.1.14.
So, not one “default geometry” property but “all geometry properties”. I think I would rather like have that as “any geometry property”. If one has something like WFS feature type for administrational units which has separate geometries for polygon and point geometries, the “all geometries” rule makes BBOX query to find the polygon geometry only if also the point geometry happens to be inside the box.
Fortunately feature types with multiple geometries are uncommon. But perhaps Geoserver could make it better than OGC and accept CQL_FILTER with all these variants:
INTERSECTS(the_geom, POLYGON((-90 40, -90 45, -60 45, -60 40, -90 40)))
- explicit geometry property name
INTERSECTS (all, POLYGON((-90 40, -90 45, -60 45, -60 40, -90 40)))
- requires that all geometries intersects
INTERSECTS (any, POLYGON((-90 40, -90 45, -60 45, -60 40, -90 40)))
- it is enough if one geometry intersects
INTERSECTS (POLYGON((-90 40, -90 45, -60 45, -60 40, -90 40))):
- following what FES 2.0 says about BBOX, Dwithin, and Beyond, means the same as “all”.
-Jukka Rahkonen-
···
Andrea Aime wrote:
Adding the list into the loop
Cheers
Andrea
Il 19/ago/2015 21:52, “Andrea Aime” <andrea.aime@anonymised.com> ha scritto:
Going by memory, GeoServer internally represents the “default geometry” as an empty string, so you may want to try a property name without content, or one with an empty CDATA section in place of the name. Let us know if any of that works
Cheers
Andrea
Il 19/ago/2015 20:11, “Martin Davis” <mtnclimb@anonymised.com> ha scritto:
The WFS spec supports “schemaless” (or perhaps “anonymous” spatial queries against featuretypes via the BBOX parameter. But if a more complex query geometry is required (e.g. polygon), it’s necessary to create a Filter, which then needs to have the spatial propertyname provided.
This means that clients need more metadata about featuretype schemas to do polygon queries. This seems a bit inconsistent, since presumably the server mechanism can handle schemaless queries (since it can support BBOX).
I suspect I know the answer to this, but I’ll ask it anyway… Is there any extension in GeoServer that supports WFS queries with a polygonal query geometry WITHOUT requiring a property name?
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users