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-926807091,https://api.github.com/repos/pydata/xarray/issues/3620,926807091,IC_kwDOAMm_X843PfQz,1828519,2021-09-24T17:37:54Z,2021-09-24T17:37:54Z,CONTRIBUTOR,@benbovy It's been a while since I've looked into xarray's flexible index work. What's the current state of this work (sorry if there is some issue or blog I should be watching for)? Is it possible for me as a user to create my own index classes that xarray will accept?,"{""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-862639338,https://api.github.com/repos/pydata/xarray/issues/3620,862639338,MDEyOklzc3VlQ29tbWVudDg2MjYzOTMzOA==,1828519,2021-06-16T19:06:50Z,2021-06-16T19:06:50Z,CONTRIBUTOR,"@benbovy I'm reading over the changes in #5322. All of this is preparing for the future, right? Is it worth it to start playing with these base classes (Index) in geoxarray or will I not be able to use them for a CRSIndex until more changes are done to xarray core? For example, none of this `set_index` for Index classes stuff you showed above is actually implemented yet, right?","{""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-856055553,https://api.github.com/repos/pydata/xarray/issues/3620,856055553,MDEyOklzc3VlQ29tbWVudDg1NjA1NTU1Mw==,1828519,2021-06-07T15:49:42Z,2021-06-07T15:49:42Z,CONTRIBUTOR,"@benbovy Thanks. This looks really promising and is pretty inline with what I saw geoxarray's internals doing for a user. 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?

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.","{""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-565679586,https://api.github.com/repos/pydata/xarray/issues/3620,565679586,MDEyOklzc3VlQ29tbWVudDU2NTY3OTU4Ng==,1828519,2019-12-14T03:56:38Z,2019-12-14T03:56:38Z,CONTRIBUTOR,"> For reference, here is how CRS information is handled in rioxarray: CRS management docs.

Nice! I didn't know you had documented this.

Sorry this is going to get long. I'd like to describe the CRS stuff we deal with and the lessons learned and the decisions I've been fighting with in the geoxarray project (https://github.com/geoxarray/geoxarray). I'm looking at this from a meteorological satellite point of view. @snowman2 please correct me if I'm wrong about anything.

1. In our field(s) and software the CRS object that @snowman2 is talking about and has implemented in `pyproj` encapsulates our version of these ""complex mathematical functions"", although ours seem much simpler. The CRS object can hold things like the model of the Earth to use and other parameters defining the coordinate system like the reference longitude/latitude.
2. When it comes to computing the coordinates of data on a CRS, the coordinates are typically on a cartesian plane so we have an X and a Y and points in between can be linearly interpolated. These work well as 1D xarray coordinates.
3. These X and Y coordinates don't tell you all the information alone though so we need the CRS information. Xarray's current rasterio functionality adds this CRS definition as a string value in `.attrs`. The problem with using `.attrs` for this is most operations on the DataArray object will make this information disappear (ex. adding two DataArrays).
4. In geoxarray I was going to try putting a pyproj CRS object in a DataArray's coordinates (`.coords`). I figured this would be good because then if you tried to combine two DataArrays on different CRSes, xarray would fail. Turns out xarray will just ignore the difference and drop the `crs` coordinate so that was no longer my ""perfect"" option. Additionally, to access the `crs` object would have to be accessed by doing `my_data_arr.coords['crs'].item()` because xarray stores the object as a scalar array.
5. [Xarray accessors](http://xarray.pydata.org/en/stable/internals.html#extending-xarray), last time I checked, often have to be recreated when working with Dataset or DataArray objects. This has to do with how low-level xarray converts Variable objects to DataArrays. I didn't expect this when I started geoxarray and I'm not really sure how to continue now.

As for your use case(s), I'm wondering if an xarray accessor could work around some of the current limitations you're seeing. They could basically be set up like @dcherian described, but ""arbitrary_function"" could be accessed through `x, y, z = my_data_arr.astro.world_coordinates(subpixels=4)` or something. You could do `my_data_arr.astro.wcs_parameters` to get a dictionary of common WCS parameters stored in `.attrs`. The point being that the accessor could simplify the interface to doing these calculations and accessing these parameters (stored in `.coords` and `.attrs`) and *maybe* make changes to xarray core unnecessary.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,537772490