If we publicly expose the DGGSInfo classes, we should probably also support passing grid parameters either as separate kwargs or as an instance of a DGGSInfo subclass passed via a grid_info kwarg.
In other words, we want to be able to override the grid parameters when decoding.
This reminds me of the pattern we're using in pint-xarray: obj.pint.quantify() returns a decoded object, and obj.pint.dequantify() serializes it again. Following that, we could do:
ds.dggs.decode() # read attributes from the default coordinate and decode
ds.dggs.decode(name="zone_ids") # read attributes from a different coordinate
# override attributes
# option 1a: provide parameters as a dict and look at the default coordinate for cell ids
ds.dggs.decode({"grid_name": "healpix", "resolution": 5, "indexing_scheme": "nested"})
# option 1b: provide parameters as a dict and look at a different coordinate for cell ids
ds.dggs.decode({"grid_name": "healpix", ...}, name="zone_ids")
# option 2a: provide grid info (default coordinate)
ds.dggs.decode(grid_info)
# option 2b: provide grid info (custom coordinate)
ds.dggs.decode(grid_info, name="zone_ids")
(I'm not particularly attached to calling the kwarg name, this could also be ids, coord, coordinate, or anything else we deem better)
If we do override the grid, we might want to replace the attributes of the cell id coordinate with the normalized parameters.
From https://github.com/xarray-contrib/xdggs/pull/39#discussion_r1633156880 (@benbovy):
In other words, we want to be able to override the grid parameters when decoding.
This reminds me of the pattern we're using in
pint-xarray:obj.pint.quantify()returns a decoded object, andobj.pint.dequantify()serializes it again. Following that, we could do:(I'm not particularly attached to calling the kwarg
name, this could also beids,coord,coordinate, or anything else we deem better)If we do override the grid, we might want to replace the attributes of the cell id coordinate with the normalized parameters.