Different packages concerned with spatial data use different polygon
specifications, which sometimes becomes very confusing (see Details below).
To be compatible with the various polygon classes, package polyCub
uses an S3 class "xylist", which represents
polygons by their core feature only, a list of lists of vertex coordinates
(see the "Value" section below).
The generic function xylist can deal with the
following polygon classes:
"owin" from package spatstat
"gpc.poly" from package
rgeos (or gpclib)
"'>Polygons" from package sp
(as well as "'>Polygon" and
"'>SpatialPolygons")
The (somehow useless) default xylist-method
does not perform any transformation but only ensures that the polygons are
not closed (first vertex not repeated).
xylist(object, ...)# S3 method for owin
xylist(object, ...)
# S3 method for gpc.poly
xylist(object, ...)
# S3 method for SpatialPolygons
xylist(object, reverse = TRUE, ...)
# S3 method for Polygons
xylist(object, reverse = TRUE, ...)
# S3 method for Polygon
xylist(object, reverse = TRUE, ...)
# S3 method for default
xylist(object, ...)
an object of one of the supported spatial classes.
(unused) argument of the generic.
logical (TRUE) indicating if the vertex order of the
sp classes should be reversed to get the xylist/owin
convention.
Applying xylist to a polygon object, one gets a simple list,
where each component (polygon) is a list of "x" and "y"
coordinates. These represent vertex coordinates following spatstat's
"owin" convention (anticlockwise order without repeating any vertex).
The opposite vertex order can be retained for the sp-classes
by the non-default use with reverse=FALSE.
Different packages concerned with spatial data use different polygon specifications with respect to:
do we repeat the first vertex?
which direction represents holes?
Package overview:
Repeat first vertex at the end (closed), anticlockwise = hole, clockwise = normal boundary
do not repeat first vertex,
anticlockwise = normal boundary, clockwise = hole. This convention is also
used in xylist.
Unfortunately, there seems to be no convention
for the specification of polygons of class "gpc.poly".