Ambiguous ST_ForceLHR

[Jukka Rahkonen]

Hi,

I wonder if it would be better to rename ST_ForceLHR into
ST_ForcePolygonCW or something because the right-hand and left-hand
rules are ambiguous.

In https://www.gaia-gis.it/gaia-sins/spatialite-sql-latest.html is is
defined as
"Any Polygon Ring will be oriented accordingly to Left Hand Rule
(Exterior Ring will be clockwise oriented, and Interior Rings will be
counter-clockwise oriented)."

In PostGIS the same thing is called as Right Hand Rule
http://postgis.net/docs/ST_ForceRHR.html
"Forces the orientation of the vertices in a polygon to follow a
Right-Hand-Rule, in which the area that is bounded by the polygon is to
the right of the boundary. In particular, the exterior ring is
orientated in a clockwise direction and the interior rings in a
counter-clockwise direction. This function is a synonym for
ST_ForcePolygonCW"

I know that in mathematics the right hand rule means winding
counter-clockwise https://en.wikipedia.org/wiki/Right-hand_rule but the
description used for shapefiles "The neighborhood to the right of an
observer walking along the ring in vertex order is the neighborhood
inside the polygon" is also called as right hand rule even it means just
the opposite.

Current situation with PostGIS and Spatialite having a different
interpretation is odd. How about to stop using ST_ForceLHR and rename it
to ST_ForcePolygonCW which is understood similarly by PostGIS?

-Jukka Rahkonen-

[a.fu...@lqt.it]

On Fri, 13 Oct 2017 13:01:19 +0300, Jukka Rahkonen wrote:
> Hi,
>
> I wonder if it would be better to rename ST_ForceLHR into
> ST_ForcePolygonCW or something because the right-hand and left-hand
> rules are ambiguous.
>
> In https://www.gaia-gis.it/gaia-sins/spatialite-sql-latest.html is is
> defined as
> "Any Polygon Ring will be oriented accordingly to Left Hand Rule
> (Exterior Ring will be clockwise oriented, and Interior Rings will be
> counter-clockwise oriented)."
>
> In PostGIS the same thing is called as Right Hand Rule
> http://postgis.net/docs/ST_ForceRHR.html
> "Forces the orientation of the vertices in a polygon to follow a
> Right-Hand-Rule, in which the area that is bounded by the polygon is
> to the right of the boundary. In particular, the exterior ring is
> orientated in a clockwise direction and the interior rings in a
> counter-clockwise direction. This function is a synonym for
> ST_ForcePolygonCW"
>

Hi Jukka,

just to add more confusion PostGIS itself supports ST_ForceLHR(),
but only when using the SFCGAL backend:

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

(I was unable to understand what this exactly means because the
HTML page is really vague and elusive).

as you stated, the conventional interpretation of left- and
right-hand rules are highly ambiguous, inconsistent and
contradictory between different implementations.

suppressing a well established function name never is a good
policy, because this way many existing SQL scripts could suddenly
stop working.
SQL scripts are usually deployed by big organizations on remote
servers, and are usually executed at fixed time intervals under
"cron" planning in a completely automatic and unattended mode:
so any traumatic breakage should be always carefully avoided.

I suppose that we could reasonably adopt the following corrections:

1. leave ST_ForceLHR() untouched, so not to break backward
compatibility.
2. add a new ST_ForceRHR() working the opposite way.
3. add ST_ForcePolygonCW() as an alias name to ST_ForceLHR()
4. add ST_ForcePolygonCCW() as an alias name to ST_ForceRHR()
5. clearly stating in the accompanying documentation that
ST_ForceLHR() and ST_ForceRHR() in SpatiaLite have the
opposite interpretation than in PostGIS, whilst
ST_ForcePolygonCW() and ST_ForcePolygonCCW() have
exactly the same interpretation in both DBMS.

bye Sandro

[Even Rouault]

Hi Sandro,

 

> 1. leave ST_ForceLHR() untouched, so not to break backward

> compatibility.

> 2. add a new ST_ForceRHR() working the opposite way.

 

Doesn't seem to be a great idea to add a function that will add more cause confusion and would do the contrary of the PostGIS function of same name. Just introducing ST_ForcePolygonCCW() is probably better.

 

> 3. add ST_ForcePolygonCW() as an alias name to ST_ForceLHR()

> 4. add ST_ForcePolygonCCW() as an alias name to ST_ForceRHR()

> 5. clearly stating in the accompanying documentation that

> ST_ForceLHR() and ST_ForceRHR() in SpatiaLite have the

> opposite interpretation than in PostGIS, whilst

> ST_ForcePolygonCW() and ST_ForcePolygonCCW() have

> exactly the same interpretation in both DBMS.

 

>

> bye Sandro

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com

[a.fu...@lqt.it]

On Fri, 13 Oct 2017 13:05:34 +0200, Even Rouault wrote:
> Hi Sandro,
>
>> 1. leave ST_ForceLHR() untouched, so not to break backward
>> compatibility.
>>
>> 2. add a new ST_ForceRHR() working the opposite way.
>>
> Doesn't seem to be a great idea to add a function that will add more
> cause confusion and would do the contrary of the PostGIS function of
> same name. Just introducing ST_ForcePolygonCCW() is probably better.
>

Even,

you are absolutely right ;-)

bye Sandro