ST_IsPolygonCCW for invalid inputs

[Greg Troxel]

Paul Ramsey <pramsey at cleverelephant.ca> writes:

> Grrr, I'm trying to fix https://trac.osgeo.org/postgis/ticket/5754 which on
> the surface is quite simple, but it actually exposes a bit of a rats nest
> of bad logic.
>
> I have a good fix that mostly works, but now I have a "big" regression: the
> old function returned "true" when handed non-polygonal inputs.

The spec for ST_IsPolygonCW

  https://postgis.net/docs/ST_IsPolygonCW.html

says

  Returns true if all polygonal components of the input geometry use a
  clockwise orientation for their exterior ring, and a counter-clockwise
  direction for all interior rings.

  Returns true if the geometry has no polygonal components. 

which is perhaps odd, but seems well defined.

It seems intended that a geometry passes ST_IsPolygonCW unless there is
a polygon which failes to be CW.

> My feeling is that a geometry is "clockwise" if it is (a) a polygon or
> polygonal and (b) the outer ring is clockwise and (c) the inner rings are
> anti-clockwise. Otherwise it's not oriented. (My changes for this work
> mostly centered around the fact that a geometry can have one of three
> orientations: clockwise, anticlockwise, and none. That made the logic, I
> think, more straightforward to understand.)

That certainly makes sense.

> So, this change is for 3.7 and I'd like to change the behaviour for
> non-polygonal inputs to the ST_IsPolygonCCW and ST_IsPolygonCW functions.

So you want to change the docs to say

  Returns true if all components of the input geometry use are polygons,
  and each has a clockwise orientation for their exterior ring, and a
  counter-clockwise direction for all interior rings.

  Returns false if any component of the input geometry is not a polygon,
  or if there is a polygon that does not meet the rules in the first
  paragraph.

I wonder why the specification was written the way it was.