[R-sig-Geo] Holes in polygons disappear after performing checkPolygonsHoles from maptools

[Roger Bivand]

This posting turned out to be of major importance, and the conclusion 
below is a star case of the importance of contributing postings with 
well-constructed reproducible examples. Thanks to Grigory's careful 
contribution, a potential weakness in sp for R >= 3.1 has been found and 
corrected, details below.

On Fri, 3 Apr 2015, Grigory Alexandrovich wrote:

>
>
> Am 03.04.2015 um 20:42 schrieb Roger Bivand:
>>  On Fri, 3 Apr 2015, Grigory Alexandrovich wrote:
>> > 
>> >  Am 03.04.2015 um 13:16 schrieb Roger Bivand:
>> > >   On Fri, 3 Apr 2015, Grigory Alexandrovich wrote:
>> > > 
>> > > >   Am 02.04.2015 um 22:24 schrieb Roger Bivand:
>> > > > >   On Thu, 2 Apr 2015, Roger Bivand wrote:
>> > > > > > > >   On Thu, 2 Apr 2015, Edzer Pebesma wrote:
>> > > > > > > > > > > > > > > > > >    On 04/01/2015 08:03 PM, Grigory 
>> > >  Alexandrovich wrote:
>> > > > > > > >    Hello all,
>> > > > > > > > >    I encountered the following unexpected result using
>> > > > > > >   checkPolygonsHoles:
>> > > > > > > > >    # attach the worldmap as SpatialPolygonsDataFrame from 
>> > >  the
>> > > > > > > package >    maptools
>> > > > > > > >    library(sp)
>> > > > > > > >    library(maptools)
>> > > > > > > >    data(wrld_simpl)
>> > > > > > > > >    # get a polygon with a hole
>> > > > > > > >    shape_with_hole <- wrld_simpl[5,]
>> > > > > > > > >    # plot it (hole is left white, surrounded by blue color)
>> > > > > > > >    plot(shape_with_hole, col = "blue")
>> > > > > > > > >    # perform checkPolygonsHoles
>> > > > > > > >    shape_with_hole at polygons <- 
>> > >  lapply(shape_with_hole at polygons,
>> > > > > > > >    checkPolygonsHoles)
>> > > > > > > > >    # plot again, now holes aren't recognized as such
>> > > > > > > >    plot(shape_with_hole, col = "blue")
>> > > > > > > > >    # and even the original SpatialPolygonsDataFrame 
>> > >  object is
>> > > > > > >   changed !?
>> > > > > > > >    plot(wrld_simpl[5,], col = "blue")
>> > > > > > > > >    One irritating side effect here is that the original 
>> > >  object
>> > > > > > >   wrld_simpl
>> > > > > > > >    is also changed. This result looks to me like a bug, or 
>> > >  have I
>> > > > > > >   missed
>> > > > > > > >    something?
>> > 
>> 
> Roger, actually I didn't run update.packages()  on the corresponding spatial 
> packages yet, since I installed them maybe two-three months ago.
> Anyway, I just installed the newest R Version (3.1.3)  and the required 
> packages and  the problem doesn't appear any more.
> So one should take care using older versions of the rgeos/rgdal packages.

The identification of a modification without assignment, resulting in the 
ring direction of holes being flipped in maptools::checkPolygonsHoles 
using rgeos, was correct. Forthcoming sp 1.1-0 resolves the issue.

The issue was that some Spatial* objects (lines and polygons) involve new 
style classes with slots with lists of member objects. R says that it 
passes objects by value, but actually passes by reference in C, counting 
whether an object is modified and so needs to be duplicated. Before R 3.1, 
the internal mechanisms for copying objects in C functions were very 
defensive (counting more than strictly necessary), so reference chains 
were broken by possibly excessive copying.

The C code for handling Polygons and Polygon objects was added to sp in 
2009, and is also used in rgdal and rgeos.

In 2014, R 3.1 changed the way that the need for automatic duplication of 
objects was counted, so that sp code previously protected not by design 
but by R's defensive copying strategy became exposed. In this particular 
case, maptools::checkPolygonsHoles calls sp functions to turn a Polygons 
object into a SpatialPolygons object - where each Polygons object had one 
Polygon object with unknown hole status, but the underlying C code 
did not duplicate these object components explicitly.

The forthcoming sp version (now on R-forge), in addition to other changes, 
introduces explicit duplication in C code, and the behaviour reported here 
for R 3.1 and later is now corrected, so that the same results will be 
available without change across R versions.

It is unlikely that the lack of duplication has had major impacts, as it 
does not seem to affect rgdal or rgeos, but did affect the manipulation of 
objects using sp in some limited cases.

Without Grigory's clear report, analysis and testing by Ezder Pebesma and 
myself, and advice from R-core members Luke Tierney and Michael Lawrence, 
we would not have resolved this issue.

We remain crucially dependent on users reporting unexpected behavious 
clearly!

Roger


>
> Thank you and Edzer for the concurrence and your contributions to R's spatial 
> analysis toolkit.
>
> Grigory
>
>
>
>
>
>

-- 
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 91 00
e-mail: Roger.Bivand at nhh.no