home / github

Menu
  • Search all tables
  • GraphQL API

issue_comments

Table actions
  • GraphQL API for issue_comments

3 rows where issue = 140063713 and user = 10050469 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

user 1

  • fmaussion · 3 ✖

issue 1

  • ENH: Optional Read-Only RasterIO backend · 3 ✖

author_association 1

  • MEMBER 3
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
197601132 https://github.com/pydata/xarray/issues/790#issuecomment-197601132 https://api.github.com/repos/pydata/xarray/issues/790 MDEyOklzc3VlQ29tbWVudDE5NzYwMTEzMg== fmaussion 10050469 2016-03-16T23:22:10Z 2016-03-16T23:22:10Z MEMBER

Hi @jhamman , this is close to how I would've done it, but I am maybe not the most qualified (probably the gis specialists from rasterio would be more helpful). But still, a couple of remarks from my side: - I wouldn't necessarily do the try_to_get_latlon_coords systematically. When the raster coords are lat-lon, the new coords are redundant. And when the coords are x-y, the lat-lon info are only partly useful (since the grid will be unstructured in lat-lon). Furthermore, I am not sure if +init=EPSG:4326 is the only lat-lon proj available (there are surely more - at least if you leave the wgs-84 area) - as mentioned by perrygeo in your rasterio post, the data model of geotiffs is not always clear. The pixel coordinates are very likely to be at the top-left corner of the pixel (as I assume in my small salem library). Most netcdf datasets we are using in the meteo/climate community are pixel-centered. I don't know if this is something that xarray wants to consider, but this becomes important if you want to make accurate projections. (in practice, the two concepts are equivalent for most applications, but you have to know what is what: in my small library I called those representations center_grid and corner_grid: https://github.com/fmaussion/salem/blob/master/salem/gis.py#L101 )

To your questions: 1. I agree that returning a dataset is a good idea. I don't know if raster is a good name, but I have no other idea right now 2. I don't know. The projection was always enough for me :flushed:

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  ENH: Optional Read-Only RasterIO backend 140063713
195955210 https://github.com/pydata/xarray/issues/790#issuecomment-195955210 https://api.github.com/repos/pydata/xarray/issues/790 MDEyOklzc3VlQ29tbWVudDE5NTk1NTIxMA== fmaussion 10050469 2016-03-13T13:13:56Z 2016-03-13T13:15:07Z MEMBER

Hi @jhamman , I tend to agree with your doubts. I'll still comment on your cons:

To (1): I also think that xarray should avoid opening the projection can of worms. But the minimum things that xarray could do with rasterio is to read corner coordinates, dx and dy and define the two coordinates "x" and "y" out of it, without taking care of whether these are meters, degrees of arc or whatever. As long at the other rasterio file attributes are available as attribute of the DataArray or DataSet objects, users can do their own mixture

To (2): some geotiffs files also have more than one band. I don't know if these bands are named or have metadata, so maybe xarray will have to take decisions about these names too (most probably 1, 2, 3...).

I'll add a (3): rasterio depends on GDAL, which is huge and every now and then causes trouble on conda. This might also cause troubles to the continuous integration of xarray

Altogether this might be more complicated than worth it, but maybe the rasterio folks have interest in this and might provide more support.

If the idea for xarray accessors is implemented (https://github.com/pydata/xarray/issues/706#issuecomment-169099306) this will allow more specific libraries like mine to do their own rasterio support at low cost.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  ENH: Optional Read-Only RasterIO backend 140063713
195254611 https://github.com/pydata/xarray/issues/790#issuecomment-195254611 https://api.github.com/repos/pydata/xarray/issues/790 MDEyOklzc3VlQ29tbWVudDE5NTI1NDYxMQ== fmaussion 10050469 2016-03-11T08:25:04Z 2016-03-11T08:25:04Z MEMBER

:+1: Rasterio shines at reading georeferencing metadata out of any file, and I guess it would be no big deal to treat the various info as attributes in an xarray dataset. It is also possible to do lazy reading out of rasterio files.

(example with a geotiff file: https://github.com/fmaussion/salem/blob/master/salem/datasets.py#L263)

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  ENH: Optional Read-Only RasterIO backend 140063713

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 40.171ms · About: xarray-datasette