issue_comments

Thanks for pinging me. Regarding the ancillary variables, this comes from the CF conventions, allowing to "link" two or more arrays together. For example, we might have a radiance array, with quality_flags as an ancillary variable array, that characterises the quality of each radiance pixel. Now, in netcdf/CF, the ancillary variables are just references, but the logical way to do this in xarray is to use an ancillary_variables attribute to a DataArray. I'm not sure how we could do it in another way.

Thanks for launching this discussion @TomNicholas ! I'm a core dev of pytroll/satpy which handles earth observing satellite data. I got interested in DataTree because we have data from the same instruments available at mulitple resolution, hence not fitting into a single Dataset. For use Option 1 is probably feeling better. Even when having data at multiple resolutions, it is still a limited number of resolutions and hence splitting them in groups is the natural way of going I would say. We do not use the features you mention in Zarr or GRIB, as a majority of the satellite data we use is provided in netcdf nowadays. Don't hesitate to ask if you want to know more or if something is unclear, we are really interested in these developments, so if we can help that way...

Thanks for the clarification. I can confirm that drop_vars works as expected. As a user, I would vote for having __delitem__ call drop_vars, at least for now to keep backwards compatibility ?

@keewis thanks for the quick reply. I wasn't aware the builtin del wasn't supposed to work here, I'll try with drop_vars instead.

Ok, then I probably won't have the time to dig into this for now, sorry. If someone else with better knowledge of the code can work on this it would probably be for the best.

ooh, maybe I answered too fast. I hadn't really looked at the code yet... but let's see: if I understand correctly, in the function you cited, the functions get wrapped and include in the current cls. So I would need to fix the wrapper itself (_func_slash_method_wrapper) so that the attrs get copied and applied to the resulting array (if keep_attrs is True that is). However, do we have a guarantee that the wrapped functions are actually returning something that can have a .attrs ?

Sure! What do you reckon the default should be ? False for backwards compatibility ?

@crusaderky yep, supporting DataArray and Dataset objects is what we need.

and thanks for the workaround and impressively fast reaction :)

Ok good, I'll let this run it's course then. How about whats-new.rst, do you want me to fill in something there?

Ok travis seems to pass, how about appveyor ? There are many time encoding errors, should it be so ?

Am I right in thinking the failing travis and appveyor build aren't my doing ?

I'm not sure if I need to document anything as this is just a bugfix ?

I'm satisfied with this answer, thanks for taking the time !

Also DataArrays can have attributes, so storing them as attributes could lead to quite intricate situations ;)

I agree totally, but when writing to netcdf, I was expecting xarray to take out the DataArrays out of attributes, replace them with their name, and save them as separate array in the netcdf files. But maybe that's not xarray's job do deal with ?

This issue is very relevant for me too. I would like to also propose that a user could provide a function that would know how to combine the attrs of different DataArrays.

That looks fantastic @shoyer , looking forward to testing it :)

@shoyer absolutely, I will look into it, soon I hope

@jhamman One possibility would be to have a .resample on a DataArray (or equivalent independent function) that would be provided also a set of new coordinates, and that would return a new DataArray resampled to the new coordinates. One step further would be to implement this in sel or isel directly somehow.

thanks @shoyer

@jhamman Same problem rises with a regular numpy array as a source for the DataArray.

The use case I have is spatial resampling: assigning source data pixels to a destination grid. So in the example provided above, l_indices and c_indices would be the shape of the of the destination grid and tell us which pixels to take from the source data.

@shoyer this is what I showed you earlier

Yes, I have the latest version, still takes some time with a 9000x9000 array: In [4]: %time arr.unstack('flat_dim') CPU times: user 26.1 s, sys: 7.8 s, total: 33.9 s Wall time: 35.3 s