issue_comments

The main thing I don't like about how we handle the coordinate attribute right now is that we use it to determine the coordinate names, and throw the attribute out. I seem to remember bringing this up in the past with our discussions of the calendar attribute and still don't like that we remove attributes that we decode. Especially this once since we don't do much with it.

In the case of calendars, the information ends up on the encoding attribute. I think you're right though that we currently throw away variable specific coordinates information -- that should probably also be preserved on encoding.

There are two reasons why we do this sort of thing: 1. to make it unambiguously clear that we've "decoded" this information into xray's data model. 2. to ensure that the metadata can't get out of sync by being changed in one place but not another. For example, what would it mean if we unset xc as a coordinate on the dataset, but it remained in the coordinates attribute on mask? Or if we deleted xc entirely?

These sort of ambiguous scenarios are the part that worry me. In particular, I worry that it leads us down a path of maintaining arbitrary metadata through operations.

My hesitation with adding coord_keys is two-fold: 1. This would make the xray data model more complex. I would really prefer to avoid this. 2. It's not clear to me that the order of names in the coordinates attribute is meaningful according to CF conventions: "The value of the coordinates attribute is a blank separated list of the names of auxiliary coordinate variables. There is no restriction on the order in which the auxiliary coordinate variables appear in the coordinates attribute string."

A better way to handle this might be to write a xray-cf packages (see #461 for another use case), which registers the .cf namespace on Dataset/DataArray objects. Then we could have ds.cf.plot, which automatically plots according to CF conventions, and could even do things like automatically plot with cartopy if relevant. This means less domain specific details in xray, and could be a good model for other similar extension projects (e.g., xgcm).

These latitude and longitude coordinates can't be dimensions because they need to be 2D. A good example would be simulation data on some sort of projected grid (like in @jhamman's example above).

We could probably modify our contour/contourf wrapper to accept 2D arrays for X/Y. The matplotlib functions already handle all the necessary logic.

We do support multi-dimensional coordinates already, and even read the coordinates attributes. However, we don't do anything with them, beyond keeping them around: http://xray.readthedocs.org/en/stable/data-structures.html#coordinates

It's definitely worth seeing if we can make ds.T.plot.contourf('lat', 'lon') work, though.