Spherical Geometry for All Operations

[jaredlander]

I was originally going to ask for a specific function such as st_buffer_spheroid() which would allow me to create a buffer around a polygon (or point or linestring) with the buffer size specified in meters instead of degrees. While I very much want that in order to avoid changing the projection 3857, computing the buffer then changing back to 4326.

While I really want that one particular function, I know that I'll eventually need the other functions to be spherical as well. It would be nice to have a spherical option for all the spatial operations, either by a *-spheroid() function, an argument to existing functions or a global setting.

R's {sf} does this globally be setting sf_use_s2(TRUE) (the default) and PostGIS does it with the GEOGRAPHY type.

So, this is a feature request not an issue, and I would love for there to be an st_buffer_spheroid() function and even better if other operations had spherical options too.

[Maxxen]

We're probably doing a GEOGRAPHY type at some point in the future that defaults to spherical (not ellipsoidal as with _spheroid) operations. I don't know of any system or library that can compute buffers on an ellipsoid. AFAIK PostGIS st_buffer implementation for geographies does a reprojection to planar space, computes the buffer and then converts it back to the original projection, although by automatically trying to figure out a fitting planar projection to minimize distortion. I guess we could probably look at implementing something similar after I rework projection handling in general (planned as the next big work-item after i finish up spatial indexes).

[jaredlander]

So I guess PostGIS is hiding the projection/reprojection from me, which I'm honestly fine with. I think {sf} in R computes the buffer in terms of meters, using S2, but I won't pretend to know how it works (I'm guessing it's the sphere, not the ellipse, and that's ok for my needs).

although by automatically trying to figure out a fitting planar projection to minimize distortion

This part is huge, since I don't know in advance where on the world my users are working, so I can't specify a good projection and am stuck with 3857.

after I rework projection handling in general

Will that mean I don't need to worry about always_xy in st_transform()? I didn't fully understand why that mattered, I figured once I made a POINT geometry then the order of the x/y wouldn't matter.

(planned as the next big work-item after i finish up spatial indexes

That sounds really exciting.