FWIW I could definitely see use cases for allowing something like this... I have used cumbersome/ugly workarounds to work with variance-covariance matrices etc. So I'm not weighing in on the "this should raise an error" debate. I got briefly excited when I saw it didn't raise an error, until everything started unraveling 🙃

ooh this is a fun one! came across this issue when we stumbled across a pendantic case writing tests (H/T @brews). I expected this to "fail loudly in the constructor" but it doesn't. note that currently AFAICT you cannot use positional slicing to achieve an intuitive result - the behavior seems more undefined/unpredictable

```python

setup

import xarray as xr, pandas as pd, numpy as np da = xr.DataArray(np.arange(8).reshape(2, 2, 2), coords=[[0, 1], [0, 1], ['a', 'b']], dims=["ni", "ni", "shh"]) xarray seems to not know it has a problem:python In [4]: da Out[4]: <xarray.DataArray (ni: 2, shh: 2)> array([[[0, 1], [2, 3]],

   [[4, 5],
    [6, 7]]])

Coordinates: * ni (ni) int64 0 1 * shh (shh) <U1 'a' 'b' slicing (somewhat intuitively? slices along both dims):python In [5]: da.sel(ni=0) Out[5]: <xarray.DataArray (shh: 2)> array([0, 1]) Coordinates: ni int64 0 * shh (shh) <U1 'a' 'b' however, positional slicing (and any attempts I've made to handle the repeated dims differently) seems to have undefined behavior:python In [6]: da[0, :, :] # positional slicing along first dim works as expected(?) Out[6]: <xarray.DataArray (ni: 2, shh: 2)> array([[[0, 1], [2, 3]],

   [[4, 5],
    [6, 7]]])

Coordinates: * ni (ni) int64 0 1 * shh (shh) <U1 'a' 'b'

In [7]: da[:, 0, :] # positional slicing along second dim slices both dims Out[7]: <xarray.DataArray (shh: 2)> array([0, 1]) Coordinates: ni int64 0 * shh (shh) <U1 'a' 'b' ```

This has been happening a lot to me lately when writing to zarr. Thanks to @bolliger32 for the tip - this usually works like a charm:

```python for v in list(ds.coords.keys()): if ds.coords[v].dtype == object: ds.coords[v] = ds.coords[v].astype("unicode")

for v in list(ds.variables.keys()): if ds[v].dtype == object: ds[v] = ds[v].astype("unicode") `` For whatever reason, clearing the encoding and/or using.astype(str)` doesn't seem to work as reliably. I don't have a good MRE for this but hope it helps others with the same issue.

note the flag raised by @FlorisCalkoen below - don't just throw this at all your writes! there are other object types (e.g. CFTime) which you probably don't want to convert to string. This is just a patch to get around this issue for dataarrays with string coords/variables.

ha - yeah that's a good flag. I definitely didn't intend for that to be a universally applied patch! so probably should have included a buyer beware. but we did find that clearing the encoding doesn't always do the trick for string arrays. So a comprehensive patch will probably need to be more nuanced.

D'oh! Thanks so much for the catch!

@andersy005 last I saw this was still not building on readthedocs! I never figured out how to get around the build timeout are you sure this PR was good to go?

If there's anything you need help with or would like to discuss, please don't hesitate to raise a Zarr issue. We also enabled GH discussions over there so if that fits better feel free to use that 🙂

@jakirkham appreciate that! And just to clarify my confusion/frustration in the past was simply around the issue that I'm documenting here, which I've finally figured out! so hopefully this will help resolve the problem for future users. I agree with Ryan that there might be some changes in the defaults that could be helpful here, though setting intuitive defaults other than zarr's defaults could get messy for complex datasets with a mix of dask and in-memory arrays. But I think that's all on the xarray side?

@jakirkham were you thinking a reference to the dask docs for more info on optimal chunk sizing and aligning with storage? or are you suggesting the proposed docs change is too complex?

I was trying to address the lack of documentation on specifying chunks within a zarr array for non-dask arrays/coordinates, but also covering the weedsy (but common) case of datasets with a mix of dask & in-memory arrays/coords like in my example. I have been frustrated by zarr stores I've written with a couple dozen array chunks and thousands of coordinate chunks for this reason, but it's definitely a gnarly topic to cover concisely :P

thank you all for being patient with this PR! seems the build failed again for the same reason. I think there might be something wrong with my examples, though it beats me what the issue is. As far as I can tell, most builds come in somewhere in the mid 900s range on readthedocs but my branch consistently times out at 1900s. I'll see if I can muster a bit of time to run through the exact rtd build workflow and figure out what's going on but probably won't get to it until this weekend.

now I'm getting reproducible build timeouts 😭

The docs build alone (just make html) takes around an hour on my laptop for xarray/main and just a bit longer on my branch. readthedocs seems to be timing out at 31 minutes. How does this usually work? or am I doing something wrong again?

Thanks for all the help everyone!

@dcherian - yep I was trying to follow that guide closely but was still struggling with building using conda on my laptop's miniconda environment. The sphinx ipython directive kept running in the wrong conda environment, even after deleting sphinx, ipython, and ipykernel on my base env and making sure the env I was running make from had all the dependencies 🤷🏼‍♂️ . The docker image helped with the conda version issue but then I ran afoul of the xarray version because I used a shallow clone. oopps 😞

!!! @andersy005 thank you so much! yes - I was using a shallow clone inside the docker version of the build. I really appreciate the review and for catching my error. I'll clean this up and push the changes.

sorry I know I said I'd fix this but I'm having a very hard time figuring out what is wrong and how to build the docs. I had to set up a docker image to build them because I couldn't get the ipython directive to use the right conda env on my laptop, and now I'm getting a version error when pandas encounters the default build number on my fork. I'm a bit embarrassed that I can't figure this out, but... I think I might need a hand getting this across the finish line 😕

``` ....

13 1597.6 reading sources... [ 97%] getting-started-guide/faq

13 1600.8 reading sources... [ 97%] getting-started-guide/index

13 1600.8 reading sources... [ 97%] getting-started-guide/installing

13 1601.0 reading sources... [ 97%] getting-started-guide/quick-overview

13 1609.3 WARNING:

13 1609.3 >>>-------------------------------------------------------------------------

13 1609.3 Exception in /xarray/doc/getting-started-guide/quick-overview.rst at block ending on line 169

13 1609.3 Specify :okexcept: as an option in the ipython:: block to suppress this message

13 1609.3 ---------------------------------------------------------------------------

13 1609.3 ImportError Traceback (most recent call last)

13 1609.3 Input In [40], in <cell line: 1>()

13 1609.3 ----> 1 series.to_xarray()

13 1609.3

13 1609.3 File /srv/conda/envs/xarray-doc/lib/python3.9/site-packages/pandas/core/generic.py:3173, in NDFrame.to_xarray(self)

13 1609.3 3096 @final

13 1609.3 3097 def to_xarray(self):

13 1609.3 3098 """

13 1609.3 3099 Return an xarray object from the pandas object.

13 1609.3 3100

13 1609.3 (...)

13 1609.3 3171 speed (date, animal) int64 350 18 361 15

13 1609.3 3172 """

13 1609.3 -> 3173 xarray = import_optional_dependency("xarray")

13 1609.3 3175 if self.ndim == 1:

13 1609.3 3176 return xarray.DataArray.from_series(self)

13 1609.3

13 1609.3 File /srv/conda/envs/xarray-doc/lib/python3.9/site-packages/pandas/compat/_optional.py:164, in import_optional_dependency(name, extra, errors, min_version)

13 1609.3 162 return None

13 1609.3 163 elif errors == "raise":

13 1609.3 --> 164 raise ImportError(msg)

13 1609.3 166 return module

13 1609.3

13 1609.3 ImportError: Pandas requires version '0.15.1' or newer of 'xarray' (version '0.1.dev1+gfdf7303' currently installed).

13 1609.3

13 1609.3 <<<-------------------------------------------------------------------------

13 1609.3

13 1609.3 Exception occurred:

13 1609.3 File "/srv/conda/envs/xarray-doc/lib/python3.9/site-packages/IPython/sphinxext/ipython_directive.py", line 584, in process_input

13 1609.3 raise RuntimeError('Non Expected exception in {} line {}'.format(filename, lineno))

13 1609.3 RuntimeError: Non Expected exception in /xarray/doc/getting-started-guide/quick-overview.rst line 169

13 1609.3 The full traceback has been saved in /tmp/sphinx-err-a01y480j.log, if you want to report the issue to the developers.

13 1609.3 Please also report this if it was a user error, so that a better error message can be provided next time.

13 1609.3 A bug report can be filed in the tracker at https://github.com/sphinx-doc/sphinx/issues. Thanks!

13 1611.4 make: *** [Makefile:58: html] Error 2

13 1611.6 ERROR conda.cli.main_run:execute(41): conda run /bin/bash -c make html failed. (See above for error)

13 ERROR: executor failed running [conda run --no-capture-output -n xarray-doc /bin/bash -c make html]: exit code: 2

> [10/10] RUN make html:

executor failed running [conda run --no-capture-output -n xarray-doc /bin/bash -c make html]: exit code: 2 ```

hmmm seems I've messed something up in the docs build. apologize for the churn - will fix.

In the example it's saving every iteration, but in my actual code it's much less frequent

when I said "you're overwriting the file every iteration" I meant to put the emphasis on overwiting. by using mode='w' instead of mode='a' you're telling zarr to delete the file if it exists and the re-create it every time to_zarr is executed.

See the docs on xr.Dataset.to_zarr:

mode ({"w", "w-", "a", "r+", None}, optional) – Persistence mode: “w” means create (overwrite if exists); “w-” means create (fail if exists); “a” means override existing variables (create if does not exist); “r+” means modify existing array values only (raise an error if any metadata or shapes would change). The default mode is “a” if append_dim is set. Otherwise, it is “r+” if region is set and w- otherwise.

This interpretation of mode is consistent across all of python - see the docs for python builtins: open

So I think changing your writes to ds3.to_zarr('zarr_bug.zarr', mode='a') as Max suggested will get you a good part of the way there :)

oof - debugging CI build process is no fun. good luck, and thanks @max-sixty !!

@tbloch1 following up on Max's suggestion - it looks like you might be overwriting the file with every iteration. See the docs on ds.to_zarr - mode='w' will overwrite the file while mode='a' will append. That said, you still would need your indices to not overlap. How are you distinguishing between the files? is each one a different point in time?

To me, this doesn't seem likely to be a bug, but is more of a usage question. Have you tried asking on stackoverflow with the xarray tag?

hmm. readthedocs failed because of concurrency limits (my bad) but seems to have failed to automatically retry. can someone give it a nudge?

thanks @max-sixty! I was mostly trying to be overly-cautious because the ValueError was so clearly raised intentionally, and I can't figure out why it was necessary. But maybe it was just left over from a time when providing both arguments really would have caused a problem, and it's no longer the case.

This isn't a fix for the overhead required to manage an arbitrarily large graph, but note that creating chunks this small (size 1 in this case) is explicitly not recommended. See the dask docs on Array Best Practices: Select a good chunk size - they recommend chunks no smaller than 100 MB. Your chunks are 8 bytes. This creates 1 billion tasks, which does result in an enormous overhead - there's no way around this. Note that storing this on disk would not help - the problem results from the fact that 1 billion tasks will almost certainly overwhelm any dask scheduler. The general dask best practices guide recommends keeping the number of tasks below 1 million if possible.

Also, I don't think that the issue here is in specifying the universe of the tasks that need to be created, but rather in creating and managing the python task objects themselves. So pre-computing or storing them wouldn't help.

For me, changing to (1000, 1000, 100) chunks (~750MB for a float64 array) reduces the time to a couple ms: python In [16]: %%timeit ...: ...: chunks = (1000, 1000, 100) ...: ds = xr.Dataset(data_vars={ ...: "foo": (('x', 'y', 'z'), dask.array.empty((1000, 1000, 1000), chunks=(1000, 1000, 1000)))}) ...: ds.to_zarr(store='data', group='ds.zarr', compute=False, encoding={'foo': {'chunks': chunks}}, mode='w') ...: ds_loaded = xr.open_zarr(group='ds.zarr', store='data') ...: ...: 6.36 ms ± 111 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

With this chunking scheme, you could store and work with much, much more data. In fact, scaling the size of your example by 3 orders of magnitude only increases the runtime by ~5x: python In [18]: %%timeit ...: ...: chunks = (1000, 1000, 100, 1) ...: ds = xr.Dataset(data_vars={ ...: "foo": (('w', 'x', 'y', 'z'), dask.array.empty((1000, 1000, 1000, 1000), chunks=(1000, 1000, 1000, 1)))}) ...: ds.to_zarr(store='data', group='ds.zarr', compute=False, encoding={'foo': {'chunks': chunks}}, mode='w') ...: ds_loaded = xr.open_zarr(group='ds.zarr', store='data') ...: ...: 36.9 ms ± 2.23 ms per loop (mean ± std. dev. of 7 runs, 10 loops each) So if re-writing your arrays with larger chunks is an option I think this could get around the problem you're seeing?

This looks like it could be a good improvement! Just flagging that in func_interpolate_na on main I see a different condition: python # fast track for no-nans and all-nans cases n_nans = nans.sum() if n_nans == 0 or n_nans == len(y): return y

Do you see the n_nans < 0 condition somewhere or is this just a typo? That condition also wouldn't make much sense.

Your point about using the shortcut for n_nans == len(y) - 1 seems right to me, and definitely doesn't seem worthy of an error when an all-NaN slice is silently skipped.

I realize this may be a larger discussion, but the implementation is so easy I went ahead and filed a PR that issues a PendingDeprecationWarning in Dataset.__bool__.

If there's a synthesis of keeping the truthiness while reducing the chance of these mistakes, that would be very welcome.

@max-sixty im not sure what this would look like. Do you mean a warning or are you hinting that the bar that would need to be met is a silver bullet that preserves bool(ds) but somehow isn’t confusing?

Yeah… I do understand how it’s currently working and why, and the behavior is certainly intuitive to those who appreciate the mapping inheritance.

That said, I feel I have to make a last stand argument because this trips people up quite often (on my team and elsewhere). I haven’t yet come across an example of anyone using this correctly, but I see users misusing it all the time.

The examples and behavior you’re showing @Illviljan seem to me like more the natural result of an implementation detail than a critical principle of the dataset design. While it’s obvious why bool(ds) resolves to True or False in the current implementation, I still think it’s not used and is out of step with how most users think of a dataset. The fact that nothing in the package requires a change in order to pass tests (the broken tests and the pathological case aside) reaffirms for me that this is not a useful feature.

I don’t know much about the mapping protocol or how closely it must be followed. Is the idea here that packages building on xarray (or interoperability features in e.g. numpy or dask) depend on a strict adherence to the full spec?

Here's a test script I'm using for this:

```bash

echo '$ conda create -n py37xr14 -c conda-forge --yes python=3.7 xarray=0.14.1' conda create -n py37xr14 -c conda-forge --yes python=3.7 xarray=0.14.1 > /dev/null

echo '$ conda create -n py37xr15 -c conda-forge --yes python=3.7 xarray=0.15.1' conda create -n py37xr15 -c conda-forge --yes python=3.7 xarray=0.15.1 > /dev/null

echo '$ conda run -n py37xr14 python test.py' conda run -n py37xr14 python test.py

echo

echo '$ conda run -n py37xr15 python test.py' conda run -n py37xr15 python test.py

echo echo '$ conda list -n py37xr14' conda list -n py37xr14

echo echo '$ conda list -n py37xr15' conda list -n py37xr15

conda env remove -n py37xr14 > /dev/null 2>&1 conda env remove -n py37xr15 > /dev/null 2>&1 ```

yeah I use this pattern all the time - df.stack().to_xarray() seems to now fail unless your columns were sorted alphabetically. not sure yet where this is happening but it does result in some pernicious bad data errors that can be hard to debug if you catch them at all.

xarray==0.10.2 netCDF4==1.3.1

Just tried it again and didn't have any issues:

```python patt = ( 'http://nasanex.s3.amazonaws.com/NEX-GDDP/BCSD/{scen}/day/atmos/{var}/' + 'r1i1p1/v1.0/{var}day_BCSD{scen}r1i1p1{model}_{year}.nc')

def open_url_dataset(url):

fname = os.path.splitext(os.path.basename(url))[0]
res = requests.get(url)
content = io.BytesIO(res.content)
nc4_ds = netCDF4.Dataset(fname, memory=res.content)

store = xr.backends.NetCDF4DataStore(nc4_ds)
ds = xr.open_dataset(store)

return ds

ds = open_url_dataset(url=patt.format( model='GFDL-ESM2G', scen='historical', var='tasmax', year=1988)) ds ```

yes! Thanks @jhamman and @shoyer. I hadn't tried it yet, but just did. worked great!

```python In [1]: import xarray as xr ...: import requests ...: import netCDF4 ...: ...: %matplotlib inline

In [2]: res = requests.get( ...: 'http://nasanex.s3.amazonaws.com/NEX-GDDP/BCSD/rcp45/day/atmos/tasmin/' + ...: 'r1i1p1/v1.0/tasmin_day_BCSD_rcp45_r1i1p1_CESM1-BGC_2073.nc')

In [3]: res.status_code Out [3]: 200

In [4]: res.headers['content-type'] Out [4]: 'application/x-netcdf'

In [5]: nc4_ds = netCDF4.Dataset('tasmin_day_BCSD_rcp45_r1i1p1_CESM1-BGC_2073', memory=res.content)

In [6]: store = xr.backends.NetCDF4DataStore(nc4_ds)

In [7]: ds = xr.open_dataset(store)

In [8]: ds.tasmin.isel(time=0).plot() /global/home/users/mdelgado/git/public/xarray/xarray/plot/utils.py:51: FutureWarning: 'pandas.tseries.converter.register' has been moved and renamed to 'pandas.plotting.register_matplotlib_converters'. converter.register() Out [8]: <matplotlib.collections.QuadMesh at 0x2aede3c922b0> ![output_7_2](https://user-images.githubusercontent.com/3698640/34856943-f82619f4-f6fc-11e7-831d-f5d4032a338a.png)python In [9]: ds Out [9]: <xarray.Dataset> Dimensions: (lat: 720, lon: 1440, time: 365) Coordinates: * time (time) datetime64[ns] 2073-01-01T12:00:00 2073-01-02T12:00:00 ... * lat (lat) float32 -89.875 -89.625 -89.375 -89.125 -88.875 -88.625 ... * lon (lon) float32 0.125 0.375 0.625 0.875 1.125 1.375 1.625 1.875 ... Data variables: tasmin (time, lat, lon) float64 ... Attributes: parent_experiment: historical parent_experiment_id: historical parent_experiment_rip: r1i1p1 Conventions: CF-1.4 institution: NASA Earth Exchange, NASA Ames Research C... institute_id: NASA-Ames realm: atmos modeling_realm: atmos version: 1.0 downscalingModel: BCSD experiment_id: rcp45 frequency: day realization: 1 initialization_method: 1 physics_version: 1 tracking_id: 1865ff49-b20c-4268-852a-a9503efec72c driving_data_tracking_ids: N/A driving_model_ensemble_member: r1i1p1 driving_experiment_name: historical driving_experiment: historical model_id: BCSD references: BCSD method: Thrasher et al., 2012, Hydro... DOI: http://dx.doi.org/10.7292/W0MW2F2G experiment: RCP4.5 title: CESM1-BGC global downscaled NEX CMIP5 Cli... contact: Dr. Rama Nemani: rama.nemani@nasa.gov, Dr... disclaimer: This data is considered provisional and s... resolution_id: 0.25 degree project_id: NEXGDDP table_id: Table day (12 November 2010) source: BCSD 2014 creation_date: 2015-01-07T19:18:31Z forcing: N/A product: output ```

Ok this is good to go if you all do want to enable _FillValue for variable-length unicode strings with a netCDF4 backend. Seems like there's a lot of prior work/thinking in this space though so no worries if you want to wait.

lol. no I'm just walking around in your footsteps @shoyer. I've just enabled the tests you presumably wrote for #1647 & #1648. Curious why variable-length unicode strings with _FillHoles using netCDF4 doesn't currently work in master?

hmm. Seems I'm touching on a much larger issue here: Unidata/netcdf4-python#730

The round-trip works for me using a netcdf4 engine once this fix is implemented in conventions.py. There are tests that are ready to demonstrate this in test_backends.py:836-843, but running these tests (by removing the pytest.raises lines) applies to both netCDF4 and h5netcdf backends.

Should these use cases be split up?

I've got a reproducible example of this (sorry for the length):

```python In [1]: import xarray as xr ...: import numpy as np ...: import pandas as pd

...: import netCDF4 ```

python In [2]: xr.show_versions()

INSTALLED VERSIONS
------------------
commit: None
python: 3.5.4.final.0
python-bits: 64
OS: Darwin
OS-release: 17.3.0
machine: x86_64
processor: 
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: en_US.UTF-8

xarray: 0.10.0
pandas: 0.21.0
numpy: 1.13.3
scipy: 1.0.0
netCDF4: 1.3.1
h5netcdf: None
Nio: None
bottleneck: 1.2.1
cyordereddict: None
dask: 0.16.0
matplotlib: 2.1.0
cartopy: None
seaborn: 0.8.1
setuptools: 36.5.0.post20170921
pip: 9.0.1
conda: None
pytest: 3.3.1
IPython: 6.2.1
sphinx: None

python In [3]: nds = netCDF4.Dataset('test.nc', 'w', format='NETCDF4')

python In [4]: nds.createDimension('X', 3) ...: nds.createVariable('X', str, ('X', ), fill_value='invalid') ...: nds.createVariable('xname', str, ('X', ), fill_value='invalid') ...: nds.createVariable('var1', np.float32, ('X', ), fill_value=np.nan) ...: ...: nds.variables['X'][:] = np.array(['first', 'second', 'third']) ...: nds.variables['xname'][:] = np.array(['the_first', 'invalid', 'the_third']) ...: nds.variables['var1'][:] = np.random.random((3, ))

python In [5]: nds.variables['X']

<class 'netCDF4._netCDF4.Variable'>
vlen X(X)
    _FillValue: invalid
vlen data type: <class 'str'>
unlimited dimensions: 
current shape = (3,)

python In [6]: nds.variables['X'][:]

array(['first', 'second', 'third'], dtype=object)

python In [7]: nds.variables['xname']

<class 'netCDF4._netCDF4.Variable'>
vlen xname(X)
    _FillValue: invalid
vlen data type: <class 'str'>
unlimited dimensions: 
current shape = (3,)

python In [8]: nds.variables['xname'][:]

array(['the_first', 'invalid', 'the_third'], dtype=object)

python In [9]: nds.variables['var1']

<class 'netCDF4._netCDF4.Variable'>
float32 var1(X)
    _FillValue: nan
unlimited dimensions: 
current shape = (3,)
filling on

python In [10]: nds.variables['var1'][:]

array([ 0.58315825,  0.82443351,  0.39345944], dtype=float32)

python In [11]: nds.close()

python In [12]: ds = xr.open_dataset('test.nc')

---------------------------------------------------------------------------

UnboundLocalError                         Traceback (most recent call last)

<ipython-input-14-1a1dee73db10> in <module>()
----> 1 ds = xr.open_dataset('test.nc')


~/miniconda2/envs/spatial3/lib/python3.5/site-packages/xarray/backends/api.py in open_dataset(filename_or_obj, group, decode_cf, mask_and_scale, decode_times, autoclose, concat_characters, decode_coords, engine, chunks, lock, cache, drop_variables)
    303             lock = _default_lock(filename_or_obj, engine)
    304         with close_on_error(store):
--> 305             return maybe_decode_store(store, lock)
    306     else:
    307         if engine is not None and engine != 'scipy':


~/miniconda2/envs/spatial3/lib/python3.5/site-packages/xarray/backends/api.py in maybe_decode_store(store, lock)
    223             store, mask_and_scale=mask_and_scale, decode_times=decode_times,
    224             concat_characters=concat_characters, decode_coords=decode_coords,
--> 225             drop_variables=drop_variables)
    226 
    227         _protect_dataset_variables_inplace(ds, cache)


~/miniconda2/envs/spatial3/lib/python3.5/site-packages/xarray/conventions.py in decode_cf(obj, concat_characters, mask_and_scale, decode_times, decode_coords, drop_variables)
   1153     vars, attrs, coord_names = decode_cf_variables(
   1154         vars, attrs, concat_characters, mask_and_scale, decode_times,
-> 1155         decode_coords, drop_variables=drop_variables)
   1156     ds = Dataset(vars, attrs=attrs)
   1157     ds = ds.set_coords(coord_names.union(extra_coords).intersection(vars))


~/miniconda2/envs/spatial3/lib/python3.5/site-packages/xarray/conventions.py in decode_cf_variables(variables, attributes, concat_characters, mask_and_scale, decode_times, decode_coords, drop_variables)
   1086             k, v, concat_characters=concat_characters,
   1087             mask_and_scale=mask_and_scale, decode_times=decode_times,
-> 1088             stack_char_dim=stack_char_dim)
   1089         if decode_coords:
   1090             var_attrs = new_vars[k].attrs


~/miniconda2/envs/spatial3/lib/python3.5/site-packages/xarray/conventions.py in decode_cf_variable(name, var, concat_characters, mask_and_scale, decode_times, decode_endianness, stack_char_dim)
    998         if (has_fill or scale_factor is not None or add_offset is not None):
    999             if has_fill and np.array(fill_value).dtype.kind in ['U', 'S', 'O']:
-> 1000                 if string_encoding is not None:
   1001                     raise NotImplementedError(
   1002                         'variable %r has a _FillValue specified, but '


UnboundLocalError: local variable 'string_encoding' referenced before assignment

This seems to be produced by the fact that string_encoding is not defined for unicode-encoded variable-length string types. Could the problem be the lack of 'O' and 'U' in conventions.py line 952? I'll try my hand at a PR.

Thanks @shoyer. So you can download the entire object into memory and then create a file image and read that? While not a full fix, it's definitely an improvement over download-to-disk-then-read workflow!

I wasn't misled by the docs, just by my intuition. But now that you've made the distinction between '2012' and '2012-12-31' this totally makes sense:

```python In [24]: arr.sel(time='2012') Out[24]: <xarray.DataArray (time: 1, age: 4)> array([[ 0.244146, 0.702819, 0.06614 , 0.211758]]) Coordinates: * age (age) object 'age0' 'age1' 'age2' 'age3' * time (time) datetime64[ns] 2012-12-31

In [25]: arr.sel(time='2012-12-31') Out[25]: <xarray.DataArray (age: 4)> array([ 0.244146, 0.702819, 0.06614 , 0.211758]) Coordinates: * age (age) object 'age0' 'age1' 'age2' 'age3' time datetime64[ns] 2012-12-31

In [26]: arr.sel(time=np.datetime64('2012-12-31')) Out[26]: <xarray.DataArray (age: 4)> array([ 0.244146, 0.702819, 0.06614 , 0.211758]) Coordinates: * age (age) object 'age0' 'age1' 'age2' 'age3' time datetime64[ns] 2012-12-31 ```

thanks for the schooling. learned something new!

Got it. :( Thanks!

Could this extend the OpeNDAP interface? That would solve the metadata problem and would provide quick access to the distributed workers.