Ok, so for now I roll with this:

```python def shrink_dataarray(da, dims=None): """remove nodata borders from spatial dims of dataarray""" dims = set(dims) if dims else set(da.dims)

if len(dims) != 2:
    raise IndexError

# non-spatial dims (carry over, only shrink spatial dims)
nsd = set(da.dims) - dims
nsd_indexers = {d: range(len(da[d])) for d in nsd}

indexers = {d: (da.count(dim=dims - set([d])|nsd).cumsum() != 0) * 
               (da.count(dim=dims - set([d])|nsd)[::-1].cumsum()[::-1] != 0)
            for d in dims}

indexers.update(nsd_indexers)

return da.isel(**indexers)

```

Is it possible to identify non-spatial dims with plain xarray dataarrays (non cf-xarray)? And is there maybe a way to detect unlimited dims (usually the time dim)?

@fujiisoup Thanks, that’s great and much cleaner than my previous numpy code. I’ll run with that and maybe try to pack that in a general function. Not sure is this a common enough problem to have in xarray itself?

@keewis @fujiisoup @shoyer thanks. this does indeed not work for my used case if there's a all-nan stretch between parts of the array (think UK and the channel and the northern coast of France) - I simply want to get rid of extra space around a geographic domain (i.e. the nan edges)

``` data = np.array([ [np.nan, np.nan, np.nan, np.nan], [np.nan, 0, 2, np.nan], [np.nan, np.nan, np.nan, np.nan], [np.nan, 2, 0, np.nan], [np.nan, np.nan, np.nan, np.nan], ]) da = xr.DataArray(data, dims=("x", "y"))

this also results in a 2x2 array, but should be 3x2

```

Great!

Seems I was simply missing the new dim z in my attempts. Could not translate to the new format... Thanks a bunch!!!

Maybe it's a misconception of mine how compression with add_offset, scale_factor works?

I tried using i2 dtype (ctype='i2')and only scale_factor (no add_offset) and this looks ok. However, when I switch to i4/i8 type I get strange data in the netCDFs (I write with NETCDF4_CLASSIC if this matters?)... Is it not possible to use a higher precision integer type for add_offset/ scale_factor encoding to get a better precision of scaled values?

About the code samples: sorry, just copied them verbatim from my script. The first block is the logic to compute the scale and offset values, the second is the enconding application using the decorator-based extension to neatly pipe encoding settings to an data array...

Doing a minimal example at the moment is a bit problematic as I'm traveling...

@jhamman Yes, indeed. Sorry to spam this old issue. I misread this one - #757 is what'm seeing.

I am seeing something similar, but maybe this is another issue (I'm on 0.10.0rc2)?

I do get a sorted string coordinate after a groupby...

My scenario is, that I have a dataset with a coord like this:

<xarray.DataArray 'pft' (pft: 13)> array(['TeBE_tm', 'TeBE_itm', 'TeBE_itscl', 'TeBE_tscl', 'TeBS_tm', 'TeBS_itm', 'TeE_s', 'TeR_s', 'TeNE', 'BBS_itm', 'BE_s', 'BS_s', 'C3G'], dtype='|S10') Coordinates: * pft (pft) |S10 'TeBE_tm' 'TeBE_itm' 'TeBE_itscl' 'TeBE_tscl' ... Then I create a new coordinate that I use to aggregate:

``` pfts = ds.coords['pft'].values.tolist() pfts_simplified = [remove(x) for x in pfts]

ds2['pft_agg'] = xr.full_like(ds['pft'], 0) ds2['pft_agg'][:] = pfts_simplified ds2_agg = ds2.groupby('pft_agg').sum(dim='pft', skipna=False) result = ds2_agg.rename({'pft_agg': 'pft'}) ```

Then in the end I have: ``` <xarray.DataArray 'pft' (pft: 8)> array(['BBS', 'B_s', 'C3G', 'TeBE', 'TeBE_scl', 'TeBS', 'TeNE', 'Te_s'], dtype=object) Coordinates: * pft (pft) object 'BBS' 'B_s' 'C3G' 'TeBE' 'TeBE_scl' 'TeBS' 'TeNE' ...

```

Am I missing something?

Ok, do you mean something like this?

ds = xr.open_dataset(fname_data, decode_times=False) ds['time_agg'] = xr.full_like(ds['time'], 0) ds['time_agg'][:] = np.repeat(np.arange(len(ds['time'])/10), 10) ds_agg = ds.groupby('time_agg').mean(dim='time')

@shoyer Is it possible to resample using fixed user-defined intervals? I have a non-CF compliant time axis (years -22000 to 1989) and want to aggregate by mean or argmax for 10 year intervals...

Is this possible using resample?

Thanks for that Stephan.

The workaround looks good for the moment ;-)... Detecting a mismatch (and maybe even correcting it) automatically would be very useful

cheers, C

Is there any news on this? Have the same problem. A reset_chunksizes() method would be very helpful. Also, what is the cleanest way to remove all chunk size info? I have a very long computation and it fails at the very end with the mentioned error message. My file is patched together from many sources...

cheers

I would like something like this as well! Also, specifying default attrs for all data arrays of a dataset (like missing_data/ _FillValue/ ...) would be nice... Not sure if this is currently possible?

Hi.

I'm seeing the same plotting issues as @jhamman in the plot above Oct 2015 with 0.8.2. Basically, all (most?) operations on the first subplots' axis differ.

Is there a fix/ workaround for this?

Ah, ok, cool.

Thanks for the pointers and getting back to me. Looking forward to any future xray improvements. It’s really becoming my goto to for netcdf stuff (in addition to cdo).

Christian

On 11 Nov 2015, at 01:27, Stephan Hoyer notifications@github.com wrote:

This is tricky to put into .sel because that method currently works by only looking at coordinate labels, not at data values.

One way to fix this would be to unravel your two dimensions corresponding to latitude and longitude into a single "lat_lon" dimension. At this point, you could apply a sea mask, to produce a compressed lat_lon coordinate corresponding to only unmasked points. Now, it's relatively straightforward to imagine doing nearest neighbor lookups on this set of labels.

This later solution will require a few steps (all of which are on the "to do" list, but without any immediate timelines): 1. support for multi-level indexes in xray 2. support for "unraveling" multiple dimensions into 1-dimension 3. support for looking up nearest locations in multiple dimensions via some sort of spatial index (e.g., a KD tree)

— Reply to this email directly or view it on GitHub https://github.com/xray/xray/issues/644#issuecomment-155611625.

Ah, ok... Thanks.