issue_comments

Looks like it

Should this have been closed by #2612?

see also https://github.com/pydata/xarray/issues/2525

Just to be clear, my comment above was a joke... @jbusecke and I are good friends! 🤣

https://twitter.com/wesmckinn/status/1055883061513084928

The dask implementation is short enough that I would certainly reimplement/vendor the pure numpy version for xarray. It might also be worth considering using the related utility skimage.util.view_as_blocks from skimage, which does the necessary reshaping using views (which should be much faster).

Currently dask is an optional dependency for carry, which I would like to preserve if possible. I'll take a glance at the implementation shortly, but my guess is that we will indeed want to vendor the numpy version into xarray. On Wed, May 31, 2017 at 6:38 AM Peter Steinberg notifications@github.com wrote:

Hi @darothen https://github.com/darothen earthio is a recent experimental refactor of what was the elm.readers subpackage. elm - Ensemble Learning Models was developed with a Phase I NASA SBIR in 2016 and in part reflects our thinking in late 2015 when xarray was newer and we were planning the proposal. In the last ca. month we have started a Phase II of development on multi-model dask/xarray ML algorithms based on xarray, dask, scikit-learn and a Bokeh maps UI for tasks like land cover classification. I'll add you to elm and feel free to contact me at psteinberg [at] continuum [dot] io. We will do more promotion / blogs in the near term and also in about 12 months we will release a free/open collection of notebooks that form a "Machine Learning with Environmental Data" 3-day course.

Back to the subject matter of the thread.... I assigned this issue to myself. I'll wait to get started until after @shoyer https://github.com/shoyer comments on @laliberte https://github.com/laliberte 's question:

(1) replicate serial coarsen into xarray or (2) point to dask coarsen methods?

—

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pydata/xarray/issues/1192#issuecomment-305189172, or mute the thread https://github.com/notifications/unsubscribe-auth/ABKS1hU-F507Wp1-MMa_JXzyaNtxXYQvks5r_W1hgaJpZM4LaxU4 .

My guess is that if you want to avoid a strong dependence on Dask then you'll want to copy the code over regardless.

Historically chunk.py hasn't been considered public (we don't publish docstrings in the docs for example). That being said it hasn't moved in a long while and I don't see any reason for it to move. I'm certainly willing to commit to going through a lengthy deprecation cycle if it does need to move.

I would be happy with a coarsen method, though I'd prefer to have an non-dask implementation, too.

Dask has this actually. We had to build it before we could build the parallel version. See dask/array/chunk.py::coarsen

I think this would be a nice feature and something that would fit nicely within xarray. The spatial resampling that I'm working towards is 1) a ways off and 2) quite a bit more domain specific than this. I'm +1!

This has the feel of a multi-dimensional resampling operation operation. I could potentially see this as part of that interface (e.g., array.resample(x=3, y=3).mean()), but that may be a slightly different operations because resample's window size is in label rather than integer coordinates.

That said, this seems useful and I wouldn't get too hung up about the optimal interface. I would be happy with a coarsen method, though I'd prefer to have an non-dask implementation, too. Potentially we could simply copy in skimage's block_reduce function for the non-dask implementation, which if I recall correctly does some clever tricks with reshaping to do the calculation efficiently.

cc @jhamman who has been thinking about regridding/resampling.