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/6448#issuecomment-1236352216,https://api.github.com/repos/pydata/xarray/issues/6448,1236352216,IC_kwDOAMm_X85JsTzY,1192433,2022-09-04T14:21:13Z,2022-09-04T14:21:13Z,NONE,"> I am a little discouraged that we have not managed to align better across projects so far (e.g. having this conversation before the GDAL Zarr CRS convention was implemented)
just seeing this conversation. I wasn't aware of GeoZarr when I implemented the _CRS attribute in the GDAL Zarr driver. There is a practical difficulty in reusing the CF reading & writing code from the GDAL netCDF driver as it is tied to that driver, but I'd guess with sufficient effort it could be made agnostic of the carrier. No opposition from me if someone wants to tackle this.
That said, the way CRS is encoding in CF conventions is not super elegant, because you need to create a 0-dim variable, define a set of attributes for each projection method, and have an attribute in the georeferenced variable to point to the variable that holds the CRS attribute. A _CRS attribute on the georeferenced variable is much more simple, and by reusing the WKT or PROJJSON encodings, this save the implementor the business of knowing how to define exactly the CRS (obviously when they have a library that does that job for them)","{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 1, ""eyes"": 0}",,1194993450
https://github.com/pydata/xarray/issues/6448#issuecomment-1098371121,https://api.github.com/repos/pydata/xarray/issues/6448,1098371121,IC_kwDOAMm_X85Bd9Ax,15717873,2022-04-13T18:45:23Z,2022-04-13T18:45:23Z,NONE,so just to make it clear... GDAL doesn't actually need the CRS stored with the `_CRS` convention as documented in their ZARR driver specification?,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1194993450
https://github.com/pydata/xarray/issues/6448#issuecomment-1091708256,https://api.github.com/repos/pydata/xarray/issues/6448,1091708256,IC_kwDOAMm_X85BEiVg,9072111,2022-04-07T13:01:55Z,2022-04-07T13:02:34Z,NONE,"Some people will prefer Cloud-Optimised GeoTiff, others (geo)Zarr.
By the way, I use rasterio (based on GDAL), xarray, GDAL and all tools without problems with CF conventions.
The impact of GDAL using CRS attribute are only:
- when converting a non-netcdf file to Zarr with GDAL, the CRS is encoded in the CRS attribute
- when converting a Zarr file to a non-netcdf file which encode CRS in grid-mapping, this is not converted to the CRS attribute.
","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1194993450
https://github.com/pydata/xarray/issues/6448#issuecomment-1091422044,https://api.github.com/repos/pydata/xarray/issues/6448,1091422044,IC_kwDOAMm_X85BDcdc,9072111,2022-04-07T09:28:27Z,2022-04-07T09:28:27Z,NONE,"Very interesting topic. I assume that GDAL proposed something as Zarr specification has no provision for spatial reference system encoding.
From my point of view, by making it close to NetCDF (which is so widely used in Earth Observation missions) and providing supporting librarires, xArray made the success of Zarr in the EO world.
Indeed, my dream would be GDAL align to the GeoZarr spec which is mostly aligned with NetCDF/xArray.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1194993450