issues

I'm building a DataArray and get the following future warning, but can't seem to find a way to pass transpose_coords=False to ffill to keep current behavior?

dsinput['soundspeed'] =(('runname','time','azimuth','depth','range'),(speed1[np.newaxis,np.newaxis,np.newaxis,:,:])) dsinput['soundspeed'] =dsinput['soundspeed'].ffill(dim='depth')

/local-home/mor582/miniconda3/envs/dev2/lib/python3.8/site-packages/xarray/core/missing.py:403: FutureWarning: This DataArray contains multi-dimensional coordinates. In the future, these coordinates will be transposed as well unless you specify transpose_coords=False. return apply_ufunc()

@jhamman Hi I've been experimenting with converting Argo float profiles (http://www.argo.ucsd.edu/About_Argo.html) data to zarr as a cache for cloud processing of Argo data. One thing I've noticed is that Argo floats have each cycle (up down in the water column). The samples depths are not consistent across cycles. and there are a lot of single value attributes in the cycle file. e.g. Latitude etc. I loaded 250 cycle files from a single float and pushed them into a zarr using .to_zarr on each file putting each cycle into its own group:

cache/123456 (float id)/1(cycle)

This resulted in over 70k small files being created. small files are very inefficient on disk utilisation my data went from 10Meg to over 100 of disk utilisation.

With a straight pickle to zarr array the compression had the whole data series down to <1 MB!

Hi I've noticed a possible inconsistency with datetime storing. ``` t=xr.open_dataset(files[0]) t['JULD_LOCATION'][0] <xarray.DataArray 'JULD_LOCATION' ()> array('2008-07-29T20:20:58.000000000', dtype='datetime64[ns]') Attributes: long_name: Julian day (UTC) of the location relative to REFERENCE_DATE... conventions: Relative julian days with decimal part (as parts of day) resolution: 0.0

t.to_zarr(r'D:\argo\argo2.zarr',mode='w')

za =zarr.open(r'D:\argo\argo2.zarr',mode='w+') za['JULD_LOCATION'].info Out[442]: Name : /JULD_LOCATION Type : zarr.core.Array Data type : float64 Shape : (197,) Chunk shape : (197,) Order : C Read-only : False Compressor : Zlib(level=1) Store type : zarr.storage.DirectoryStore No. bytes : 1576 (1.5K) No. bytes stored : 2000 (2.0K) Storage ratio : 0.8 Chunks initialized : 1/1 ```

if I try this za['JULD_LOCATION1'] =t['JULD_LOCATION'] za['JULD_LOCATION1'].info Out[444]: Name : /JULD_LOCATION1 Type : zarr.core.Array Data type : datetime64[ns] Shape : (197,) Chunk shape : (197,) Order : C Read-only : False Compressor : Zlib(level=1) Store type : zarr.storage.DirectoryStore No. bytes : 1576 (1.5K) No. bytes stored : 1742 (1.7K) Storage ratio : 0.9 Chunks initialized : 1/1

There also seems to be a problem with the actual values stored are different using the two methods ``` pd.to_datetime(za['JULD_LOCATION'][0]) Timestamp('1970-01-01 00:00:00.000021394')

pd.to_datetime(za['JULD_LOCATION1'][0]) Timestamp('2008-07-29 20:20:58') I think it is to do with the reference date time not being applied? t1['REFERENCE_DATE_TIME'] Out[459]: <xarray.DataArray 'REFERENCE_DATE_TIME' ()> array(b'19500101000000', dtype='|S14') Attributes: long_name: Date of reference for Julian days conventions: YYYYMMDDHHMISS ```

I hope this makes sense