[PROJ] Geodesic buffers/offsets?

[Greg Troxel]

Nyall Dawson <nyall.dawson at gmail.com> writes:

> Something which I get asked on a recurring basis by users is how to
> create geometry buffers using a real-world distance on a geographic
> dataset. E.g. creating a 100km buffer on a linestring in such a way
> that the geodesic distances between the buffer and original line are
> always 100km.

It's interesting to consider what that means.  Even for the simple case
of a single point, "exactly 100km" would take an infinite number of
points to represent.

> The approaches/advice I've found so far fall into these broad categories:
> - find a local projection which covers the area of interest and create
> planimetric buffers/offsets in that projection

This seems straightforward except for the finite-resolution
arc-representation issue.  I would expect this is the usual aproach, but
also that it doesn't really work for geometries that span say 90 degrees
in latitude or longitude.

> - for point datasets, create a custom projection centered over each
> individual point and densify/transform the planimetric buffer in that
> projection back to the geographic CRS

This evokes some notion of close enough granularity, perhaps 100 points
around a circle but with each of them being right.  But once you do
that, I don't see how this differs from computing
  DIRECT(PT1, distance, az_i) for az_i in (0..99)/100 * \pi.
(I probably  got that wrong, but the  astute reader can consider what I
should have said.)


(This devolves to the first approach if the points are closer than the
buffer amount.)

> - use a geographic focused library like s2 (but that has the
> limitation in that it's spherical approximations only, not
> ellipsoidal)
>
> Consequently, I haven't found any generic approaches for calculating
> ellipsoid based buffers/offsets, and I'm interested in other's
> thoughts on this.
>
> Buffers/offsets are a bit of a funny beast, because they're complex to
> calculate with a lot of corner cases to handle. So we have great
> libraries like GEOS which handle this problem well, but I personally
> can't see GEOS ever gaining support for geodesic buffers as GEOS is
> focused on cartesian calculations only. But on the other hand having

I see your point, but it seems that if the kinds of calculations GEOS
can do are also necessary on the ellipsoid, it seems like GEOS is the
logical home for them.

> all the logic for buffer calculation sitting in proj also seems
> completely out of scope and inappropriate too! (Maybe geographiclib
> would be the best place for something of this nature?)

We'll see what Charles has to say!  (I expect his comments to be much
more valuable than mine....)

> Has anyone else looked into this previously? Anyone with any insights
> on this problem?

Is the use case for this a situation where a local projection doesn't
work because the area is so big?

Is the use case one where if the buffered geometry were 99.8 km
sometimes, something bad would happen?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210504/06ba7939/attachment.sig>