Skip to content

Design of CRSIndex vs. "CRS-aware" indexes #25

Open
@benbovy

Description

@benbovy

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:

  1. 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)
  2. 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!)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions