issue_comments
8 rows where author_association = "MEMBER" and issue = 537772490 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 · 8 ✖
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 | |
565671981 | https://github.com/pydata/xarray/issues/3620#issuecomment-565671981 | https://api.github.com/repos/pydata/xarray/issues/3620 | MDEyOklzc3VlQ29tbWVudDU2NTY3MTk4MQ== | dcherian 2448579 | 2019-12-14T02:18:15Z | 2019-12-14T02:19:17Z | MEMBER | I should have said "discrete lazily evaluated form (which we support through dask)". I think we already have what you want in principle (caveats at the end). Here's an example: ``` python import dask import numpy as np import xarray as xr xr.set_options(display_style="html") def arbitrary_function(dataset): return dataset["a"] * dataset["wavelength"] * dataset.attrs["wcs_param"] ds = xr.Dataset() construct a dask array.In practice this could represent an on-disk dataset,with data reads only occurring when necessaryds["a"] = xr.DataArray(dask.array.ones((10,)), dims=["wavelength"], coords={"wavelength": np.arange(10)}) some coordinate system parameterds.attrs["wcs_param"] = 1.0 complicated pixel to world functionno compute happens since we are working with dask arraysso this is quite cheap.ds.coords["azimuth"] = arbitrary_function(ds) ds ``` So you can carry around your coordinate system parameters in the Both 'a' and 'azimuth' are computed now, since actual values are required to plotds.a.plot(x="azimuth")
```
In practice, there are a few limitations. @djhoese and @snowman2 may have useful perspective here.
Additional info: 1. https://docs.dask.org/en/latest/array.html 2. https://xarray.pydata.org/en/stable/dask.html 3. https://blog.dask.org/2019/06/20/load-image-data PS: If it helps, I'd be happy to chat over skype for a half hour getting you oriented with how we do things. |
{ "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 | |
565625792 | https://github.com/pydata/xarray/issues/3620#issuecomment-565625792 | https://api.github.com/repos/pydata/xarray/issues/3620 | MDEyOklzc3VlQ29tbWVudDU2NTYyNTc5Mg== | dcherian 2448579 | 2019-12-13T22:05:07Z | 2019-12-13T22:05:07Z | MEMBER | It would also be good to hear about "sub-pixel metadata" → this seems to be the main reason why you want to carry around the analytic rather than the discrete evaluated form (which we basically support through dask). Is that right or am I missing something? |
{ "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 | |
565622345 | https://github.com/pydata/xarray/issues/3620#issuecomment-565622345 | https://api.github.com/repos/pydata/xarray/issues/3620 | MDEyOklzc3VlQ29tbWVudDU2NTYyMjM0NQ== | rabernat 1197350 | 2019-12-13T21:53:55Z | 2019-12-13T21:53:55Z | MEMBER | Thanks for reaching out Erik! We’d love to find a way to better support Astro data in xarray. Before digging deeper, I just want to ask a clarification question. When you say “arbitrary complex mathematical functions”: what are the arguments / inputs to these functions? Presumably they have to be evaluated at some point, ie for plotting. Can you describe what happens when the time comes to turn the arbitrary functions to actual numbers? Your answer will help us respond more accurately to your question.
|
{ "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 |
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