Bug report #6283
no reversion of direction when digitizing polygons counter clockwise in PostGIS
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | Digitising | ||
| Affected QGIS version: | master | Regression?: | No |
| Operating System: | OpenSUSE 64bit | Easy fix?: | No |
| Pull Request or Patch supplied: | No | Resolution: | invalid |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 15583 |
Description
QGIS allows digitizing polygons either clockwise (cw) or counter clockwise (ccw).
AFAIK it is a general rule that walking along a polygon's edge in digitizing direction the inside of the polygon is to the right, that means that the polygon's exterior boundary is to be digitized cw and any hole ccw. QGIS obeyes this rule for shapefiles, i.e. when saving a ccw-digitized polygon the direction is reverted. For a PostGIS layer the polygon is saved ccw.
To reproduce: digitize a polygon ccw in both a shape file layer and a PostGIS layer and save the layer. Visualize the layer with the attached style file.
History
#1
Updated by Paolo Cavallini about 12 years ago
- Target version set to Version 2.0.0
#2
Updated by Giovanni Manghi about 12 years ago
- Crashes QGIS or corrupts data changed from Yes to No
#3
Updated by Jürgen Fischer about 12 years ago
- Resolution set to invalid
- Priority changed from High to Normal
AFAIK there's no such rule for PostGIS as it explicitly knows which rings are exterior and which are interior and doesn't need to decide on the ring orientation. What problems does it impose for you?
#4
Updated by Bernhard Ströbl about 12 years ago
- File double_line.qml added
Jürgen Fischer wrote:
AFAIK there's no such rule for PostGIS as it explicitly knows which rings are exterior and which are interior and doesn't need to decide on the ring orientation. What problems does it impose for you?
Agreed, PostGIS and QGIS both work as expected no matter which direction the polygon outline follows. The problem arises when symbolizing only the outline: imagine you have a thick colored line and a thin black line and no fill. The thin black line should be drawn as the outer boundary and the thick colored line is supposed to be inside of the polygon to indicate inside and outside (remember there is no fill) when zoomin in; holes are especially problematic: what is the hole and what is the polygon?
I attached a qml file to visualize.
#5
Updated by Sandro Santilli about 12 years ago
Zoom in more, until you see a single line. Then tell me: is that the hole or is that the polygon ? Is it clockwise or counterclockwise ? You can't tell.
I suggest you create two layers, one with shells and one with holes, and style differently.
Anyway an ST_ForceRHR function in PostGIS is available if you want.
#6
Updated by Bernhard Ströbl about 12 years ago
Sandro Santilli wrote:
Zoom in more, until you see a single line. Then tell me: is that the hole or is that the polygon ? Is it clockwise or counterclockwise ? You can't tell.
It does not matter if it is clockwise or counterclockwise but it should follow a rule. When zooming in until you only see a single line and you use the style I provided you can tell if the inside is to the left or right of the line and that does matter! If the line direction is random you cannot tell.
I suggest you create two layers, one with shells and one with holes, and style differently.
This would not be a solution as the goal is data modelling and not data display. The data will be used to make analyses, too, so if there is a hole I need a hole. Besides, if the digitizing direction is random I could still not use my style.
Anyway an ST_ForceRHR function in PostGIS is available if you want.
I was not aware of this function, thank you very much for the hint. I will create a trigger for my polygon tables to implement it.
Just for clarification: I was assuming that QGIS is correcting the direction if editing a shape file (I know from my own programming experience that shape is accepting polygons digitized the "wrong" way, too. There are side effects using these shape files, though). I wanted to have this function applied to the PostGIS data provider, too. If this is not the case and whatever library (ogr?) does correct the direction for shape files we could close this ticket.
#7
Updated by Jürgen Fischer over 10 years ago
- Target version changed from Version 2.0.0 to Future Release - Lower Priority
#8
Updated by Médéric RIBREUX almost 9 years ago
- Status changed from Open to Feedback
Hello, bug triage...
here is what the Shapefile standard says (on page 12):
The order of vertices or orientation for a ring indicates which side of the ring is the interior of the polygon. The neighborhood to the right of an observer walking along the ring in vertex order is the neighborhood inside the polygon. Vertices of rings defining holes in polygons are in a counterclockwise direction. Vertices for a single, ringed polygon are, therefore, always in clockwise order. The rings of a polygon are referred to as its parts
It seems that polygon orientation for Shapefiles in QGIS are respecting the "standard".
In the past, I have tried to implement a reverse polygon algorithm and it worked in QGIS for anything that wasn't shapefile. For this file format, the geometries where modified on save to respect the ESRI "standard". For ESRI shapefiles, you can't reverse polygons (even if you don't have hole) !
But I think this rule should not apply to any other format because sometimes, it is very valuable to be able to change a polygon orientation (with holes or not).
I think we can close this bug as it free orientation for polygons is much more a feature than a bug...
#9
Updated by Bernhard Ströbl almost 9 years ago
- Status changed from Feedback to Closed
Hi,
maybe I was under the impression that the shape-file standard is a general standard. Thanks for pointing this out. I am working with triggers now, so we can close this.