html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/3620#issuecomment-926829182,https://api.github.com/repos/pydata/xarray/issues/3620,926829182,IC_kwDOAMm_X843Pkp-,4160723,2021-09-24T18:13:25Z,2021-09-24T18:13:25Z,MEMBER,"@djhoese not yet but hopefully soon! Most of the work on explicit indexes is currently happening in #5692, which once merged (probably after the next release) will provide all the infrastructure for custom indexes. This is quite a big internal refactoring (bigger than I initially thought) that we cannot avoid as we're changing Xarray's core data model. After that, we'll need to update some public API (Xarray object constructors, `.set_index()`, etc.) so that Xarray will accept custom index classes. This should take much less work than #5692, though.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,537772490
https://github.com/pydata/xarray/issues/3620#issuecomment-865648105,https://api.github.com/repos/pydata/xarray/issues/3620,865648105,MDEyOklzc3VlQ29tbWVudDg2NTY0ODEwNQ==,4160723,2021-06-22T06:53:28Z,2021-06-22T06:53:28Z,MEMBER,"@djhoese you're right, I thought it was better to do all the internal refactoring first but we maybe shouldn't wait too long before updating `set_index` and the `DataArray` / `Dataset` constructors so that you and others can start playing with custom indexes.","{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,537772490
https://github.com/pydata/xarray/issues/3620#issuecomment-856081652,https://api.github.com/repos/pydata/xarray/issues/3620,856081652,MDEyOklzc3VlQ29tbWVudDg1NjA4MTY1Mg==,4160723,2021-06-07T16:25:13Z,2021-06-08T07:34:09Z,MEMBER,"> In your opinion will this type of CRSIndex/WCSIndex work need #5322? If so, will it also require (or benefit from) the additional internal xarray refactoring you mention in #5322?
Yes, CRSIndex/WCSIndex will need to provide an implementation for the `query` method added in #5322. However, this could be ""as simple as"" internally using `PandasIndex` for each 1-d coordinate in case of raster/grid data, maybe with an additional check that the values provided to `.sel` are in the same CRS (for example in the case of advanced indexing where `xarray.DataArray` or `xarray.Variable` objects are passed as arguments).
What will be probably more tricky is to find some common way to handle CRS for various indexes (e.g., regular gridded data vs. irregular data), probably via some class inheritance hierarchy or using mixins.
> I can really see this becoming super easy for CRS-based dataset users where libraries like geoxarray (or xoak) ""know"" the common types of schemes/structures that might exist in the scientific field and have a simple .geo.set_index that figures out most of the parameters for .set_index by default.
In case we load such data from a file/store, thanks to the Xarray backend system, maybe we won't even need a `.geo.set_index` but we'll be able to build the right index(es) when opening the dataset!","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,537772490
https://github.com/pydata/xarray/issues/3620#issuecomment-855720969,https://api.github.com/repos/pydata/xarray/issues/3620,855720969,MDEyOklzc3VlQ29tbWVudDg1NTcyMDk2OQ==,4160723,2021-06-07T08:29:15Z,2021-06-08T07:32:45Z,MEMBER,"We could also imagine
```python
# returns a new dataset with both pixel and world (possibly lazy) coordinates
>>> new_dataset = dataset.astro.append_world({'x': 'xw', 'y': 'yw', 'z': 'zw'})
# so that we can directly select data either using the pixel coordinates...
>>> new_dataset.sel(x=..., y=..., z=...)
# ...or using the world coordinates
>>> new_dataset.sel(xw=..., yw=..., zw=...)
# the WCS index would be attached to both pixel and world dataset coordinates
>>> new_dataset
Dimensions: (x: 100, y: 100, z: 100)
Coordinates:
* x (x) float64 ...
* xw (x) float64 ...
* y (y) float64 ...
* yw (y) float64 ...
* z (z) float64 ...
* zw (z) float64 ...
Data variables:
field (x, y, z) float64 ....
Indexes:
x, y, z, zw, yw, zw WCSIndex
```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,537772490
https://github.com/pydata/xarray/issues/3620#issuecomment-855710036,https://api.github.com/repos/pydata/xarray/issues/3620,855710036,MDEyOklzc3VlQ29tbWVudDg1NTcxMDAzNg==,4160723,2021-06-07T08:16:35Z,2021-06-07T08:16:35Z,MEMBER,"This looks like a nice use case for the forthcoming Xarray's [custom index](https://github.com/pydata/xarray/blob/master/design_notes/flexible_indexes_notes.md) feature.
How I see CRS/WCS-aware Xarray datasets with custom indexes:
- A set of coordinate(s) and their attributes hold data or metadata relevant for public use and that could be easily (de)serialized
- A custom index (`CRSIndex` or `WCSIndex`) provides CRS/WCS-aware implementations of common Xarray operations such as alignment (merge/concat) and data selection (sel), via `Xarray.Index`'s `equals`, `union`, `intersection` and `query` methods added in #5102 and #5322 (not yet ready for use outside of Xarray). Such custom index may also be used to hold some data that is tricky to propagate by other means, e.g., some internal information like ""functional"" coordinate parameters or a `crs` object. Xarray indexes should definitely provide more flexibility than coordinate data or attributes or accessor attributes for propagating this kind of information.
- Xarray accessors may be used to extend Dataset/DataArray public API. They could use the information stored in the `CRSIndex`/`WCSIndex`, e.g., add a `crs` read-only property that returns the `crs` object stored in CRSIndex, or add some some `extract_crs_parameters` method to extract the parameters and store them in Dataset/DataArray attributes similarly to what @djhoese suggests in his comment above.
For this use case a possible workflow would then be something like this:
```python
# create or open an Xarray dataset with x, y, z ""pixel"" (possibly lazy) coordinates
# and set a WCS index
dataset = (
xr.Dataset(...)
.set_index(['x', 'y', 'z'], WCSIndex, wcs_params={...})
)
# select data using pixel coordinates
dataset.sel(x=..., y=..., z=...)
# select data using world coordinates (via the ""astro"" accessor,
# which may access methods/attributes of the WCS index)
dataset.astro.sel_world(x=..., y=..., z=...)
# return a new dataset where the x,y,z ""pixel"" coordnates are replaced by the ""world"" coordinates
# (again using the WCS index, and propagating it to the returned dataset)
world_dataset = dataset.astro.pixel_to_world(['x', 'y', 'z'])
# select data using world coordinates
world_dataset.sel(x=..., y=..., z=...)
# select data using pixel coordinates (via the ""astro"" accessor)
world_dataset.astro.sel_pixel(x=..., y=..., z=...)
# this could be reverted
pixel_dataset = world_dataset.astro.world_to_pixel(['x', 'y', 'z'])
assert pixel_dataset.identical(dataset)
# depending on the implementation in WCSIndex, would either raise an error
# or implicitly convert to either pixel or world coordinates
xr.merge([world_dataset, another_pixel_dataset])
```
","{""total_count"": 2, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 2, ""rocket"": 0, ""eyes"": 0}",,537772490