issue_comments: 1236352216
This data as json
| 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 |
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 |