issue_comments
2 rows where issue = 140063713 and user = 1151287 sorted by updated_at descending
This data as json, CSV (advanced)
Suggested facets: created_at (date), updated_at (date)
issue 1
- ENH: Optional Read-Only RasterIO backend · 2 ✖
id | html_url | issue_url | node_id | user | created_at | updated_at ▲ | author_association | body | reactions | performed_via_github_app | issue |
---|---|---|---|---|---|---|---|---|---|---|---|
211351199 | https://github.com/pydata/xarray/issues/790#issuecomment-211351199 | https://api.github.com/repos/pydata/xarray/issues/790 | MDEyOklzc3VlQ29tbWVudDIxMTM1MTE5OQ== | perrygeo 1151287 | 2016-04-18T12:06:07Z | 2016-04-18T12:06:07Z | NONE | @IamJeffG thanks for the example. I didn't realize you'd already been integrating xarray with rasterio already. Is that library open source?
To clarify, I just want to make sure that clipping/reprojecting/resampling remains an explicit step. That's a great approach you outlined, I just wouldn't want any software to make those assumptions for me!
Agreed. We've been doing more testing on this topic and found that rasterio generally works as expected for positive-y rasters. But there are still some built-in assumptions about negative-y rasters that cause spectacular failures. It's still a work in progress... |
{ "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 | |
198343073 | https://github.com/pydata/xarray/issues/790#issuecomment-198343073 | https://api.github.com/repos/pydata/xarray/issues/790 | MDEyOklzc3VlQ29tbWVudDE5ODM0MzA3Mw== | perrygeo 1151287 | 2016-03-18T12:57:14Z | 2016-03-18T12:57:14Z | NONE | @fmaussion @jhamman re: projecting coordinates to lat-lng. If you consider the raster cells as independent points, you can project them independently but they will likely not be regularly spaced. With few exceptions, if you need to maintain a regular grid, transforming data between projections will alter the shape of the array and require resampling (GDAL and rasterio call the process "warping" to reflect this). There are decisions and tradeoffs to be considered with the various resampling methods, selecting new extents and cell sizes, etc so it's typically not something you want to do on-the-fly for analyses. I think keeping the xarray coordinates as generic cartesian x-y makes sense, at least initially. Even in many GIS tools, analysis is done on a naive 2D plane and it's assumed that the inputs are of the same projection. I'd recommend doing any reprojection outside of xarray as a pre-processing step (with e.g. |
{ "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
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 1