@yt87 This works for me with latest h5netcdf version. There have been several fixes regarding attribute reading. The issue might be closed after confirming.

Possibly related issue: https://github.com/h5netcdf/h5netcdf/issues/27

Anyway, I think I've found the root-cause of the issue. So with netcdf4-python it is possible to specify writing of attributes as NC_STRING string attributes.

The following will create a netcdf file which is readable with current xarray and h5netcdf backend.

```python import netCDF4 as nc import xarray as xr rootgrp = nc.Dataset("test_nc4_attrs.nc", mode="w", format="NETCDF4")

rootgrp.set_ncstring_attrs(True)

x = rootgrp.createDimension("x", 1) y = rootgrp.createDimension("y", 1) foo = rootgrp.createVariable("foo", "i4", ("y", "x")) foo.coordinates = "y x" foo[0, 0] = 0 rootgrp.close() ds = xr.open_dataset("test_nc4_attrs.nc", engine="h5netcdf") print(ds) print(ds.foo) ds.close() ```

If you uncomment the one line, this creates netcdf file which breaks with the error @yt87 showed above. If you try to open the file with decode_cf=False and write it back using to_netcdf the same error occurs.

h5dump before uncomment ATTRIBUTE "coordinates" { DATATYPE H5T_STRING { STRSIZE 3; STRPAD H5T_STR_NULLTERM; CSET H5T_CSET_ASCII; CTYPE H5T_C_S1; } DATASPACE SCALAR DATA { (0): "y x" } }

h5dump after uncomment ATTRIBUTE "coordinates" { DATATYPE H5T_STRING { STRSIZE H5T_VARIABLE; STRPAD H5T_STR_NULLTERM; CSET H5T_CSET_UTF8; CTYPE H5T_C_S1; } DATASPACE SIMPLE { ( 1 ) / ( 1 ) } DATA { (0): "y x" } }

Another thing I found, that this only accounts for coordinate attributes. All other attributes are read correctly AFAIKT. So with this in mind I would consider that a bug. The assumption that attributes are always scalar doesn't hold true.

And one more thing, also roundtripping in netcdf4 does not keep the NC_STRING type:

```python import netCDF4 as nc import xarray as xr rootgrp = nc.Dataset("test_nc4_attrs.nc", mode="w", format="NETCDF4") rootgrp.set_ncstring_attrs(True) x = rootgrp.createDimension("x", 1) y = rootgrp.createDimension("y", 1) foo = rootgrp.createVariable("foo", "i4", ("y", "x")) rootgrp.coordinates = "z y x" foo.coordinates = "y x" foo[0, 0] = 0 rootgrp.close()

ds = xr.open_dataset("test_nc4_attrs.nc", engine="netcdf4") ds.to_netcdf("test_nc4_attrs_out.nc") ds.close() ```

``` ncdump test_nc4_attrs.nc

netcdf test_nc4_attrs { dimensions: x = 1 ; y = 1 ; variables: int foo(y, x) ; string foo:coordinates = "y x" ;

// global attributes: string :coordinates = "z y x" ; data:

foo = 0 ; } ```

``` ncdump test_nc4_attrs_out.nc

netcdf test_nc4_attrs_out { dimensions: y = 1 ; x = 1 ; variables: int foo(y, x) ; foo:coordinates = "y x" ; data:

foo = 0 ; } ```

So changes are needed in several places to check if the attribute is scalar or array, not only for coordinates attributes. Thoughts?

@yt87 Thanks for providing all this.

Could you please give -k 'nc4' as option to the call to ncgen and report back? I think this is a problem with data model.

If you want a quick fix to read the file, add kwarg decode_cf=False in open_dataset. Then fix the coordinate attribute and call xr.decode_cf(ds).

Hmm, this worked in my case. How exactly did you create the netcdf file?

@yt87 AFAIK the CDL doesn't declare attribute types specifically. This should work:

``` netcdf x { dimensions: x = 1 ; y = 1 ; variables: int foo(y, x) ; foo:coordinates = "x y" ; data:

foo = 0 ; } ```