Skip to content

Instantly share code, notes, and snippets.

@mdsumner
Last active May 23, 2024 05:24
Show Gist options
  • Save mdsumner/529e04bc406b512031203d87894c2e0c to your computer and use it in GitHub Desktop.
Save mdsumner/529e04bc406b512031203d87894c2e0c to your computer and use it in GitHub Desktop.

It will be different depending on whether s2 is enabled or not. To be sure I would use a map projection (local laea: Lambert Azimuthal Equal Area) (for each individual feature, if their coverage is "large enough", fine for something less than continent-size at a layer level) or use s2 (spherical approximating cells) or an ellipsoidal buffering wrapper more directly. You are supposed to blat the crs metadata if you want buffers in longlat for longlat data in sf, but it won't give real geographic distances for many projections that don't support that) and note that terra is very different - it will always use ellipsoidal methods no matter what crs is in use - but has its own vagaries here). It's largely why I don't use these tools for this kind of question, I like functions that do exactly what they say. Doing metrics in geographic space is what map projections exist for and recent attempts to hide this problem from users injects much uncertainty and new problems that are hard to track.

the units on the various parts of the CRS is completely different to what sf does with the units package and with its own logic to choose math- vs spherical- vs ellipsoidal- distance, the crs unit for longlat (EPSG:4326) is definitely degrees (it could be radians or microdegrees but that never happens in practice), and the LENGTHUNIT on the crs wkt refers to the radius of the ellipsoid that the longlat/degrees crs is based on (so the "units_gdal" does impact what sf chooses to do, but the LENGTHUNIT does not) - if the units_gdal was "US Foot" then

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment