issue_comments
4 rows where author_association = "NONE" and issue = 1194993450 sorted by updated_at descending
This data as json, CSV (advanced)
Suggested facets: reactions, created_at (date), updated_at (date)
issue 1
- Writing GDAL ZARR _CRS attribute not possible · 4 ✖
id | html_url | issue_url | node_id | user | created_at | updated_at ▲ | author_association | body | reactions | performed_via_github_app | issue |
---|---|---|---|---|---|---|---|---|---|---|---|
1236352216 | https://github.com/pydata/xarray/issues/6448#issuecomment-1236352216 | https://api.github.com/repos/pydata/xarray/issues/6448 | IC_kwDOAMm_X85JsTzY | rouault 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 } |
Writing GDAL ZARR _CRS attribute not possible 1194993450 | |
1098371121 | https://github.com/pydata/xarray/issues/6448#issuecomment-1098371121 | https://api.github.com/repos/pydata/xarray/issues/6448 | IC_kwDOAMm_X85Bd9Ax | wankoelias 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 |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Writing GDAL ZARR _CRS attribute not possible 1194993450 | |
1091708256 | https://github.com/pydata/xarray/issues/6448#issuecomment-1091708256 | https://api.github.com/repos/pydata/xarray/issues/6448 | IC_kwDOAMm_X85BEiVg | christophenoel 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 } |
Writing GDAL ZARR _CRS attribute not possible 1194993450 | |
1091422044 | https://github.com/pydata/xarray/issues/6448#issuecomment-1091422044 | https://api.github.com/repos/pydata/xarray/issues/6448 | IC_kwDOAMm_X85BDcdc | christophenoel 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 } |
Writing GDAL ZARR _CRS attribute not possible 1194993450 |
Advanced export
JSON shape: default, array, newline-delimited, object
CREATE TABLE [issue_comments] ( [html_url] TEXT, [issue_url] TEXT, [id] INTEGER PRIMARY KEY, [node_id] TEXT, [user] INTEGER REFERENCES [users]([id]), [created_at] TEXT, [updated_at] TEXT, [author_association] TEXT, [body] TEXT, [reactions] TEXT, [performed_via_github_app] TEXT, [issue] INTEGER REFERENCES [issues]([id]) ); CREATE INDEX [idx_issue_comments_issue] ON [issue_comments] ([issue]); CREATE INDEX [idx_issue_comments_user] ON [issue_comments] ([user]);
user 3