home / github

Menu
  • Search all tables
  • GraphQL API

issue_comments

Table actions
  • GraphQL API for issue_comments

4 rows where author_association = "NONE" and issue = 1194993450 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: reactions, created_at (date), updated_at (date)

user 3

  • christophenoel 2
  • rouault 1
  • wankoelias 1

issue 1

  • Writing GDAL ZARR _CRS attribute not possible · 4 ✖

author_association 1

  • NONE · 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

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
}
  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 _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
}
  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

CSV options:

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]);
Powered by Datasette · Queries took 13.973ms · About: xarray-datasette