xproj.CRSIndex is designed to be exclusively associated with a grid mapping (or spatial reference) scalar coordinate variable. Its unique goal is to track a pyproj.crs.CRS instance and assert CRS compliance when aligning Xarray objects.
Besides that, there is a variety of Xarray indexes that do the real business of translating array indices <-> physical coordinate labels and that would benefit from some CRS-aware functionalities (or that are already providing it), such as taking into account the CRS of the input labels passed to .sel(). A few examples are xvec's GeometryIndex, rasterix's RasterIndex, xoak's KDTreeIndex... and potentially many more. In Xproj and here below, we refer to these as "CRS-aware" indexes.
In the current Xarray model, however, a coordinate variable may be associated with only one index. This raises a major question: which "user-facing" index handles the grid mapping variable? There are two main options:
- Only the CRS-aware indexes are 1st-class Xarray indexes
- In an Xarray Dataset a grid mapping variable is mapped to an
xvec.GeometryIndex or rasterix.RasterIndex or xoak.KDTreeIndex... together with the index's spatial coordinate variables
xproj.CRSIndex is a helper, 2nd-class Xarray index that is meant to be encapsulated in a CRS-aware index (actually this could be anything else that allows identifying an Xarray index as CRS-aware and that avoids duplicating the same logic in each index)
- Both
xproj.CRSIndex and CRS-aware indexes are 1st-class Xarray indexes
- In an Xarray Dataset a grid mapping variable is always associated with an
xproj.CRSIndex while spatial coordinate variables are associated with CRS-aware indexes
- CRS-aware indexes manage their own CRS independently of any grid mapping variable (e.g., they may expose a
crs build option and/or property)
- For better interoperability between the
xproj.CRSIndex and CRS-aware indexes present in a Dataset, Xproj defines an interface that any CRS-aware index can implement, as well as a few helper methods in the proj accessor
Xproj currently adopts option 2, although I think this is still open for discussion.
I opened this issue for listing the pros and cons of each approach. I'll further comment it with some thoughts and a partial list, although I can still hardly have a clear and definitive opinion on this. Feedback from the community would be very much welcome!
@scottyhq @dcherian @maxrjones @martinfleis (feel free to ping anyone else who might have thoughts on this!)
xproj.CRSIndexis designed to be exclusively associated with a grid mapping (or spatial reference) scalar coordinate variable. Its unique goal is to track apyproj.crs.CRSinstance and assert CRS compliance when aligning Xarray objects.Besides that, there is a variety of Xarray indexes that do the real business of translating array indices <-> physical coordinate labels and that would benefit from some CRS-aware functionalities (or that are already providing it), such as taking into account the CRS of the input labels passed to
.sel(). A few examples are xvec'sGeometryIndex, rasterix'sRasterIndex, xoak'sKDTreeIndex... and potentially many more. In Xproj and here below, we refer to these as "CRS-aware" indexes.In the current Xarray model, however, a coordinate variable may be associated with only one index. This raises a major question: which "user-facing" index handles the grid mapping variable? There are two main options:
xvec.GeometryIndexorrasterix.RasterIndexorxoak.KDTreeIndex... together with the index's spatial coordinate variablesxproj.CRSIndexis a helper, 2nd-class Xarray index that is meant to be encapsulated in a CRS-aware index (actually this could be anything else that allows identifying an Xarray index as CRS-aware and that avoids duplicating the same logic in each index)xproj.CRSIndexand CRS-aware indexes are 1st-class Xarray indexesxproj.CRSIndexwhile spatial coordinate variables are associated with CRS-aware indexescrsbuild option and/or property)xproj.CRSIndexand CRS-aware indexes present in a Dataset, Xproj defines an interface that any CRS-aware index can implement, as well as a few helper methods in theprojaccessorXproj currently adopts option 2, although I think this is still open for discussion.
I opened this issue for listing the pros and cons of each approach. I'll further comment it with some thoughts and a partial list, although I can still hardly have a clear and definitive opinion on this. Feedback from the community would be very much welcome!
@scottyhq @dcherian @maxrjones @martinfleis (feel free to ping anyone else who might have thoughts on this!)