issue_comments
5 rows where author_association = "MEMBER", issue = 537772490 and user = 4160723 sorted by updated_at descending
This data as json, CSV (advanced)
Suggested facets: reactions, created_at (date), updated_at (date)
issue 1
- Idea: functionally-derived non-dimensional coordinates · 5 ✖
id | html_url | issue_url | node_id | user | created_at | updated_at ▲ | author_association | body | reactions | performed_via_github_app | issue |
---|---|---|---|---|---|---|---|---|---|---|---|
926829182 | https://github.com/pydata/xarray/issues/3620#issuecomment-926829182 | https://api.github.com/repos/pydata/xarray/issues/3620 | IC_kwDOAMm_X843Pkp- | benbovy 4160723 | 2021-09-24T18:13:25Z | 2021-09-24T18:13:25Z | MEMBER | @djhoese not yet but hopefully soon! Most of the work on explicit indexes is currently happening in #5692, which once merged (probably after the next release) will provide all the infrastructure for custom indexes. This is quite a big internal refactoring (bigger than I initially thought) that we cannot avoid as we're changing Xarray's core data model. After that, we'll need to update some public API (Xarray object constructors, |
{ "total_count": 1, "+1": 1, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Idea: functionally-derived non-dimensional coordinates 537772490 | |
865648105 | https://github.com/pydata/xarray/issues/3620#issuecomment-865648105 | https://api.github.com/repos/pydata/xarray/issues/3620 | MDEyOklzc3VlQ29tbWVudDg2NTY0ODEwNQ== | benbovy 4160723 | 2021-06-22T06:53:28Z | 2021-06-22T06:53:28Z | MEMBER | @djhoese you're right, I thought it was better to do all the internal refactoring first but we maybe shouldn't wait too long before updating |
{ "total_count": 1, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 1, "rocket": 0, "eyes": 0 } |
Idea: functionally-derived non-dimensional coordinates 537772490 | |
856081652 | https://github.com/pydata/xarray/issues/3620#issuecomment-856081652 | https://api.github.com/repos/pydata/xarray/issues/3620 | MDEyOklzc3VlQ29tbWVudDg1NjA4MTY1Mg== | benbovy 4160723 | 2021-06-07T16:25:13Z | 2021-06-08T07:34:09Z | MEMBER |
Yes, CRSIndex/WCSIndex will need to provide an implementation for the What will be probably more tricky is to find some common way to handle CRS for various indexes (e.g., regular gridded data vs. irregular data), probably via some class inheritance hierarchy or using mixins.
In case we load such data from a file/store, thanks to the Xarray backend system, maybe we won't even need a |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Idea: functionally-derived non-dimensional coordinates 537772490 | |
855720969 | https://github.com/pydata/xarray/issues/3620#issuecomment-855720969 | https://api.github.com/repos/pydata/xarray/issues/3620 | MDEyOklzc3VlQ29tbWVudDg1NTcyMDk2OQ== | benbovy 4160723 | 2021-06-07T08:29:15Z | 2021-06-08T07:32:45Z | MEMBER | We could also imagine ```python returns a new dataset with both pixel and world (possibly lazy) coordinates
so that we can directly select data either using the pixel coordinates...
...or using the world coordinates
the WCS index would be attached to both pixel and world dataset coordinates
|
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Idea: functionally-derived non-dimensional coordinates 537772490 | |
855710036 | https://github.com/pydata/xarray/issues/3620#issuecomment-855710036 | https://api.github.com/repos/pydata/xarray/issues/3620 | MDEyOklzc3VlQ29tbWVudDg1NTcxMDAzNg== | benbovy 4160723 | 2021-06-07T08:16:35Z | 2021-06-07T08:16:35Z | MEMBER | This looks like a nice use case for the forthcoming Xarray's custom index feature. How I see CRS/WCS-aware Xarray datasets with custom indexes:
For this use case a possible workflow would then be something like this: ```python create or open an Xarray dataset with x, y, z "pixel" (possibly lazy) coordinatesand set a WCS indexdataset = ( xr.Dataset(...) .set_index(['x', 'y', 'z'], WCSIndex, wcs_params={...}) ) select data using pixel coordinatesdataset.sel(x=..., y=..., z=...) select data using world coordinates (via the "astro" accessor,which may access methods/attributes of the WCS index)dataset.astro.sel_world(x=..., y=..., z=...) return a new dataset where the x,y,z "pixel" coordnates are replaced by the "world" coordinates(again using the WCS index, and propagating it to the returned dataset)world_dataset = dataset.astro.pixel_to_world(['x', 'y', 'z']) select data using world coordinatesworld_dataset.sel(x=..., y=..., z=...) select data using pixel coordinates (via the "astro" accessor)world_dataset.astro.sel_pixel(x=..., y=..., z=...) this could be revertedpixel_dataset = world_dataset.astro.world_to_pixel(['x', 'y', 'z']) assert pixel_dataset.identical(dataset) depending on the implementation in WCSIndex, would either raise an erroror implicitly convert to either pixel or world coordinatesxr.merge([world_dataset, another_pixel_dataset]) ``` |
{ "total_count": 2, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 2, "rocket": 0, "eyes": 0 } |
Idea: functionally-derived non-dimensional coordinates 537772490 |
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