Unexpected validation error on counterclockwise polygon

[mwjsanders]

I am faced with an unexpected validation error when validating the GML Application schema. The validation error states that the outer ring of the polygon is not counter clockwise while in fact it is counter clockwise. I validated a GML feature from the GeographicalName dataset:

<wfs:member>
    <gn:NamedPlace gml:id="NL.TOP10NL.GN.100000145">
        <gn:beginLifespanVersion>2015-05-31T00:00:00Z</gn:beginLifespanVersion>
        <gn:endLifespanVersion xsi:nil="true" nilReason="other:unpopulated"/>
        <gn:geometry>
            <gml:Polygon gml:id="geom.geographicalname.695325" srsDimension="2" srsName="urn:ogc:def:crs:EPSG::4258">
                <gml:exterior>
                    <gml:LinearRing>
                        <gml:posList>
51.52241776655308 3.604928494424912 51.52280756735408 3.6049132089858955 51.52280695168354 3.6048057064543992 51.522789539030676 3.6036315515016715 51.52278205994033 3.6031754223908568 51.52277275016531 3.6031774740024556 51.522571414061005 3.6032219970992 51.52205263867542 3.6033404733421257 51.522062259601526 3.60421779093866 51.52167554530979 3.6043051047816212 51.52168204244095 3.604318454359244 51.52184004474107 3.604643217284736 51.52198951009785 3.604924707768916 51.522009619103436 3.6049657704640374 51.52201471175038 3.604957197644315 51.5220221449546 3.6049446995634096 51.522043150908644 3.604980322780102 51.52204851323886 3.604989422402476 51.522089117002004 3.605029076282544 51.52211268437776 3.6049367969925368 51.52241776655308 3.604928494424912
                        </gml:posList>
                    </gml:LinearRing>
                </gml:exterior>
            </gml:Polygon>
        </gn:geometry>
        <gn:inspireId>
            <base:Identifier>
                <base:localId>100000145</base:localId>
                <base:namespace>NL.TOP10NL.GN</base:namespace>
                <base:versionId xsi:nil="true" nilReason="other:unpopulated"/>
            </base:Identifier>
        </gn:inspireId>
        <gn:localType>
            <gmd:LocalisedCharacterString locale="nl-NL">Functionelegebieden</gmd:LocalisedCharacterString>
        </gn:localType>
        <gn:type xsi:nil="true" nilReason="other:unpopulated"/>
    </gn:NamedPlace>
</wfs:member>

The validation report states: The feature geometry is not a valid GML geometry. Error detected: Invalid polygon. Outer ring of polygon is clockwise within element Polygon, (gml:id: geom.geographicalname.695325 with coordinates: LINESTRING (51.522418 3.604928,51.522808 3.604913,51.522807 ...) The Polygon is stored in a postgres db and according to the ST_Orientation function the outer ring is counterclockwise and there is no transformation on the geometry when the complex feature is being build.

[cportele]

The geometry validation currently relies on the deegree library, which in turn uses the JTS library to determine the orientation of the rotation.

However, I think the result is correct. In the left-handed coordinate system that is used (first axis up, second axis right) the rotation is clockwise. In a right-handed system like in a typical map projection (first axis right, second axis up) it would be counter-clockwise. That is at least my understanding...

If that analysis would be correct: Can it be the case that the native coordinate reference system in the DB uses a coordinate system with lon/lat or east/north (which would explain the ST_Orientation result) and the orientation is not considered in the conversion to ETRS89 lat/lon?

[heidivanparys]

@cportele I am not sure that the analysis is a correct: as I see it, the exterior boundary of a surface has a certain orientation. This orientation does not change when the boundary's coordinates are expressed in another coordinate system, also not when that coordinate system has the opposite orientation of the original coordinate system (right-handed vs. left-handed).

[cportele]

@heidivanparys - Why has the CRS no effect on the orientation of a ring? As I understand it, the orientation is the orientation of the geometry in its CRS. It it is not necessarily, for example, the orientation of the ring drawn on the Earth surface when viewed from space.

From the new edition of ISO 19107 (DIS):

For surfaces, the orientation reflects which direction is "up", the "top" of the surface being the direction of a completing "z-axis" that would be the local upward.

That is, the z-axis points in a different direction whether you use a left-handed or right-handed CRS.

Anyhow: Since most software seems to have no problems with "incorrect" orientations (they just need to know whether it is an exterior or interior boundary), maybe this requirement should not be a requirement - and not be tested.

[cportele]

See #137. @heidivanparys is right, this is a bug and the test has to be updated for coordinates in a left-handed CRS (like ETRS89 lat/lon).

[carlospzurita]

We are moving forward with this issue. The pull request https://github.com/deegree/deegree3/pull/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.

[esevens]

I also get that fatal error: outer ring is clockwise. Checked in qgis node succesion is ccw crs epsg:303. Tested with a simple dataset, 2 records, simple geometries in zip the tested gml and the test report stortplaatsen_inspire_ccw_tf.zip

[fabiovinci]

Dear @esevens,

a fix for this issue is available in the BETA instance of the validator, I tested your sample dataset and it validates without errors (see test report).

Any other test and feedback is more than welcome. Please use the Validator helpdesk for reporting issues.

[JohannaOtt]

@fabiovinci Just tested with this dataset using EPSG:4258 but the error is still occurring export4258.zip

[fabiovinci]

Hi @JohannaOtt, I tested your dataset in the BETA instance and it validates (see the report) ;-)

[JohannaOtt]

Is the beta instance something else than the staging instance?

[fabiovinci]

Yes ;-) See Release strategy document

[JohannaOtt]

Manages to miss that, thanks a lot for the info!

[JohannaOtt]

@fabiovinci I can confirm the error is gone (at least for EPSG:4258). That is great news and will make the use of the validator so much more convenient!

[IoannaTsakalakidou]

@fabiovinci Is the this fix included in the v2023.2 release? I see that #950 fix is included in the release notes of this version but I am still getting this error in the validator.

My geometries are in EPSG:4258 (N-E), and the extrerior ring is CounterClockWise

[fabiovinci]

Dear @IoannaTsakalakidou,

yes, the fix is included in the last release. Could you please provide your dataset to reproduce the error?

[IoannaTsakalakidou]

Here is a sample of my dataset:

INSPIREGeology_north.zip

[fabiovinci]

Dear @IoannaTsakalakidou,

looking at your gml in QGIS, it seems that polygons with holes (e.g. ) have exterior boundaries in ClockWise order, so, in this case, the error is right.

Could you please verify?

[IoannaTsakalakidou]

To check the orientation I used 3 different methods in python, 1.built-in shapely function, 2. by plotting 3 points with the order they appear in the polygon, 3. with the signed area method (check script in attached .ipynb). They all show that the orientation is CCW.

When using the extract vertex tool in QGIS I get the same orientation as you, so ClockWise. I am just not sure what happens "behind the scenes" of this tool.

At this point, I am not sure which method's results are right, and it seems that finding the orientation of geometries is quite a vexing problem :)

- Some notes regarding the attached script: the polygon used as an example is an exterior ring I copied from the .gml. Some pre-processing is done in a text editor to turn the space separated coords into tuples of (x,y) (as required for Shapely geometries) - In case you are not working with python or jupyter notebooks I can also provide some screenshots of the methods used polygon_orientation_check.zip

[IoannaTsakalakidou]

To check the orientation I used 3 different methods in python, 1.built-in shapely function, 2. by plotting 3 points with the order they appear in the polygon, 3. with the signed area method (check script in attached .ipynb). They all show that the orientation is CCW.

When using the extract vertex tool in QGIS I get the same orientation as you, so ClockWise. I am just not sure what happens "behind the scenes" of this tool.

At this point, I am not sure which method's results are right, and it seems that finding the orientation of geometries is quite a vexing problem :)

- Some notes regarding the attached script: the polygon used as an example is an exterior ring I copied from the .gml. Some pre-processing is done in a text editor to turn the space separated coords into tuples of (x,y) (as required for Shapely geometries) - In case you are not working with python or jupyter notebooks I can also provide some screenshots of the methods used polygon_orientation_check.zip

UPDATE: The validator works as it should. The polygons are indeed ClockWise! The polygons in gml are in lat lon (e.g 50, 5). So when reading them as a shapely polygon they had to be swapped into x, y (5, 50). This is what I missed before and the orientation appeared to be CCW. Sorry for the confusion :)

[JohannaOtt]

@fabiovinci Couldn't this be closed?