issue_comments
11 rows where author_association = "CONTRIBUTOR" and user = 57705593 sorted by updated_at descending
This data as json, CSV (advanced)
Suggested facets: issue_url, reactions, created_at (date), updated_at (date)
user 1
- tovogt · 11 ✖
id | html_url | issue_url | node_id | user | created_at | updated_at ▲ | author_association | body | reactions | performed_via_github_app | issue |
---|---|---|---|---|---|---|---|---|---|---|---|
1287864880 | https://github.com/pydata/xarray/issues/7186#issuecomment-1287864880 | https://api.github.com/repos/pydata/xarray/issues/7186 | IC_kwDOAMm_X85Mw0Iw | tovogt 57705593 | 2022-10-22T17:37:05Z | 2022-10-22T17:37:41Z | CONTRIBUTOR | The reason for this behavior is that the A quick workaround for you might be to encode the string as |
{ "total_count": 1, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 1, "rocket": 0, "eyes": 0 } |
netCDF4: support byte strings as attribute values 1414669747 | |
1069096876 | https://github.com/pydata/xarray/issues/6310#issuecomment-1069096876 | https://api.github.com/repos/pydata/xarray/issues/6310 | IC_kwDOAMm_X84_uR-s | tovogt 57705593 | 2022-03-16T12:55:28Z | 2022-03-16T12:55:28Z | CONTRIBUTOR | Yes, I tested this locally, and here is the PR for that suggestion: #6366 |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Only auxiliary coordinates are listed in nc variable attribute 1154014066 | |
1069089232 | https://github.com/pydata/xarray/issues/6310#issuecomment-1069089232 | https://api.github.com/repos/pydata/xarray/issues/6310 | IC_kwDOAMm_X84_uQHQ | tovogt 57705593 | 2022-03-16T12:46:33Z | 2022-03-16T12:46:33Z | CONTRIBUTOR | No, in this case I think the problem is that the author of line 773 assumed that |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Only auxiliary coordinates are listed in nc variable attribute 1154014066 | |
1069073130 | https://github.com/pydata/xarray/issues/6310#issuecomment-1069073130 | https://api.github.com/repos/pydata/xarray/issues/6310 | IC_kwDOAMm_X84_uMLq | tovogt 57705593 | 2022-03-16T12:27:14Z | 2022-03-16T12:27:14Z | CONTRIBUTOR | @DWesl Thanks for digging into the details of the CF! I read your post in the sense that solution (1) is the one to choose. I have one more question though before we close this: When setting |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Only auxiliary coordinates are listed in nc variable attribute 1154014066 | |
1068869457 | https://github.com/pydata/xarray/issues/6310#issuecomment-1068869457 | https://api.github.com/repos/pydata/xarray/issues/6310 | IC_kwDOAMm_X84_tadR | tovogt 57705593 | 2022-03-16T08:39:02Z | 2022-03-16T08:40:08Z | CONTRIBUTOR | Hey @dcherian, Thanks for your consideration! I just started to create a new branch with my suggested changes, but then I noticed that setting the In my original post, the example can easily be fixed to reflect the coordinate attributes in the conventions (https://cfconventions.org/cf-conventions/cf-conventions.html#_single_trajectory) by enforcing the attribute value in the From here, there are several ways to proceed:
1. Stick to the current logic which might be non-conformal with the CF conventions in case of "Discrete Sampling Geometries". However, users can manually fix this by setting the I actually suggest to choose solution (1) and close this issue as "won't fix". What do you think? |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Only auxiliary coordinates are listed in nc variable attribute 1154014066 | |
1054195542 | https://github.com/pydata/xarray/issues/6310#issuecomment-1054195542 | https://api.github.com/repos/pydata/xarray/issues/6310 | IC_kwDOAMm_X84-1b9W | tovogt 57705593 | 2022-02-28T12:13:46Z | 2022-02-28T12:33:07Z | CONTRIBUTOR | If you are interested in a fix, I would modify the following section:
https://github.com/pydata/xarray/blob/613a8fda4f07181fbc41d6ff2296fec3726fd351/xarray/conventions.py#L726-L744
The So, this issue is about including the non-auxiliary coordinates by default because it's permissible in general, and it is even required for so-called "Discrete Sampling Geometries". |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Only auxiliary coordinates are listed in nc variable attribute 1154014066 | |
1028730657 | https://github.com/pydata/xarray/issues/6174#issuecomment-1028730657 | https://api.github.com/repos/pydata/xarray/issues/6174 | IC_kwDOAMm_X849US8h | tovogt 57705593 | 2022-02-03T08:39:45Z | 2022-02-03T08:41:16Z | CONTRIBUTOR |
Thanks for the hint! Unfortunately, it says already in the docstring that "it is no different than calling to_netcdf repeatedly". And I explained in my OP that this would cause repeated file open/close operations - which is the whole point of this issue. Furthermore, when using However, it might still be the way to go API-wise. So, when talking about the solution of this issue, we could aim at fixing |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
[FEATURE]: Read from/write to several NetCDF4 groups with a single file open/close operation 1108138101 | |
1019879801 | https://github.com/pydata/xarray/issues/6174#issuecomment-1019879801 | https://api.github.com/repos/pydata/xarray/issues/6174 | IC_kwDOAMm_X848yiF5 | tovogt 57705593 | 2022-01-24T09:16:40Z | 2022-01-24T09:16:40Z | CONTRIBUTOR |
Here is my PR for the docstring improvements: https://github.com/pydata/xarray/pull/6187 |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
[FEATURE]: Read from/write to several NetCDF4 groups with a single file open/close operation 1108138101 | |
1019849836 | https://github.com/pydata/xarray/issues/6174#issuecomment-1019849836 | https://api.github.com/repos/pydata/xarray/issues/6174 | IC_kwDOAMm_X848yaxs | tovogt 57705593 | 2022-01-24T08:43:36Z | 2022-01-24T08:43:36Z | CONTRIBUTOR | It's not at all tricky to implement the listing of groups in a NETCDF4 file, at least not for the "netcdf4" engine. The code for that is in my OP above: ```python def _xr_nc4_groups_from_store(store): """List all groups contained in the given NetCDF4 data store
``` |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
[FEATURE]: Read from/write to several NetCDF4 groups with a single file open/close operation 1108138101 | |
1018257806 | https://github.com/pydata/xarray/issues/6174#issuecomment-1018257806 | https://api.github.com/repos/pydata/xarray/issues/6174 | IC_kwDOAMm_X848sWGO | tovogt 57705593 | 2022-01-21T07:40:55Z | 2022-01-21T07:46:06Z | CONTRIBUTOR | When I first posted this issue, I thought, the best solution is to just implement my proposed helper functions as part of the official xarray API. I don't think our project would add DataTree as a new dependency just for this as long as we have a very easy and viable solution of ourselves. But now I have a new idea. At first, I noticed that |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
[FEATURE]: Read from/write to several NetCDF4 groups with a single file open/close operation 1108138101 | |
1017298572 | https://github.com/pydata/xarray/issues/6174#issuecomment-1017298572 | https://api.github.com/repos/pydata/xarray/issues/6174 | IC_kwDOAMm_X848or6M | tovogt 57705593 | 2022-01-20T09:53:16Z | 2022-01-20T09:53:32Z | CONTRIBUTOR | Thanks for your quick response, Tom! I'm sure that DataTree is a really neat solution for most people working with hierarchically structured data. In my case, we are talking about a very unusual application of the NetCDF4 groups feature: We store literally thousands of very small NetCDF datasets in a single file. A file containing 3000 datasets is typically not larger than 100 MB. With that setup, the I/O performance is critical. Opening and closing the file on each group read/write is very, very bad. On our cluster this means that writing that 100 MB file takes 10 hours with your DataTree implementation, and 30 minutes with my helper functions. For reading, the effect is smaller, but still noticeable. So, my request is really about the I/O performance, and I don't need a full-fledged hierarchical data management API in xarray for that. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
[FEATURE]: Read from/write to several NetCDF4 groups with a single file open/close operation 1108138101 |
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]);
issue 3