Skip to content

rgeos::gBuffer() fails when passed a SpatialPolygonsDataFrame containing a single multi-part @Polygons object.

6 messages · Josh O'Brien, Roger Bivand

#
Hello,

Not sure if this would be considered a bug, but it did recently bite
me (and might bite others using gBuffer(..., byid=TRUE)
programatically).


    library(sp)
    library(rgdal)
    library(rgeos)

    ## Example SpatialPolygonsDataFrame
    x <- readOGR(system.file("etc/shapes", package="spdep"), "sids")[c(89,28),]
    plot(x, col=c('dodgerblue', 'wheat'))

    ## Works fine on object with multiple @Polygons in @polygons, even
    ## if one of the @Polygons is multi-part
    gBuffer(x, width=0.01, byid=TRUE)

    ## Works with a single single-part @Polygons object in @polygons
    gBuffer(x[1,], width=0.01, byid=TRUE)

    ## Fails with a single _multi-part_ @Polygons object in @polygons
    gBuffer(x[2,], width=0.01, byid=TRUE)


Thanks (and please let me know an rgeos-specific note like this would
be better posted elsewhere),

Josh O'Brien
#
Oops. The post's title should have read "rgeos::gBuffer( , byid=TRUE)
fails when...". (I inadvertently left out the `byid=TRUE` bit).

My apologies.
On Mon, Feb 8, 2016 at 9:59 AM, Josh O'Brien <joshmobrien at gmail.com> wrote:
#
On Mon, 8 Feb 2016, Josh O'Brien wrote:

            
Thanks for a reproducible example - for rgeos 0.3-14 this gives a 
segfault, in 0.3-16 an error as the data.frame has only one row, but three 
Polygons objects are returned. As you note, the issue is triggered by 
byid=TRUE but there is only one input object; only one buffer is created, 
around the NE island.

I'll look into this - it'll need debugging in C, close to recent bug-fixes 
(then concerned with pre-sp-MultiPoint object signalling - multiple 
objects making up features).

And yes, this is a reasonable place to report, it should give users a 
realistic view of how many corner cases actually exist and require 
someone's attention.

Roger

  
    
#
On Mon, 8 Feb 2016, Roger Bivand wrote:

            
I have committed a fix to R-Forge (checking whether the length of spgeom 
== 1 and byid == TRUE, if so set byid=FALSE and warn). The problem was 
visible in the C code, but there we don't have an sp-class generic 
"length" measure of the # features, so the modification is at the R level.

Which OS would you like to test under?

Best wishes,

Roger

  
    
#
On Tue, Feb 9, 2016 at 5:01 AM, Roger Bivand <Roger.Bivand at nhh.no> wrote:
I'm using it on Windows (with R-3.2.3) and Ubuntu 14.04 (with
R-3.2.2), but am afraid I don't know how to install from sources on
either. I'll test under both, but if I had to pick one, would go with
Ubuntu, since that's where I'm doing my production work.

Thanks so much,

- Josh
4 days later
#
On Tue, 9 Feb 2016, Josh O'Brien wrote:

            
After some exchanges off-list, rgeos 0.3-17 has now reached CRAN with 
modifications handling the problem. Once again, the key was the simple, 
reproducible example.

Thanks to Josh for his help,

Roger