Roger--
0.3-2 looks great!
I ran the 0.3-2 version from r-forge against a vegetation map with ~7k
polygons, where either ~600 or ~3k polygons shrunk to nothing with negative
buffering (depending on buffer width).  0.3-2 gives me the right number of
polygons in the results ("right" being the same as I obtained with my
previous code that explicitly tested for is.null(coords)).
I have the rest of my production code running against the results of this
gBuffer: gIntersection to clip out steep slopes, then spsurvey::grts() with
a sample design stratified by vegetation class.

I'll try to do complete benchmark when these production runs are finished,
but 0.3-2 clearly ran substantially faster than geos 0.3-1 for this file,
even when I didn't do my is.null checking with 0.3-1.

Tom

R version 3.0.1 (2013-05-16)
Platform: x86_64-w64-mingw32/x64 (64-bit)

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] rgeos_0.3-2  rgdal_0.8-11 sp_1.0-13

loaded via a namespace (and not attached):
[1] grid_3.0.1      lattice_0.20-15



On Sun, Oct 6, 2013 at 12:53 PM, Roger Bivand <Roger.Bivand@nhh.no> wrote:

> On Thu, 3 Oct 2013, Barry Rowlingson wrote:
>
>  On Thu, Oct 3, 2013 at 2:29 PM, Roger Bivand <Roger.Bivand@nhh.no> wrote:
>>
>>  Yes, but ...
>>>
>>> The user gets a SpatialPolygonsDataFrame object with the data slot
>>> intact,
>>> but some of the polygons are clearly now invalid. Should we do
>>> book-keeping to only retain the data slot rows for valid polygons, only
>>> return the subset of valid polygons, or proceed as now, and have the user
>>> do:
>>>
>>> plot(b[gArea(b, byid=TRUE) > 0,])
>>>
>>> What makes more sense? I'm open to suggestions ...
>>>
>>
>>
> rgeos 0.3-2 is now on CRAN, and the CRAN Windows and OSX binary packages
> should be built soon. The changes made in rgeos should now prevent invalid
> geometries without valid representation in sp classes, such as empty
> polygons with no coordinates, being built. In gBuffer(), any output GEOM
> empty objects are removed before their conversion back to sp form,
> retaining the ids of the non-empty objects.
>
> Please report back if these changes cause untoward effects in production
> code.
>
> Roger
>
>
>  I'm first wondering what the source of the invalidity is here. What
>> does the underlying GEOS code return from one of these operations?
>> Does it have a valid NULL polygon feature concept? If so, then I'd
>> like to see that carried through into sp-class objects.
>>
>> Its not a sufficient condition that the area = 0 - a polygon of three
>> coincident points has area=0, but a big negative buffer should be a
>> geometry without even points in it...
>>
>> Barry
>>
>>
> --
> Roger Bivand
> Department of Economics, NHH Norwegian School of Economics,
> Helleveien 30, N-5045 Bergen, Norway.
> voice: +47 55 95 93 55; fax +47 55 95 95 43
> e-mail: Roger.Bivand@nhh.no
>
> ______________________________**_________________
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/**listinfo/r-sig-geo<https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
>

	[[alternative HTML version deleted]]

