[CITE-Forum] Test wfs:wfs-1.1.0-Basic-GetFeature-tc208.3 and crosses operator semantic.

Igor Shultays igor at politerm.com.ru
Fri Nov 19 03:49:00 EST 2010

Hi experts.

We test our wfs service at the moment.
And we stopped at the test tc208.3.

We have development by two directions.
Someone develop spatial extension to database for geography query 
language (GQL)
And someone develop WFS service.

We'd like to understand how need to perform crosses operator in OGC 
Filter.(or how properly need to translate that to GQL).

Test wfs:wfs-1.1.0-Basic-GetFeature-tc208.3 (s0002/d1e35143_1/d1e740_1/d1e25211_1/d1e16299_1/d1e9868_1)

       The response to a GetFeature request that includes an ogc:Filter having a
       Crosses spatial predicate must include only features that are crossing
       with respect to the provided geometry value.

Request d1e12296_1:
    Method: POST
<wfs:GetFeature ...>
    <wfs:Query typeName="sf:AggregateGeoFeature">
             <gml:LineString srsName="urn:ogc:def:crs:EPSG::4326">
                <gml:posList>53 22 54 21 54 20 54 19 54 18 54 17</gml:posList>

Test expected feature not in response (gml:name="name-f010").

At the moment that request translate to GQL by follow way:
SELECT .... FROM ... as L WHERE  (...
L.geometry.crosses( geometry::STGeomFromText("linestring(53 22 54 21 54 20 54 19 54 18 54 17)", 4326) )
). (or Crosses(L.geometry, geometry:STGeomFromText("linestring(53 22 54 21 54 20 54 19 54 18 54 17)", 4326)  )

L match sf:multiSurfaceProperty

geometry::STGeomFromText("linestring(....) match gml:LineString from request.

That request must not return any features in response for the following reasons ...

OGC Filter specification declare:

/The semantics of the other operators Equals, Disjoint, Touches, Within, Overlaps, Crosses, Intersects, and Contains
are defined in subclause of the OpenGIS Simple Feature Specification for SQL [5]./

See to OpenGIS Simple FeatureSpecification:

The Crosses relation applies to P/L, P/A, L/L and L/A situations. Where term P is used to refer to 0
dimensional geometries (Points and MultiPoints), L is used to refer to one-dimensional geometries
(LineStrings and MultiLineStrings) and A is used to refer to two-dimensional geometries (Polygons and
Ok. The typeName sf:AggregateGeoFeature only refer to two-dimensional geometries (A) but operation A/L not defined
in specification for crosses operation.

So, when we use above-named GQL-request we have empty response.

In case when we switch operands sf:multiSurfaceProperty and specified gml:LineString so that we will have
follow request:

SELECT .... FROM ... as L WHERE  (...
geometry::STGeomFromText("linestring(53 22 54 21 54 20 54 19 54 18 54 17)", 4326).crosses(L.geometry)
). (or Crosses(geometry:STGeomFromText("linestring(53 22 54 21 54 20 54 19 54 18 54 17)", 4326), L.geometry  )

Only in that case we will take expected for test passing result.

As seen swithing of operands affect to finish result.
In other words (sf:multiSurfaceProperty).cross(LineString(....))(or equal Cross(sf:multiSurfaceProperty, LineString(...)) and
(LineString(...)).cross(sf:multiSurfaceProperty)(or equal Cross(LineString(...), sf:multiSurfaceProperty))
is two different requests. And each will have different result.

Please explain, how need interpret WFS request?
Should whether the test in this case expect specified response?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/cite-forum/attachments/20101119/aa49d3c4/attachment-0001.htm>

More information about the CITE-Forum mailing list