Thank you guys for all your input. I apologize for not providing what my `sap` object looks like. This is the command I used to create it
sap <- SpatialPoints(matrix(c(0,0), ncol = 2)) Nonetheless, after restarting R and spending my day working on other things, gBuffer is now working as desired (and as you both described) on my older version of 0.1-2 and on the newest version. I have no idea what I was doing wrong. Cheers, Roman On Fri, Apr 15, 2011 at 6:39 PM, Colin Rundel <[email protected]> wrote: > > Which sp objects does quadsegs argument in gBuffer affect (or rather, > which > > it does not)? Based on my experiments, SpatialPoints -> SpatialPolygons > is > > not affected. I use SpatialPoints to draw circles (see below) and I > figured > > that specifying the quadsegs would alter the "roughness" of the circle > > generated (which is now SpatialPolygons). This doesn't seem to be the > case. > > Can someone expand on this? > > > > sap <- gBuffer(spgeom = sap, width = 500, quadsegs = 5) > > nrow(sap@polygons[[1]]@Polygons[[1]]@coords) #always the same, > irrespective > > of quadsegs > > > This should not be happening and when I run similar code I do get a > difference in the number of coordinates as expected using the most current > version of rgeos 0.1-4: > > > x=SpatialPoints(cbind(x=1,y=1)) > > z1=gBuffer(x,quadsegs=10) > > z2=gBuffer(x,quadsegs=5) > > nrow(z1@polygons[[1]]@Polygons[[1]]@coords) > [1] 41 > > nrow(z2@polygons[[1]]@Polygons[[1]]@coords) > [1] 21 > > There may be some weirdness with your initial SpatialPoints object that is > causing this but I don't have a plausible theory as to why. Try the above > code and see if you still have the problem and double check that your rgeos > is up to date. > > -Colin -- In God we trust, all others bring data. [[alternative HTML version deleted]] _______________________________________________ R-sig-Geo mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-geo
