Issue with gmlas.d.10: Validate geometries (1) regarding outer ring orientation

[heidivanparys]

There is an issue with gmlas.d.10: Validate geometries (1), as also reported in #60 .

When providing a GML file in http://www.opengis.net/def/crs/EPSG/0/4326, with coordinates transformed from http://www.opengis.net/def/crs/EPSG/0/25832, the validation fails with message "Error detected: Invalid polygon. Outer ring of polygon is clockwise within element MultiSurface". Transformation was done by two different tools (Go Publisher and FME), and the validation fails for both resulting files.

When providing a modified GML file, where the points of the exterior boundary are placed in reverse order, the validation passes.

When validating the same files with Test Suite: GML 3.2 (ISO 19136:2007) Conformance Test Suite from http://cite.opengeospatial.org/teamengine/, the results are opposite. That is, the original file, created by the tools, passes validation, the modified file fails.

So to these two validators give a conflicting result.

When visualising the polygon with the coordinates from EPSG:4326, the orientation of the boundary is counterclockwise, thus its orientation is positive, thus it should not fail the test, as I see it.

When validating with GML file in http://www.opengis.net/def/crs/EPSG/0/25832, there is no issue. So this may have something to do with the axis order of the coordinate system used.

Test which reports incorrect orientation for EPSG:4326, with test object
GPP_ProtectedSites_a113a810_EPSG4326.txt

Result in OGC validator:

Test which reports correct orientation for EPSG:4326, with test object
GPP_ProtectedSites_a113a810_EPSG4326_inverseorientation.txt

Result in OGC validator:

Test with data in EPSG:4326, with test object ProtectedSites_a113a810-53a7-11e2-b325-00155d01e765_EPSG25832.txt

[cportele]

I agree, this is not satisfactory. And different libraries have implemented different interpretations. See the discussion in #60.

I will have a look in the CITE test to see how they determine the orientation...

[cportele]

Yes, the CITE tests convert the geometry to a right-handed CRS before determining the orientation - also using JTS. A comment states that JTS would expect a right-handed CRS, but I found nothing in the JTS documentation or source code about this. I guess it boils down to the question whether the orientation of a geometry depends on the left/right-hand nature of the CRS.

[cportele]

Update: the orientation of a geometry does not depend on the left/right-hand nature of the CRS. JTS uses Green's Theorem, which assumes a right-handed CRS. I.e., ETF has to convert the geometry to a right-handed CRS before testing the orientation.

[josemasensio]

Dear all,

We continue trying to solve the issue. Looks like is related to external libraries improvement.

Best regards.

[carlospzurita]

We are moving forward with this issue. The pull request deegree/deegree3#1034 with a fix in deegree to be used in the ETF code has been accepted. Whenever the new release is ready, we will integrate it on the validator. Will keep you posted.

[fabiovinci]

Dear all,

a fix for this issue is available in the BETA instance of the validator, could you please test the solution and report your feedback?

For reporting issues, please use the Validator helpdesk.

[heidivanparys]

It works fine now in the beta instance, thank you.