Bug report #6283

no reversion of direction when digitizing polygons counter clockwise in PostGIS

Added by Bernhard Ströbl over 7 years ago. Updated about 4 years ago.

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.

digitizing_direction.qml - qml showing the digitizing direction of the polygon boundary (2.39 KB) Bernhard Ströbl, 2012-08-30 01:54 AM

double_line.qml - line style with two lines (2.28 KB) Bernhard Ströbl, 2012-10-08 03:25 AM

History

#1 Updated by Paolo Cavallini over 7 years ago

  • Target version set to Version 2.0.0

#2 Updated by Giovanni Manghi over 7 years ago

  • Crashes QGIS or corrupts data changed from Yes to No

#3 Updated by Jürgen Fischer over 7 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 over 7 years ago

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 over 7 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 over 7 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 5 years ago

  • Target version changed from Version 2.0.0 to Future Release - Lower Priority

#8 Updated by Médéric RIBREUX about 4 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 about 4 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.

Also available in: Atom PDF