html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/6374#issuecomment-1090483461,https://api.github.com/repos/pydata/xarray/issues/6374,1090483461,IC_kwDOAMm_X85A_3UF,905179,2022-04-06T16:46:32Z,2022-04-06T16:46:32Z,NONE,"> As it is currently it is also not possible to write a zarr which follows the [GDAL ZARR driver conventions](https://gdal.org/drivers/raster/zarr.html). Writing the _CRS attribute also results in a TypeError:
Can you elaborate? What API are you using to do the write: python, netcdf-c, or what?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1172229856
https://github.com/pydata/xarray/issues/6374#issuecomment-1081236360,https://api.github.com/repos/pydata/xarray/issues/6374,1081236360,IC_kwDOAMm_X85AcluI,905179,2022-03-28T23:05:51Z,2022-03-28T23:05:51Z,NONE,"> dimension names stored by xarray in .zattrs[""_ARRAY_DIMENSIONS""] are stored by NCZarr in .zarray[""_NCZARR_ARRAY""][""dimrefs""]
I made a recent change to this so that where possible, all NCZarr files contain the
xarray _ARRAY_ATTRIBUTE. By ""where possible"" I mean that the array is in the root group
and the dimensions it references are ""defined"" in the root group (i.e. they have the simple
FQN ""/XXX"" where XXX is the dim name.
This means that there is sometimes a duplication of information between _ARRAY_ATTRIBUTE
and "".zarray[""_NCZARR_ARRAY""][""dimrefs""].","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1172229856
https://github.com/pydata/xarray/issues/6374#issuecomment-1076821132,https://api.github.com/repos/pydata/xarray/issues/6374,1076821132,IC_kwDOAMm_X85ALvyM,905179,2022-03-23T21:07:01Z,2022-03-23T21:07:01Z,NONE,"I guess I was not clear. If you are willing to lose netcdf specific metadata,
then I believe any xarray or zarr implementation should be able to read nczarr written data
with no changes needed.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1172229856
https://github.com/pydata/xarray/issues/6374#issuecomment-1076777717,https://api.github.com/repos/pydata/xarray/issues/6374,1076777717,IC_kwDOAMm_X85ALlL1,905179,2022-03-23T20:15:18Z,2022-03-23T20:15:18Z,NONE,"As the moment, NCzarr format files (as opposed to pure Zarr format files
produced by NCZarr) do not include the Xarray _ARRAY_DIMENSIONS attribute.
Now that I think about it, there is no reason not to include that attribute where it is meaningful,
so I will make that change. After that change, the situation should be as follows:
Xarray can read any nczarr format file subject to the following conditions:
1. xarray attempts to read only the root group and ignores subgroups
* this is because xarray cannot handle subgroups.
2. the xarray implementation ignores extra dictionary keys in e.g. .zarray and .zattr
that it does not recognize
* this should already be the case under the principle of ""read broadly, write narrowly"".","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1172229856
https://github.com/pydata/xarray/issues/6374#issuecomment-1071720621,https://api.github.com/repos/pydata/xarray/issues/6374,1071720621,IC_kwDOAMm_X84_4Sit,905179,2022-03-17T22:47:59Z,2022-03-17T22:47:59Z,NONE,"For Unidata and netcdf, I think the situation is briefly this.
In netcdf-4, dimensions are named objects that can ""reside"" inside groups.
So for example we might have this:
````
netcdf example {
dimensions: x=1; y=10; z=20;
group g1 {
dimensions: a=1; y=10; z=5;
variables: float v(/x, /g1/y, /z);
}
}
````
So base dimension names (e.g. ""z"") can occur in different groups and can represent different dimension objects (with different sizes).
It is possible to reference any dimension using fully-qualified-names (FQNs) such as ""/g1/y"".
This capability is important so that, for example, related dimensions can be isolated with a group.
NCZarr captures this information by recording fully qualified names as special keys.
This differs from XArray where fully qualified names are not supported.
From the netcdf point of view, it is as if all dimension objects were declared in the root group.
If XArray is to be extended to support the equivalent of groups and distinct sets of dimensions are going to be supported in different groups, then some equivalent of the netcdf FQN is going to be needed.
One final note. In netcdf, the dimension size is declared once and associated with a name.
In zarr/xarray, the size occurs in multiple places (via the ""shape"" key) and the name-size
associated is also declared multlple times via the _ARRAY_DIMENSIONS attribute.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1172229856