When is a circle not a circle

[dmkaplan2000]

Hi,

I recently used st_buffer on a lon,lat point and then calculated the area of that circle and was surprised to find that it didn't agree with the standard formula pi*r^2 even for very small circles. The "error" wasn't huge, but more than 1%, which seems like a lot to me. Am I perhaps misunderstanding how things work? The specific code I ran was:

library(sf) # version 1.0.21
sf_use_s2(TRUE) # s2 version 1.1.9
x = data.frame(lon=0,lat=0) |> st_as_sf(coords=c("lon","lat"),crs=4326) |> st_buffer(units::as_units(1,"m"))
y = st_area(x)
y # = 3.191512 [m^2] ; Should be equal to pi

error = (as.numeric(y)-pi)/pi
error # = 0.01588973 = 1.6%

I would think st_buffer would get a closer answer than this, but perhaps I am mistaken.

Note that though I could probably convert to UTM to get a better answer, my real data has a set of points that are spread all over the globe making using UTM complicated.

Thanks,
David

[edzer]

Please do read the ?st_buffer docs and search for "buffer", this should explain it. The S2 engine returns a polygon around a number of S2 cells that contain the buffer, and hence is larger; number of cells can be controlled but has a default. The GEOS engine will return line segments between points ON the circle, and so will always be smaller than the true buffer, the number of segments can be controlled and is of influence.

[dmkaplan2000]

I did look at the help for st_buffer, but I must admit it was a bit cryptic on these details without knowing the arcana of s2 and geos. I see that I can control the number of line segments geos uses, but s2 is convenient for a global dataset in lon,lat. For s2, I now see that I can supply the max_cells argument of s2_buffer_cells to st_buffer.

library(sf) # version 1.0.21
sf_use_s2(TRUE) # s2 version 1.1.9
x = data.frame(lon=0,lat=0) |> st_as_sf(coords=c("lon","lat"),crs=4326) |> st_buffer(units::as_units(1,"km"),max_cells=1e5)
y = st_area(x) |> units::set_units("km^2")
y # = 3.141971 [km^2] 

error = (as.numeric(y)-pi)/pi
error # = 0.0001205412 = 0.01%

Thanks,
David

[edzer]

Let me know if you have suggestions for improving the documentation!

[dmkaplan2000]

It is hard to strike the balance between too little and too much info. I would say that adding the sentences you had in your response would not hurt things:

The S2 engine returns a polygon around a number of S2 cells that contain the buffer, and hence will always be slightly large than the true buffer; number of cells can be controlled using the max_cells parameter. The GEOS engine will return line segments between points on the circle, and so will always be slightly smaller than the true buffer; the number of segments can be controlled via the nQuadSegs parameter.

I would also suggest perhaps adding some version of my example to the examples of the function. Seeing an example of the effect of max_cells (and perhaps nQuadSegs) on the final area would seem useful.

Thanks!

[edzer]

Thanks; should be fixed in 92bc3d1