html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue https://github.com/pydata/xarray/issues/1626#issuecomment-1112231763,https://api.github.com/repos/pydata/xarray/issues/1626,1112231763,IC_kwDOAMm_X85CS09T,601177,2022-04-28T13:51:17Z,2022-04-28T13:51:17Z,NONE,"> If this issue remains relevant, please comment here or remove the `stale` label; otherwise it will be marked as closed automatically Still relevant.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,264582338 https://github.com/pydata/xarray/issues/4220#issuecomment-1070998603,https://api.github.com/repos/pydata/xarray/issues/4220,1070998603,IC_kwDOAMm_X84_1iRL,601177,2022-03-17T15:46:28Z,2022-03-17T15:46:28Z,NONE,"Issue still present in recent xarray.
Output of xr.show_versions() INSTALLED VERSIONS ------------------ commit: None python: 3.9.9 (main, Jan 9 2022, 21:37:30) [GCC 11.2.0] python-bits: 64 OS: Linux OS-release: 5.15.26-gentoo-a machine: x86_64 processor: AMD Ryzen 7 PRO 4750U with Radeon Graphics byteorder: little LC_ALL: None LANG: nl_NL.UTF-8 LOCALE: ('nl_NL', 'UTF-8') libhdf5: 1.10.5 libnetcdf: 4.8.1 xarray: 0.21.1 pandas: 1.4.1 numpy: 1.22.2 scipy: 1.7.3 netCDF4: 1.5.8 pydap: None h5netcdf: None h5py: 3.3.0 Nio: None zarr: None cftime: 1.5.2 nc_time_axis: None PseudoNetCDF: None rasterio: None cfgrib: None iris: None bottleneck: 1.3.2 dask: 2022.02.0 distributed: None matplotlib: 3.5.1 cartopy: None seaborn: 0.11.2 numbagg: None fsspec: 2022.01.0 cupy: None pint: None sparse: None setuptools: 60.9.2 pip: 22.0.3 conda: None pytest: None IPython: 7.31.1 sphinx: 4.4.0 /usr/lib/python3.9/site-packages/_distutils_hack/__init__.py:30: UserWarning: Setuptools is replacing distutils. warnings.warn(""Setuptools is replacing distutils."")
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,656089264 https://github.com/pydata/xarray/issues/2888#issuecomment-660142287,https://api.github.com/repos/pydata/xarray/issues/2888,660142287,MDEyOklzc3VlQ29tbWVudDY2MDE0MjI4Nw==,601177,2020-07-17T14:36:57Z,2020-07-17T14:36:57Z,NONE,"Even if version information is (not yet) available, this would be very useful. Currently, when packaging xarray for downstream distributions, it is a very burdensome task to piece together which optional dependencies there are in the first place. I understand that dealing with the backlog makes this a rather tedious task, but making it a requirement going forward to add such dependency information whenever a dependency is changed or added would be required in any case.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,432058005 https://github.com/pydata/xarray/issues/1888#issuecomment-571806712,https://api.github.com/repos/pydata/xarray/issues/1888,571806712,MDEyOklzc3VlQ29tbWVudDU3MTgwNjcxMg==,601177,2020-01-07T22:41:44Z,2020-01-07T22:41:44Z,NONE,"> If this issue remains relevant, please comment here or remove the `stale` label; otherwise it will be marked as closed automatically I think this is still relevant. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,294380515 https://github.com/pydata/xarray/issues/3343#issuecomment-535169724,https://api.github.com/repos/pydata/xarray/issues/3343,535169724,MDEyOklzc3VlQ29tbWVudDUzNTE2OTcyNA==,601177,2019-09-25T19:13:46Z,2019-09-25T19:13:46Z,NONE,"> you might be able to achieve what you want by using [`swap_dims`](https://xarray.pydata.org/en/latest/generated/xarray.DataArray.swap_dims.html) Yes, that is a nice workaround (I used another, less convenient one). But I would say that the current (lack of) functionality is a bug: the documentation talks about coordinates, not about dimensions. Moreover, it seems like something one would want to support. I do not know how complicated this would be to implement, but if reasonably feasible, I would request to keep this issue open. ","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,498297720 https://github.com/pydata/xarray/issues/2802#issuecomment-469885042,https://api.github.com/repos/pydata/xarray/issues/2802,469885042,MDEyOklzc3VlQ29tbWVudDQ2OTg4NTA0Mg==,601177,2019-03-05T22:31:44Z,2019-03-05T22:31:44Z,NONE,"> Is this a dupe of #1431 ? Yes. My example and explanation are a bit clearer, so I do not know which would be best to close. In any case, I hope this is considered for fixing separately from some big refactoring of the MultiIndex machinery, which seems to have stalled. This seems like a corner case that might not be too big, but I may be mistaken. ","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,417412201 https://github.com/pydata/xarray/issues/1626#issuecomment-363129063,https://api.github.com/repos/pydata/xarray/issues/1626,363129063,MDEyOklzc3VlQ29tbWVudDM2MzEyOTA2Mw==,601177,2018-02-05T15:59:50Z,2018-02-05T22:01:35Z,NONE,"I'd also like to see better support for compound types, writing them for starters. I'll collect some information here: * In the code @tfurf linked to ([_nc4_values_and_dtype](https://github.com/pydata/xarray/blob/27132fba1e465955e76ed155ba6cbb769c0904df/xarray/backends/netCDF4_.py#L81)), an `elif` needs to be added to catch structured dtypes. I think they have `kind == 'V'`. * [`dtype.builtin`](https://docs.scipy.org/doc/numpy/reference/generated/numpy.dtype.isbuiltin.html) can be used to detect whether we are indeed dealing with a structured type. Namely `dtype.builtin` must be `0`. * The structured type must fist be added to the `netCDF4.Dataset` using its method [`createCompoundType`](https://unidata.github.io/netcdf4-python/#netCDF4.Dataset.createCompoundType). This must be done recursively, with the deepest levels first. * The netCDF variable is created in [`prepare_variable`](https://github.com/pydata/xarray/blob/27132fba1e465955e76ed155ba6cbb769c0904df/xarray/backends/netCDF4_.py#L311), which calls `_nc4_values_and_dtype`. There, via `self.ds` we also have access to the netCDF4 `Dataset` to be used for the creation of the as mentioned above. [However, is `self.ds` really the Dataset, or some `NetCDF4.Group`?](https://github.com/pydata/xarray/blob/27132fba1e465955e76ed155ba6cbb769c0904df/xarray/backends/netCDF4_.py#L112) In any case `_nc4_values_and_dtype` and its use in `prepare_variable` needs to be refactored, because we need access to the underlying netCDF4 `Dataset`. Is there anything I've missed? Can someone shed light on whether `self.ds` in `prepare_variable` can be assumed to the underlying netCDF4 `Dataset`?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,264582338 https://github.com/pydata/xarray/issues/1092#issuecomment-363090775,https://api.github.com/repos/pydata/xarray/issues/1092,363090775,MDEyOklzc3VlQ29tbWVudDM2MzA5MDc3NQ==,601177,2018-02-05T13:53:55Z,2018-02-05T13:53:55Z,NONE,"I'm late to the discussion and may be repeating some things essentially already said, but I'd still like to add a further voice. @shoyer said on 8 Nov 2016: > I am reluctant to add the additional complexity of groups directly into the `xarray.Dataset` data model. For example, how do groups get updated when you slice, aggregate or concatenate datasets? The rules for coordinates are already pretty complex. If you prepend the paths to all the names (of dimensions, coordinate variables, and variables) and use the resulting strings as names, don't you just get a collection that would fit right in a `xarray.Dataset`? (Perhaps I'm just repeating what @lamorton said on 28 Mar 2017.) My feeling is that the only thing missing would be coordinate variables defined in a group closer to the root of the hierarchy, but that needs to be dealt with anyway if you want to read from netCDF4 files correctly (see my #1888). My guess would be that having groups inherit all the dimensions/coordinates of their parent that they do not redefine should be the way to go. My use case is data from a single metmast over time. There are various instruments measuring all kinds of variables of which 10-minute statistics are recorded. I use groups to keep an overview. (I use something like `/[wind|air|prec]//`, `//`, or `///statistic` as a hierarchy.) Slicing along the time axis for the whole hierarchy would make perfect sense. @shoyer said on 30 Mar 2017: > We would possibly want to make another `Dataset` subclass for the sub-datasets to ensure that their variables are linked to the parent, e.g., `xarray.LinkedDataset`. This would enable `ds['flux']['poloidal'] = subset`. > > But I'm also not convinced this is actually worth the trouble given how easy it is to write `ds['flux', 'poloidal']`. I would prefer the former option, as it more clearly shows the hierarchical nature. If also copying the netCDF4-path-separator-convention, then `ds['flux/poloidal']` is shorter than `ds['flux', 'poloidal']`. (Allowing `Dataset` or `DataArray` to have names that include '/' would be dangerous anyway in view of netCDF4 serialization.)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,187859705