[postgis-users] WKT polygon and interior ring orientation

Clay, Bruce bclay at ball.com
Mon Nov 3 10:52:45 PST 2008 

Not that PostGis would have to follow Oracle but they do use a certain
order and that has tripped us up more than once using GDAL.

Reference to http://download.oracle.com/docs/html/A96630_01/sdo_util.htm

"For a polygon with holes, its first subelement is its exterior ring,
its second subelement is its first interior ring, its third subelement
is its second interior ring, and so on. For example, in the polygon with
a hole shown in Figure 2-3 in Section 2.3.2, the exterior ring is
subelement 1 and the interior ring (the hole) is subelement 2". 


And 

"For a polygon with one or more holes, the returned geometry
representing an extracted interior ring is "reoriented" so that its
vertices are presented in counterclockwise order (as opposed to the
clockwise order within an interior ring)". 

-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Monday, November 03, 2008 1:18 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] WKT polygon and interior ring orientation

Since PostGIS explicitly keeps track of whether a ring is exterior or
interior, the orientation is neither here nor there. Internally I
think it matters not at all. For ST_As*() functions, I can see
enforcing orientation as a useful thing, since that would remove the
need for clients to do so post-facto, if they happen to have their own
orientation requirement. On the other hand, if a client inserts a
non-oriented polygon and then gets it back orients, that violates the
principle of "minimal screwing with people's data" that we are trying
to hew to.

P.

PS, here's a quick proof that we currently don't care:

pramsey=# select st_astext(st_geometryfromtext('POLYGON((0 0, 0 10, 10
10, 10 0, 0 0), (5 5, 5 6, 6 6, 6 5, 5 5))'));
                        st_astext
----------------------------------------------------------
 POLYGON((0 0,0 10,10 10,10 0,0 0),(5 5,5 6,6 6,6 5,5 5))
(1 row)

PPS, and here's an enforced version:

pramsey=# select st_astext(st_forcerhr(st_geometryfromtext('POLYGON((0
0, 0 10, 10 10, 10 0, 0 0), (5 5, 5 6, 6 6, 6 5, 5 5))')));
                        st_astext
----------------------------------------------------------
 POLYGON((0 0,0 10,10 10,10 0,0 0),(5 5,6 5,6 6,5 6,5 5))
(1 row)

PPPS, this raises an interesting code-trawling exercise, to see if we
have a surfeit of "is this ring oriented" tests in our functions,
since if we do, then orienting at load time would be a time saver
later on.

On Mon, Nov 3, 2008 at 9:34 AM, Tara Athan <tara_athan at alt2is.com>
wrote:
> My apologies for not stating my question clearly. I am not questioning
> whether polygon orientation must be counter-clockwise or clockwise- it
is
> clear from the specs, v1.2.0 at least, that either is acceptable,
although
> the result would be a change in the normal to the surface.
>
> However OGC v1.2.0 part 1 does make it clear that the interior rings
should
> be oriented in the "opposite" direction as the the exterior rings.
This
> would be consistent with a RHR convention because when traversing a
hole the
> RHR would cause the switch from clockwise to counter-clockwise, or
v.v.
>
> The question them becomes- does the software implement this
convention?  If
> there is no error in the PostGIS documentation, then the example of a
> polygon with a hole
> POLYGON((0 0,4 0,4 4,0 4,0 0),(1 1, 2 1, 2 2, 1 2,1 1))
> that is given in the PostGIS documentation would appear to violate the
OGC
> v1.2.0  as well as the RHR (or the LHR).
> Or perhaps it is a typo.
>
> But surely it matters?
>
> Tara
>
>
> Kevin Neufeld wrote:
>
> If you look at the OGC spec v.1.1.0 and the current v1.2.0, Part 2,
the only
> reference to orientation is in a footnote, "Polygon rotation is not
defined
> by this specification; actual polygon rotation may be in a clockwise
or
> counter-clockwise direction."
>
> Prior versions don't even mention orientation.
>
> http://www.opengeospatial.org/standards/sfs
>
> It's my understanding that polygon orientation doesn't really matter
and
> even varies from one database vendor to another.  Martin Davis may be
able
> to answer the whys better, but since the specs didn't specify at the
time, I
> believe JTS/GEOS chose to follow the somewhat more accepted
orientation and
> follow the Right-Hand-Rule - that is, the orientation of the rings are
such
> that the thing they are bounding is to the right.  In particular, an
> exterior ring is clockwise and interior rings are counter clockwise.
> PostGIS even has a forceRHR for polygons ... but like I said, I don't
think
> it really matters.
>
> -- Kevin
>
> Tara Athan wrote:
>
> Noobie question here:
> I am trying to understand WKT so I can build my own polygons from GPS
points
> for entry by SGL commands. In reading the OGC specification
> http://portal.opengeospatial.org/files/?artifact_id=18241
> I thought I understood it to say that interior rings should have a
clockwise
> orientation,
>
> "6.1.11.1 Description
> A Polygon is a planar Surface defined by 1 exterior boundary and 0 or
more
> interior boundaries. Each interior
> boundary defines a hole in the Polygon. A Triangle is a polygon with 3
> distinct, non-collinear vertices and no
> interior boundary.
> The exterior boundary LinearRing defines the "top" of the surface
which is
> the side of the surface from which the
> exterior boundary appears to traverse the boundary in a counter
clockwise
> direction. The interior LinearRings will
> have the opposite orientation, and appear as clockwise when viewed
from the
> "top", "
>
> but the example given in the PostGIS documentation
>
http://postgis.refractions.net/documentation/manual-1.3/ch04.html#RefObj
ect
> gives an interior ring with counter-clockwise orientation. Am I
missing
> something?
>
> Thanks, Tara
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
> ________________________________
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.175 / Virus Database: 270.8.5/1759 - Release Date:
10/31/2008
> 4:10 PM
>
>
>
> --
> My e-mail delivery has been unreliable lately, so I am asking for
> return receipts from all my email messages.
> OK'ing the return receipt lets me know that my message was delivered.
> Thank you.
>
> Tara Athan
> Principal, Alternatives to Invasive Species
> tara_athan [AT] alt2is.com
> 707-485-1198
> PO Box 415
> Redwood Valley, CA 95470
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users



This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

More information about the postgis-users mailing list