issue_comments: 457874348

Currently we distinguish between "dimension coordinates," which are converted to indexes, and "non-dimension coordinates."

The long term plan in https://github.com/pydata/xarray/issues/1603 ("Explicit indexes") is to eliminate this distinction -- we'll simply have variables, which can be in the form of data variables or coordinates, and indexes, for look-up along any coordinate.

What if we added a new type of coordinate called "cell coordinates"? We could accomodate either (N+1) sized coordinates for quad-mesh geometries or (N,M) sized coordinates for unstructured meshes.

I understand (N+1) sized coordinates for quad-mesh geometries, where N is the number of physical dimensions.

I'm not sure I understand (N,M) sized coordinates for unstructured meshes -- what is M here? The total number of cells? Some arbitrary constant indicating the maximum number of sides for a single cell?

I do.

Logically I see two approaches here: 1. Putting cell bounds into structured dtypes, and adding sugar to make these easier to use (as discussed in https://github.com/pydata/xarray/issues/1475#issuecomment-314844258). 2. Putting cell bounds directly into xarray's data model in some form, so we can deviate from our current rule that "coordinates dimensions must be a subset of DataArray dimensions."

(1) feels like the safe approach (from xarray's perpsective). Maybe structured dtypes too annoying to use on a routine basis, but there also are other use cases for them that would benefit from some attention. I worry that solutions in the style of (2) would bake domain specific logic deep into xarray's data model and make the whole library more complex, though I do appreciate that cell bounds are a pretty ubiquitous concept for modeling physical phenomena.

One way of solving (2) would be to allow something like "isolated" or "non-aligned" dimensions, which aren't shared across a Dataset/DataArray and are allowed to deviate on a per-variable basis. Dataset.dims would be a dynamic (rather than computed) part of xarray's data model, and dimensions not found in dims would not be required to be aligned/consistent between variables. This is intriguing but is also a much bigger change: - By default (i.e., dims=None), dims would get filled in from all the variables in a Dataset. But the aligned dimensions in dims could also be set explicitly. - If a dimension isn't found in dims, you can't index or align along it and it's allowed to vary between variables. - DataArray objects would also need some way to distinguish between "aligned" and "non-aligned" dimensions. It's less clear what this would be. - Only aligned dimensions on coordinates of a DataArray are required to be found on the DataArray variable.