JuliaGeo / GeometryOps.jl

GeoInterface-based geometry operations
https://juliageo.org/GeometryOps.jl/
MIT License
30 stars 4 forks source link

"Bounding boxes" on the sphere #231

Open asinghvi17 opened 2 weeks ago

asinghvi17 commented 2 weeks ago

From conversation with @aplavin:

In astronomy, one mostly encounters spherical caps and similar regions when working with coordinates that have uncertainties.

The uncertainties can be reported in different ways by different instruments/people, common ones include:

We should definitely support point-radius and point-ellipse formulations here, and perhaps the four-quadrant formulation as well. This solves one of the main issues I always had with spherical caps, which is that the spherical cap is not as flexible as an extent for extents that are large in one dimension and small in another, or stick-like and straight geometries like rivers.

Ellipsoids on the sphere would fix that nicely. But the math of intersection, point in polygon, etc would be pretty complicated - unless we brute force it.

Going to try and collect some resources on how to deal with this here.

asinghvi17 commented 2 weeks ago

I'm not sure about how this formulation works:

point + four quarters of ellipse (+- in both lat/lon are different)

is this smooth or segmented? would it be easier to represent this as a polygon on the sphere?

aplavin commented 1 week ago

Not sure I understand what you are asking... Uncertainties can be reported as two numbers for lon and two for lat (four in total), like lon = 123 +0.5 -0.3 and lat = 12 +1.2 -0.2. This has two natural interpretation, either as a rectangle (lon = 122.7 .. 123.5, lat = 11.8 .. 13.2) or as four quarters of an ellipse. Both are used. I think the resulting ellipse combination boundary is both continuous and smooth automatically, even at the boundaries.

asinghvi17 commented 1 week ago

Ah OK, so this is no longer an ellipse with two axes but rather a unit circle (let's say) that has been scaled differently in each of the four quadrants. That makes sense, thanks! It'd probably be easier to represent this as a polygon, then, but it's definitely possible to have utilities to compute these efficiently.