[PROJ] Geodesic buffers/offsets?

[Edzer Pebesma]

On 05/05/2021 00:23, Nyall Dawson wrote:
> The approaches/advice I've found so far fall into these broad categories:

[...]

> - use a geographic focused library like s2 (but that has the
> limitation in that it's spherical approximations only, not
> ellipsoidal)


In R package sf we're planning to replace GEOS with s2 as a back-end for 
(most) geometric operations when the user works with ellipsoidal 
coordinates, so we can stop emitting warnings all the time for this case.

The buffer algorithm in s2 is quite different from that in GEOS: it 
returns the union of a set of S2 cells, which are more or less close to 
rectangular and cover the sphere. An example of such a buffer is found 
here:

https://keen-swartz-3146c4.netlify.app/sf.html#fig:orangebuffer (scroll 
half a page up to see fig 7.3)

This example used the (current) default of using 1000 cells to 
approximate the buffer region. For a very small buffer around a long 
line (e.g. approximate the road surface when the road is available as a 
LINESTRING) many more cells may be needed, for such cases I think s2 may 
not be very useful, or in any case require a lot of computational 
resources and knowledge from the user.

For an algorithm that would go straight for the buffer geometry (without 
cell approximation) I would find it interesting how for practical use 
cases these two approximations would compare:
(i) spherical vs. ellipsoidal computations
(ii) approximating curved lines with piece-wise straight segments.

Of course (ii) can be made to go for zero, but that's not practical.

Best regards,
-- 
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48151 Muenster, Germany
Phone: +49 251 8333081