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 <rundel@gmail.com> 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]]

