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/197#issuecomment-52455445,https://api.github.com/repos/pydata/xarray/issues/197,52455445,MDEyOklzc3VlQ29tbWVudDUyNDU1NDQ1,1217238,2014-08-18T06:10:39Z,2014-12-19T07:16:14Z,MEMBER,"Here's my current thinking on implementation:
- [x] `Dataset._coords_keys` is a set that keeps track of the names of variables that are coordinates. This would let us implement `Dataset.coords` as a dict-like object with very little overhead for lookups.
- [x] `DataArray.dataset` should go away from the public AP (use `to_dataset()` instead); more importantly, `DataArray` objects should only know about their coordinates, not any other aspects of the underlying dataset (it's a leaky abstraction).
- [x] `Dataset.__iter__` only only iterate over non-coordinates; but `__contains__` and `__getitem__` should be unchanged.
- [x] Of course, we should automatically save and load coordinates according to CF conventions.

Also, we need some new methods to make this workable (modeled off of pandas's `set_index` and `reset_index`):
- [x] `Dataset.set_coords(keys, inplace=False)` turns the variables in `names` into coordinates
- [x] `Dataset.reset_coords(keys=None, drop=False, inplace=False)` removes all coordinates and turns them back into variables (unless `drop=True`).
- [x] `DataArray.reset_coords()` would be very similar to the dataset method; it would return a `Dataset` unless unless `drop=True` (in which case it would return another `DataArray`).
- [ ] `set_index(keys, inplace=False)` should be both a `DataArray` and `Dataset` method.

An important aspect is that using non-index coordinates (a power user feature) should be _optional_, just like how using and understanding `Dataset` objects should be optional.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,39264845
https://github.com/pydata/xarray/issues/197#issuecomment-55074776,https://api.github.com/repos/pydata/xarray/issues/197,55074776,MDEyOklzc3VlQ29tbWVudDU1MDc0Nzc2,1217238,2014-09-10T06:07:15Z,2014-09-10T06:07:15Z,MEMBER,"Still a few items to check off (see the open associated issues) but I don't think they are blockers to v0.3.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,39264845
https://github.com/pydata/xarray/issues/197#issuecomment-50978946,https://api.github.com/repos/pydata/xarray/issues/197,50978946,MDEyOklzc3VlQ29tbWVudDUwOTc4OTQ2,1217238,2014-08-03T00:49:47Z,2014-08-03T00:49:47Z,MEMBER,"Some further thinking suggests that we can allow for multi-dimensional coordinates, but the only sane way to handle conflicting non-index coordinates is to drop them. Even Iris, with its strict interpretation of CF conventions, [takes this approach](http://scitools.org.uk/iris/docs/latest/userguide/cube_maths.html).

Raising an exception for conflicting non-scalar variables would make multi-dimensional coordinates impractical.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,39264845