issues

Add summary methods to Dataset object. For example, it would be great if you could summarize a entire dataset in a single line.

(1) Mean of all variables in dataset.

python mean_ds = ds.mean()

(2) Mean of all variables in dataset along a dimension:

python time_mean_ds = ds.mean(dim='time')

In the case where a dimension is specified and there are variables that don't use that dimension, I'd imagine you would just pass that variable through unchanged.

Related to #122.

Requirements: - [x] Better documentation: - [x] Tutorial introduces DataArray before and independently of Dataset - [x] Revise README to emphasize that xray generalizes pandas to N-dimensions - [x] New FAQ section to clarify relationship of xray to pandas, Iris and CDAT (#112) - [x] Update What's New - [x] More consistent names: - [x] dimensions -> dims and coordinates -> coords (#190) - [x] noncoordinates -> noncoords - [x] Lay groundwork for non-index coordinates (#197): - [x] Require specifying attrs with a keyword argument in Dataset.__init__ (to make room for coords) - [x] Don't allow indexing array.coords[0] - [x] Remove the to argument from Dataset.apply (it will be much less clearly useful when we have non-index coords) - [x] Add warning in the docs (clarify that "linked dataset variables" are going away)

Nice to have: - [x] Support modifying DataArray dimensions/coordinates in place (#180) - [ ] Automatic alignment in mathematical operations (#184) - [ ] Revised interface for CF encoding/decoding (#155, #175)

Right now, we use ds.attrs but the keyword argument is still attributes. We should resolve this inconsistency.

We also use dimensions and coordinates instead of the natural abbreviations dims and coords (although dims is used in the Variable constructor). Should we switch to the abbreviated versions for consistency with attrs?

Note that I switched to attrs in part because of its use in other packages (h5py, pytables and blz). There is not as clear precedent for what to call dimensions and coordinates.

Allowing boolean arrays for .loc would make xray more consistent with pandas: http://pandas.pydata.org/pandas-docs/stable/indexing.html#different-choices-for-indexing-loc-iloc-and-ix

There is basically no ambiguity since True and False are more or less useless coordinate labels

The key thing is to (shallow) copy the underlying dataset before making any changes. The shallow copy is probably OK here -- modifying dimensions and coordinates is unlikely to be done in any inner loops.

Dataset reduce methods (#131) suggested to me that it would be nice to support applying functions which map over all data arrays in a dataset. The signature of Dataset.apply could be modeled after GroupBy.apply and the implementation would be similar to #137 (but simpler).

For example, I should be able to write ds.apply(np.mean).

Note: It's still worth having #137 as a separate implementation because it can do some additional validation for dimensions and skip variables where the aggregation doesn't make sense.

In #161, I renamed xray.Coordinate to xray.Index.

To better distinguish xray's Index from pandas, let's call it XIndex instead.

For users of pandas, the xray interface would be more obvious if we referred to what we currently call "coordinates" as "indices."

This would entail renaming the coordinates property to indices, xray.Coordinate to xray.Index and the xray.Coordinate.as_index property to as_pandas_index (all with deprecation warnings).

Possible downsides: 1. The xray data model would be less obvious to people familiar with the NetCDF. 2. There is some potential for confusion between xray.Index and pandas.Index: - The only real difference is that xray's Index is a xray.Variable object, and thus is dimension aware and has attributes. - In principle, xray.Index should have all the necessary properties to act like an index (or rather, it already has most of these properties and should get the rest). - Unfortunately, pandas doesn't accept non-pandas.Index objects as indices, nor will it properly convert an xray.Index into a pandas.Index.

At PyData SV, @mrocklin suggested that by default, array broadcasting should fall back on numpy's shape based broadcasting. This would also simplify directly constructing DataArray objects (#115).

The trick will be to make this work with xray's internals, which currently assume that dimensions are always named by strings.

``` import cPickle as pickle import xray import numpy as np import pandas as pd

foo_values = np.random.RandomState(0).rand(3,4) times = pd.date_range('2001-02-03', periods=3) ds = xray.Dataset({'time': ('time', times), 'foo': (['time', 'space'], foo_values)})

with open('mypickle.pkl', 'w') as f: pickle.dump(ds, f)

with open('mypickle.pkl') as f: myds = pickle.load(f)

myds ```

This code results in: <repr(<xray.dataset.Dataset at 0x7f95a3290d90>) failed: AttributeError: mapping>

I'd like to rename the Dataset/DataArray methods labeled and indexed, so that they are more obviously variants on a theme, similarly to how pandas distinguishes between methods .loc and .iloc (and .at/.iat, etc.). Some options include: 1. Rename indexed to ilabeled. 2. Rename indexed/labeled to isel/sel.

I like option 2 (particularly because it's shorter), but to avoid confusion with the select method, we would need to also rename select/unselect to something else. I would suggest select_vars and drop_vars.

It shouldn't be necessary to put arrays in a Dataset to make a DataArray.

See also: https://github.com/xray/xray/issues/85#issuecomment-38875079