issue_comments

I put a note in the gridded issue, but in short:

I think the way to get this is to use xarray in gridded, rather than to, well, reimplement gridded in xarray :-)

I think we can move the conversation to https://github.com/UXARRAY/uxarray now.

In order to maintain a list of currently relevant issues, we mark issues as stale after a period of inactivity

If this issue remains relevant, please comment here or remove the stale label; otherwise it will be marked as closed automatically

@ChrisBarker-NOAA: thanks, I'll reply in the gridded issue: https://github.com/NOAA-ORR-ERD/gridded/issues/55

@TomNicholas Thanks for the comment! I've put a clarification in the post, that I don't intend this to live in Xarray. The stuff I suggest is specifically about mesh topology, which I'd agree on as being outside of the scope of xarray. I realize the post wasn't that clear in that regard. I was indeed thinking of the accessor methods, but failed to explicitly mention them. Hopefully should be bit clearer now.

My basic understanding of this is that your data essentially can be represented as an xarray dataset as long as you cart around an extra variable (or attributes) to describe it, and there is a common set of methods you would then like to apply to that data?

If that's the case then this seems like a powerful and clear proposal for a widely-useful package which would leverage xarray, but perhaps would not live within xarray itself? We encourage composition over inheritance (i.e. wrap xarray.Dataset with your new gridded.Dataset), and the accessor methods can be used to provide the .method syntax you want. These methods can then interact directly with the lower level arrays xarray wraps if they need to. Even if you ended up reimplementing a large fraction of xarray's API, as each method wrapper would be thin I expect this would still be the most straightforward way to achieve what you want. Once your package is built we could also happily link to it in our list of projects which use xarray.