issue_comments

We may not have gotten this right yet. See StackOverflow: What are “unindexed dimensions” and why are coordinates empty?

The problem for the user is that the __repr__ makes him feel that his/her file is "not standard", as there are no proper coordinates in the file (at least not in the nice, CF compliant way).

I'd add another suggestion to the list that @shoyer proposed, which is simply to do nothing with the unindexed dimensions:

<xarray.Dataset> Dimensions: (x: 2, y: 2) Coordinates: * x (x) int64 1 2 Data variables: foo (x, y) int64 1 2 3 4 This has the advantage to be unambiguous and close to the data model of the file at hand (with dimensions but no coordinates).

After that, my preference goes for "Dimensions without coordinates" too.

In the SO post, the OP also wondered about the "empty" coordinates. Any plan to change this too? Maybe a - instead of *empty*?

This does make .sel a little more complex, but I think it's pretty reasonable

Sorry, I'm not sure to understand: do you mean you'd rather stay with the current behavior as you said in https://github.com/pydata/xarray/pull/1017#issuecomment-249908900 ?

[edited to remove a less relevant comment, now moved to a separate issue]

After having a look at the doc about coordinates (http://xarray.pydata.org/en/latest/data-structures.html#coordinates), here a few thoughts: - it would be good to have clear semantics about the different coordinates. For example, "positional coordinates" for coords with "*", "auxilliary coordinates" for coords without "*". How do we call the coordinates with a "o" ? - after giving it a second thought: have you considered not to list the coordinates with "o" in the coords repr? After all, what they really are is dimensions, not coordinates (as shown by the test above: 'dim_0' in ds.coords == False). The operations available on them (e.g. isel) really look like operations available on dimensions (similar to axis in numpy), not so much like operations available on coordinates.

I'll go on with a simple example that I just tried out to let you know how I dealt with this new behavior of xarray:

```python In [1]: import xarray as xr

In [2]: a = np.array([[1.1, 2.2, 3.3], [4.4, 5.5, 6.6]])

In [3]: da = xr.DataArray(a, dims=['y', 'x'], coords={'x':[0.1, 1.1, 2.2], 'xy':(['y', 'x'], a)})

In [4]: da Out[4]: <xarray.DataArray (y: 2, x: 3)> array([[ 1.1, 2.2, 3.3], [ 4.4, 5.5, 6.6]]) Coordinates: * x (x) float64 0.1 1.1 2.2 xy (y, x) float64 1.1 2.2 3.3 4.4 5.5 6.6 o y (y) - ```

"OK, I have three types of coordinates here. This makes sense, they are all defined in a different way. y is a dimension of my dataset, so at least I should be able to select along that dimension:".

python In [6]: da.isel(y=1) Out[6]: <xarray.DataArray (x: 3)> array([ 4.4, 5.5, 6.6]) Coordinates: * x (x) float64 0.1 1.1 2.2 xy (x) float64 4.4 5.5 6.6 "so far so good! x is a coordinate, so here I should be able to do more complex selection based on values:"

python In [7]: da.sel(x=2.2) Out[7]: <xarray.DataArray (y: 2)> array([ 3.3, 6.6]) Coordinates: x float64 2.2 xy (y) float64 3.3 6.6 o y (y) -

"That makes sense. However, this is probably not possible with y, which is not defined:"

python In [8]: da.sel(y=0) Out[8]: <xarray.DataArray (x: 3)> array([ 1.1, 2.2, 3.3]) Coordinates: * x (x) float64 0.1 1.1 2.2 xy (x) float64 1.1 2.2 3.3 "wait... So I can select by label on an undefined coordinate? Maybe y is a coordinate after all?"

python In [9]: 'y' in da.coords Out[9]: False "ah, no."

I actually think that .sel() shoud not work on y. I understand that this would break a bunch of existing code, but this is a confusing (if not inconsistent) behavior.

Maybe I'm completely missing the point here: don't hesitate to correct me!