[OGC] Polygon: fix rings order (Request in QGIS) #8658
Comments
|
The "after" video is not good, since we change slighty the behaviour. |
Which if I understood is "that if the exterior ring is in one direction, all interior rings are in the opposite direction, and the parts follow the direction of the exterior ring"? Exterior rings of different features do not necessarily follow the same direction, right? |
Exact
Exact
Because, if you draw with an arrow style, you'll see the orientation of your ring potentially inverted and can cause interrogation.
In https://docs.qgis.org/3.28/fr/docs/user_manual/working_with_vector/editing_geometry_attributes.html#add-part and https://docs.qgis.org/3.28/fr/docs/user_manual/working_with_vector/editing_geometry_attributes.html#add-ring |
in polygon part and ring geometries fixes qgis#8658
Request for documentation
From pull request qgis/QGIS#55306
Author: @lbartoletti
QGIS version: 3.36
[OGC] Polygon: fix rings order
PR Description:
Description
I'm reaching out regarding an important initiative aimed at rectifying an anomaly observed in the digitization process within QGIS. Specifically, the adherence to OGC standards, upon which QGIS relies, dictates a distinct orientation requirement for polygon rings.
As per the OGC norm, the exterior boundary LinearRing must define the "top" of the surface, following a counterclockwise traversal along the boundary. Conversely, interior LinearRings should exhibit an opposite orientation, appearing clockwise when viewed from the "top."
Presently, there's a lack of verification within QGIS to ensure adherence to this prescribed behavior. To address this issue, I'll be initiating a series of PR; focusing only on the digitization process here. The primary goal is to align the behavior more closely with the established standards.
Nevertheless, I intend to maintain flexibility in the codebase, allowing for the preservation of the previous behavior programmatically. This approach aims to avoid directly enforcing orientation within the *Polygon classes. So, classes still accept "unordered" rings.
Before:
before-converted.mp4
After:
after-converted.mp4
PS: The motivation behind this is that certain tools perform stricter checks than the ones we currently conduct or those performed with GEOS.
PS2: I'm aware that ESRI Shapefile is CW unlike OGC, but should be a provider role to check this part?
TODO:
Commits tagged with [need-docs] or [FEATURE]
The text was updated successfully, but these errors were encountered: