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/pull/2195#issuecomment-442554179,https://api.github.com/repos/pydata/xarray/issues/2195,442554179,MDEyOklzc3VlQ29tbWVudDQ0MjU1NDE3OQ==,1217238,2018-11-28T18:28:50Z,2018-11-28T18:29:58Z,MEMBER,"I've pushed a few commits with some additional progress here. Here's my current plan:

1. Automatically create new variables for MultiIndex levels, and store these in `Dataset._variables` / `DataArray._coords`. This lets us use the normal variable consistency checks and indexing operations, rather than requiring explicit checks like `assert_unique_multiindex_level_names` or ""virtual variables"". This is mostly complete (still under-tested) as of the last commit, but it should be a big win for consistency when using a MultiIndex since the level variables will be built into xarray's data model. The MultiIndex itself will still be an xarray variable (an object array of tuples).
2. Add explicit `indexes`, as a map from coordinate names to a `pandas.Index` or `pandas.MultiIndex` used for indexing. Note that if a MultiIndex is used, coordinates corresponding to levels will all point to the same `MultiIndex`, e.g., if MultiIndex `foo` has levels `x` and `y`, indexes will look like `{'foo': foo, 'x': foo, 'y': foo}`.
3. Remove/fixup code that assumes that only dimension names are used for indexes. Instead, we look for indexes by looking up coordinate names in `.indexes`.
4. Add an xarray specific Index API so we can add our own index classes, e.g., a KDTree. This will happen in a later PR.","{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,327166000