issue_comments

Apologies for the delay. This is a great first pass. Definitely more metadata sharing possible, but I'm glad this has been merged - let's grow the capability as required. If any issues crop up, please feel free to ping me & @bjlittle. 👍

This looks good to go now - thanks for all your help!

Ah yes, sorry about that - fixed now.

Yep, it's not a very exciting cube, but it runs fine.

@duncanwp that example looks good to me. I assume it runs locally with this branch?

How's this? (I turned the example around so that I create the cube as a DataArray then convert it...)

dask/dask#2977 would certianly make it cleaner, but 95b0197 should work in the meantime, unless there's a specific case I've missed?

https://github.com/dask/dask/issues/2977 needs to be resolved to make it possible to properly translate dask arrays back and forth between xarray/Iris.

I don't want to hold up this PR which is coming along very nicely (and I'm sure would already be useful), so we can we simply differ handling of dask arrays for now? I would suggest raising NotImplementedError and printing an error message with a link to a follow-up issue in xarray's issue tracker.

Great - thanks!

OK, here's another go. It's not pretty, but it seems to work. Once the various issues referenced above are solved it should clean it up, but I'd rather not wait for those since this has been in the works a while now.

I don't know exactly what would go wrong, but I'm pretty sure masked Dask arrays would break xarray in some subtle ways. It would be better to convert them to using unmasked Dask arrays using NaN. On Thu, Dec 7, 2017 at 1:18 AM Duncan Watson-Parris notifications@github.com wrote:

@duncanwp commented on this pull request.

In xarray/convert.py https://github.com/pydata/xarray/pull/1750#discussion_r155465954:

@@ -181,7 +183,9 @@ def from_iris(cube): cell_methods = _iris_cell_methods_to_str(cube.cell_methods) if cell_methods: array_attrs['cell_methods'] = cell_methods - dataarray = DataArray(cube.data, coords=coords, name=name, + + cube_data = ma.filled(cube.core_data(), get_fill_value(cube.dtype)) if hasattr(cube, 'core_data') else cube.data

OK, I hadn't appreciated that dask wasn't a hard requirement. I could leave them as whatever type they're currently stored in - how would xarray cope with a dask masked array?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pydata/xarray/pull/1750#discussion_r155465954, or mute the thread https://github.com/notifications/unsubscribe-auth/ABKS1rsh70WxzNY5hvo2S09YQf3bfUMXks5s961LgaJpZM4QxRZq .

Thanks for the feedback @shoyer and sorry for all the typos!

I think it's OK in I/O (for now). This is also the place where we document serialization in pickle, and the from_dict methods.

Agreed. In the long term, the IO docs have gotten pretty long, it could make sense to split them up into several subpages.

Do you have a feel for if/where else this should be documented? I'm not sure if really fits in I/O...

I think it's OK in I/O (for now). This is also the place where we document serialization in pickle, and the from_dict methods.

I think this may be a reasonable place to start, though it is certainly not leveraging Iris's full metadata decoding capabilities.

It seams like a decent starting point, were there specific decodings you had in mind?

It would also be nice to pass dask arrays back and forth, but that will probably need to wait until after Iris 2.0 and #1372 is solved.

Agreed.

Do you have a feel for if/where else this should be documented? I'm not sure if really fits in I/O...

@pelson any thoughts here?

I think this may be a reasonable place to start, though it is certainly not leveraging Iris's full metadata decoding capabilities.

It would also be nice to pass dask arrays back and forth, but that will probably need to wait until after Iris 2.0 and https://github.com/pydata/xarray/issues/1372 is solved.