Test intersectsCurve fails with Predicate Intersects not satisfied by arguments

[Kate-Lyndegaard]

Hi,

I am receiving Predicate Intersects not satisfied by arguments ... expected [true] but found [false] for a WFS service.

WFS service: https://haleconnect.com/ows/services/org.918.cc100895-4a04-4602-a94f-8b955d136893_wfs?SERVICE=WFS&REQUEST=GetCapabilities&VERSION=2.0.0

The test IntersectsTests.intersectsCurve() fails twice with the exception: Predicate Intersects not satisfied by arguments

INSPIRE Validator Test Report:
WFS_Validator_Report_Pred.zip

The saved responses available at the links in the INSPIRE validator test report display incomplete wfs:FeatureCollections, however I cannot reproduce this using the same requests.

Could you please help me determine what the issue is?

Kind regards,
Kate

[dstenger]

Thank you for reporting.

@keshav-nangare Can you please try to reproduce the reported behavior on the master branch of the WFS 2.0 test suite?

[keshavnangare]

@dstenger

The test sends the following request:
Method: POST
URL: https://haleconnect.com/ows/services/org.918.cc100895-4a04-4602-a94f-8b955d136893_wfs
Body:

<wfs:GetFeature xmlns:wfs="http://www.opengis.net/wfs/2.0" count="10" service="WFS" version="2.0.0">
  <wfs:Query xmlns:ns14="http://inspire.ec.europa.eu/schemas/elu/4.0" typeNames="ns14:ExistingLandUseObject">
    <fes:Filter xmlns:fes="http://www.opengis.net/fes/2.0">
      <fes:Intersects>
        <fes:ValueReference xmlns:tns="http://inspire.ec.europa.eu/schemas/elu/4.0">tns:geometry</fes:ValueReference>
        <gml:LineString xmlns:gml="http://www.opengis.net/gml/3.2" gml:id="d1e1" srsName="urn:ogc:def:crs:EPSG::3044">
          <gml:posList>6085657.75 451890.4 6374986.52 711194.99</gml:posList>
        </gml:LineString>
      </fes:Intersects>
    </fes:Filter>
  </wfs:Query>
</wfs:GetFeature>

Response: Response.txt

The geometry with gml:id="GEOMETRY_bc2b7dd2-22ff-4ec8-bfb1-3e3ee89d19b4" failed with the reported message.

The failure message is reported when the intersect condition fails. Please check the below code for more reference:

ets-wfs20/src/main/java/org/opengis/cite/iso19142/basic/filter/spatial/IntersectsTests.java

Lines 220 to 224 in 464a875

	Node geom = geomNodes.item(i);
	boolean intersects = TopologicalRelationships.isSpatiallyRelated(SpatialOperator.INTERSECTS, gmlCurveElem,
	geom);
	Assert.assertTrue(intersects, ErrorMessage.format(ErrorMessageKeys.PREDICATE_NOT_SATISFIED, INTERSECTS_OP,
	XMLUtils.writeNodeToString(gmlCurveElem), XMLUtils.writeNodeToString(geom)));

[ghobona]

2021-02-11

I was able to verify visually, using QGIS, that the geometries causing the error do not intersect with the linestring provided in the GetFeature request.

Methodology:

1. Copied the geometries of the MultiPolygons reported by the Test Suite to separate GML files (sample1.gml and sample2.gml)
2. Copied the geometry of the linestring provided by the GetFeature request to a separate GML file (line.gml)
3. Loaded the GML files into QGIS
4. Visually checked whether they intersect. See a screenshot attached.

So we can conclude that the Test Suite is correct in its assessment that "Predicate Intersects not satisfied by arguments."

The GML files are attached, in Archive.zip

[Kate-Lyndegaard]

Dear @ghobona,

Thank you very much for your analysis. Why does your schema for the example files reference http://schemas.opengis.net/gml/2.1.2/feature.xsd? Do you think it would be helpful to create sample files of gml:MultiSurfaces?

[ghobona]

Hi @Kate-Lyndegaard

I wanted to visualise the features on QGIS, so I first created a GML file using QGIS. Changing the geometry type would not fix the issue.

@dstenger and I discussed the issue this morning and determined that the LineString used to test intersection is being generated from the extent bounding corners of the complete Feature Collection. This creates a problem because not all features in the collection intersect the diagonal line from one bottom corner to one upper corner. So we have concluded that this is a bug in the test suite and can be fixed by generating the LineString from the extent bounding corners of a single feature.

[Kate-Lyndegaard]

Dear @ghobona and @dstenger,

Thank you very much for your insight on this issue. I really appreciate your help.

Kind regards,
Kate

[keshavnangare]

As per the comment, the generation of LineString will be using one of the geometry from the feature. So updating the method calculateEnvelope of Extents class in geomatics-geotk. Please find the relevant issue opengeospatial/geomatics-geotk#8

[keshavnangare]

Updated the JUnit test which is failing when single geometry is used to calculate envelope. Please find the changes and points in comment of #192 PR.

[keshavnangare]

@dstenger

I have updated the calculateEnvelope method name to calculateEnvelopeUsingSingleGeometry as per geomatics-geotk changes in opengeospatial/geomatics-geotk#9 PR.

Please find the current changes in #192 PR.

I am not able to test changes with the provided service in issue.

[dstenger]

When I try to test the fix, test "intersects Curve" is skipped using the service referenced in the description of this issue.

@Kate-Lyndegaard Did you change the service? If that is the case, can you please provide a new test service which can be used to test the fix?

[Kate-Lyndegaard]

@dstenger I did not change the service in the orginal ticket description, however I can provide you with a new test service based on the same dataset.

New test service: https://test.haleconnect.de/ows/services/org.396.239874b6-e668-4e25-8425-eeed9ae37c48_wfs?SERVICE=WFS&REQUEST=GetCapabilities&VERSION=2.0.0

Thank you @keshav-nangare and @dstenger for the fix.

Kind regards,
Kate

[dstenger]

Thank you for the new test service.

@keshav-nangare Can you please test the fix?

[keshavnangare]

@dstenger @Kate-Lyndegaard

I tried with the new service but it is still skipping the intersectsCurve test.

[JohannaOtt]

@dstenger I just tested this behavior on beta and the intersectsCurve test is still skipped for the latest example @Kate-Lyndegaard provided. How is the approach for closing/testing issues in this repository? Can we expect closed issues to be implemented on beta or not?

[dstenger]

@JohannaOtt
We actually close issues as soon as a fix is implemented, verified and merged to master branch (this is the current status here).
Usually, in the close future, Beta will be updated. This is indicated by the milestone set in the issue (here 1.37).
On Beta (https://cite.opengeospatial.org/te2/), however, there is v1.36 installed (please see the landing page of the environment). Thus, this fix has not been installed on Beta, yet. This will be done at the end of this week. All Beta releases are announced via the cite-forum mailing list after installation and tests are finished.
I favor this workflow as I see the repository independently from the Beta environment. However, I also understand your point.
If this workflow is confusing for you and you would like to propose a different one (e.g. issue is closed when installation on Beta is done or different communication when Beta is updated), can you please open an issue in https://github.com/opengeospatial/cite/issues?

[JohannaOtt]

@dstenger Thanks a lot for the detailed explanation.
As long as the workflow is clear and known, I do not really care which one is used.
I tried to subscribe to the mailing list now - hope it is the right one.