search

opengeospatial / ets-wfs20

Executable Test Suite for WFS 2.0
Other
9 stars 11 forks source link

Test intersectsCurve fails with Predicate Intersects not satisfied by arguments #191

Closed Kate-Lyndegaard closed 2 years ago

Kate-Lyndegaard commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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: https://github.com/opengeospatial/ets-wfs20/blob/464a875b1163a898d00d5bcb5ab308cda0167591/src/main/java/org/opengis/cite/iso19142/basic/filter/spatial/IntersectsTests.java#L220-L224

ghobona commented 3 years ago

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."

Screenshot 2021-02-11 at 12 00 47

The GML files are attached, in Archive.zip

Kate-Lyndegaard commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Dear @ghobona and @dstenger,

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

Kind regards, Kate

keshavnangare commented 3 years ago

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 https://github.com/opengeospatial/geomatics-geotk/issues/8

keshavnangare commented 3 years ago

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 commented 3 years ago

@dstenger

I have updated the calculateEnvelope method name to calculateEnvelopeUsingSingleGeometry as per geomatics-geotk changes in https://github.com/opengeospatial/geomatics-geotk/pull/9 PR.

Please find the current changes in https://github.com/opengeospatial/ets-wfs20/pull/192 PR.

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

dstenger commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

Thank you for the new test service.

@keshav-nangare Can you please test the fix?

keshavnangare commented 3 years ago

@dstenger @Kate-Lyndegaard

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

JohannaOtt commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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.