Methods for longitude-latitude versus projected coordinate systems

[Huite]

Xugrid has, so far, mostly focused on projected coordinate systems (y, x). It will also read lat-lon data, but:

• Computing areas will go awry
• The overlap regridding also computes areas for its weights
• ?

Of course, everything could be reprojected, but it's likely worthwhile to some spherical geometry support at some point.

[veenstrajelmer]

rasterize() and CentroidLocatorRegridder are valid for spherical grids, but the OverlapRegridder uses areas which are computed as is cartesian so that will be invalid

[Huite]

The area computation in overlap regridding is done in numba_celltree: https://github.com/Deltares/numba_celltree/blob/ab64846dc8297c20a9d445f751bfcf6c1271b39a/numba_celltree/geometry_utils.py#L77 It might make sense to move the code to numba_celltree, since integrating over the sphere surface might be not that easy to do with numpy calls and we need the implementation in both places (and xugrid depends on numba_celltree, but not the other way around).

If you want to make it fancy, it can get quite tedious: https://r-spatial.github.io/sf/articles/sf7.html So support across the -180 / 180 line is not in scope. It's also worth researching the S2 stuff, see e.g.: https://github.com/benbovy/pys2index

Although it the performance is comparable for GEOS versus specialized implementations on the Cartesian plane (having to deal with more complicated geometries), it might make sense to still roll our own.