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/1068#issuecomment-582288134,https://api.github.com/repos/pydata/xarray/issues/1068,582288134,MDEyOklzc3VlQ29tbWVudDU4MjI4ODEzNA==,3404817,2020-02-05T08:06:28Z,2020-02-05T08:06:28Z,CONTRIBUTOR,"Yes, seems like a redirect issue. The URL is fine.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,186169975 https://github.com/pydata/xarray/issues/1354#issuecomment-499367730,https://api.github.com/repos/pydata/xarray/issues/1354,499367730,MDEyOklzc3VlQ29tbWVudDQ5OTM2NzczMA==,3404817,2019-06-06T06:33:44Z,2019-06-06T06:33:44Z,CONTRIBUTOR,"Thanks for reminding me, stalte bot, this is still relevant to me. I think your proposed solution @shoyer would solve this issue perfectly: expose `align`'s `join` parameter in the `concat` function - and please also in `open_mfdataset`. Would you like a PR for this?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,219692578 https://github.com/pydata/xarray/issues/1823#issuecomment-489064553,https://api.github.com/repos/pydata/xarray/issues/1823,489064553,MDEyOklzc3VlQ29tbWVudDQ4OTA2NDU1Mw==,3404817,2019-05-03T11:26:06Z,2019-05-03T11:36:44Z,CONTRIBUTOR,"The original issue of this thread is that you sometimes might want to *disable* alignment checks for coordinates other than the `concat_dim` and only check for same dimensions and dimension shapes. When you `xr.merge` with `join='exact'`, it still checks for alignment (see https://github.com/pydata/xarray/pull/1330#issuecomment-302711852), but does not join the coordinates if they are not aligned. This behavior (not joining) is also included in what @rabernat envisioned here, but his suggestion goes beyond that: you don't even load coordinate values from all but the first dataset and just blindly trust that they are aligned. So `xr.open_mfdataset(join='exact', coords='minimal')` does not fix this issue here, I think.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,288184220 https://github.com/pydata/xarray/pull/2096#issuecomment-385661908,https://api.github.com/repos/pydata/xarray/issues/2096,385661908,MDEyOklzc3VlQ29tbWVudDM4NTY2MTkwOA==,3404817,2018-05-01T12:41:08Z,2018-05-01T12:41:08Z,CONTRIBUTOR,"> I'm confused. It seems that I did exactly this a while ago @fmaussion don't be. You are perfectly right, we worked on the same line of code, only that I was about 50 PRs earlier, hence the merge conflict. I'll close this.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,319132629 https://github.com/pydata/xarray/pull/2096#issuecomment-385624187,https://api.github.com/repos/pydata/xarray/issues/2096,385624187,MDEyOklzc3VlQ29tbWVudDM4NTYyNDE4Nw==,3404817,2018-05-01T08:26:45Z,2018-05-01T08:26:45Z,CONTRIBUTOR,"That single AppVeyor CI fail is because the py27 32bit conda environment cannot be created: ``` ResolvePackageNotFound: - cftime ```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,319132629 https://github.com/pydata/xarray/pull/1965#issuecomment-385612859,https://api.github.com/repos/pydata/xarray/issues/1965,385612859,MDEyOklzc3VlQ29tbWVudDM4NTYxMjg1OQ==,3404817,2018-05-01T07:03:53Z,2018-05-01T07:03:53Z,CONTRIBUTOR,"> mind freshening up this PR I deleted my fork in the meantime. I opened a new PR at #2096 and fixed the merge conflict there.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,302447879 https://github.com/pydata/xarray/pull/1965#issuecomment-371758069,https://api.github.com/repos/pydata/xarray/issues/1965,371758069,MDEyOklzc3VlQ29tbWVudDM3MTc1ODA2OQ==,3404817,2018-03-09T09:19:38Z,2018-03-09T09:19:38Z,CONTRIBUTOR,"> Can you add a brief note on the bug fix in whats-new? Done.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,302447879 https://github.com/pydata/xarray/pull/1965#issuecomment-370571480,https://api.github.com/repos/pydata/xarray/issues/1965,370571480,MDEyOklzc3VlQ29tbWVudDM3MDU3MTQ4MA==,3404817,2018-03-05T21:25:53Z,2018-03-06T07:18:40Z,CONTRIBUTOR,"I can see `netcdftime` is casting the time numbers to `float64`: https://github.com/Unidata/netcdftime/blob/e745434547de728d53cde6316cae75b62db102e2/netcdftime/_netcdftime.pyx#L241 like I also suggested for https://github.com/pydata/xarray/pull/1863#issuecomment-361089977. How about we do that, too?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,302447879 https://github.com/pydata/xarray/pull/1965#issuecomment-370568574,https://api.github.com/repos/pydata/xarray/issues/1965,370568574,MDEyOklzc3VlQ29tbWVudDM3MDU2ODU3NA==,3404817,2018-03-05T21:16:28Z,2018-03-05T21:29:19Z,CONTRIBUTOR,"Seems like this issue only exists on Windows. See https://ci.appveyor.com/project/shoyer/xray/build/1.0.3782/job/yjodrbenev1tw5y7#L4686 (The Travis failure is due to a failing build.)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,302447879 https://github.com/pydata/xarray/issues/597#issuecomment-370381376,https://api.github.com/repos/pydata/xarray/issues/597,370381376,MDEyOklzc3VlQ29tbWVudDM3MDM4MTM3Ng==,3404817,2018-03-05T10:49:19Z,2018-03-05T10:49:19Z,CONTRIBUTOR,Can't this be closed?,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,109202603 https://github.com/pydata/xarray/issues/1859#issuecomment-361091210,https://api.github.com/repos/pydata/xarray/issues/1859,361091210,MDEyOklzc3VlQ29tbWVudDM2MTA5MTIxMA==,3404817,2018-01-28T20:01:10Z,2018-01-28T20:01:52Z,CONTRIBUTOR,I found out why the issue is absent in the current implementation. Please see https://github.com/pydata/xarray/pull/1863#issuecomment-361091073. That PR adds the test you asked for @shoyer. It passes in the current version and fails in `v0.10.0`.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,291565176 https://github.com/pydata/xarray/pull/1863#issuecomment-361091073,https://api.github.com/repos/pydata/xarray/issues/1863,361091073,MDEyOklzc3VlQ29tbWVudDM2MTA5MTA3Mw==,3404817,2018-01-28T19:59:23Z,2018-01-28T19:59:23Z,CONTRIBUTOR,"> Store _NS_PER_TIME_DELTA values as int, then numpy will do the casting. Haha, OK, this is actually what you implemented in https://github.com/pydata/xarray/commit/50b0a69a7aa0fb7ac3afb28e7bd971cf08055f99: https://github.com/pydata/xarray/blob/50b0a69a7aa0fb7ac3afb28e7bd971cf08055f99/xarray/coding/times.py#L32-L37 So that is why it works now. Case closed, I guess.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,292231408 https://github.com/pydata/xarray/pull/1863#issuecomment-361089977,https://api.github.com/repos/pydata/xarray/issues/1863,361089977,MDEyOklzc3VlQ29tbWVudDM2MTA4OTk3Nw==,3404817,2018-01-28T19:45:49Z,2018-01-28T19:48:09Z,CONTRIBUTOR,"I believe the issue originates in these lines: https://github.com/pydata/xarray/blob/ac854f081d4b57d292755d3aff1476f8e2e2da11/xarray/conventions.py#L174-L175 where we multiply the `num_dates` with some `float` value and then cast to `int64`. If `num_dates` is `float32`, numpy keeps `float32` when multiplying with e.g. 1e9 and that somehow introduces an error. Here is a stripped version of the above: ```python flat_num_dates = np.arange(100).astype('float32') n = 1e9 roundtripped = (flat_num_dates * n).astype(np.int64) / n assert np.all(flat_num_dates == roundtripped) ``` By the way, the factor has to be large, like `1e9`. E.g. `1e6` (`'ms since ...'`) won't give the error. The weird thing is that the corresponding code in the current `master` is identical: https://github.com/pydata/xarray/blob/50b0a69a7aa0fb7ac3afb28e7bd971cf08055f99/xarray/coding/times.py#L151-L152 I will look into why the result is still different from `v0.10.0`. Also, if this really is the origin of the error, there are two easy ways to avoid this: 1. Cast `flat_num_dates` to `float64`: `(flat_num_dates.astype(np.float64) * n).astype(np.int64)` 2. Store `_NS_PER_TIME_DELTA` values as `int`, then `numpy` will do the casting.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,292231408 https://github.com/pydata/xarray/pull/1863#issuecomment-361089805,https://api.github.com/repos/pydata/xarray/issues/1863,361089805,MDEyOklzc3VlQ29tbWVudDM2MTA4OTgwNQ==,3404817,2018-01-28T19:43:21Z,2018-01-28T19:43:21Z,CONTRIBUTOR,"For comparison, I added the same test to the `0.10.0` version in https://github.com/j08lue/xarray/tree/0p10-f4-time-decode, where it fails: ``` pytest -v xarray\tests\test_conventions.py ... > self.assertArrayEqual(expected, actual_cmp) E AssertionError: E Arrays are not equal E E (mismatch 90.0%) E x: array([datetime.datetime(2000, 1, 1, 0, 0), E datetime.datetime(2000, 1, 2, 0, 0), E datetime.datetime(2000, 1, 3, 0, 0),... E y: array(['2000-01-01T00:00:00.000000', '2000-01-02T00:00:00.003211', E '2000-01-03T00:00:00.006422', '2000-01-04T00:00:00.001245', E '2000-01-05T00:00:00.012845', '2000-01-06T00:00:00.024444',... ```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,292231408 https://github.com/pydata/xarray/issues/1859#issuecomment-360782050,https://api.github.com/repos/pydata/xarray/issues/1859,360782050,MDEyOklzc3VlQ29tbWVudDM2MDc4MjA1MA==,3404817,2018-01-26T13:17:46Z,2018-01-26T13:17:46Z,CONTRIBUTOR,"> PR with a test I'll see if I can find the time in the next few days.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,291565176 https://github.com/pydata/xarray/issues/1140#issuecomment-281075869,https://api.github.com/repos/pydata/xarray/issues/1140,281075869,MDEyOklzc3VlQ29tbWVudDI4MTA3NTg2OQ==,3404817,2017-02-20T13:13:07Z,2017-02-20T13:13:07Z,CONTRIBUTOR,"@JamesSample excellent work confirming the limited scope. I am quite sure that the issue is with this line: https://github.com/pydata/xarray/blob/v0.9.1/xarray/core/variable.py#L375-L376 ``` dims = tuple(dim for k, dim in zip(key, self.dims) if not isinstance(k, (int, np.integer))) ``` When you run the test case I added in #1184, you will see that, inside `__getitem__`, `key` is a tuple with an empty array inside (`key = (np.array(0, dtype=np.int64),)`). With that value, ``` isinstance(key[0], (int, np.integer)) ``` is `False` on 64 bit Windows and so `dims=('time',)`, which has length 1. But `values = self._indexable_data[key]` gives a zero-dimension array, such that `values.ndim == 0`... I am unable to tell which of the two sides of the `assertion` expression is unexpected...","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,192122307 https://github.com/pydata/xarray/issues/1140#issuecomment-281038974,https://api.github.com/repos/pydata/xarray/issues/1140,281038974,MDEyOklzc3VlQ29tbWVudDI4MTAzODk3NA==,3404817,2017-02-20T10:13:45Z,2017-02-20T10:13:45Z,CONTRIBUTOR,"@JamesSample Thanks for restoring my credibility a bit here... But, no, I did not figure this out yet. Appveyor apparently does not have the combination Windows 64 bit + Python 2.7 (https://ci.appveyor.com/project/jhamman/xarray-injyf/build/1.0.659), maybe that is why it does not reproduce the error?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,192122307 https://github.com/pydata/xarray/issues/1140#issuecomment-269136711,https://api.github.com/repos/pydata/xarray/issues/1140,269136711,MDEyOklzc3VlQ29tbWVudDI2OTEzNjcxMQ==,3404817,2016-12-25T20:41:41Z,2016-12-25T20:41:41Z,CONTRIBUTOR,"Yes, this is Python 2. :flushed: Let's see what Travis & Co say.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,192122307 https://github.com/pydata/xarray/issues/1068#issuecomment-263007655,https://api.github.com/repos/pydata/xarray/issues/1068,263007655,MDEyOklzc3VlQ29tbWVudDI2MzAwNzY1NQ==,3404817,2016-11-25T18:21:05Z,2016-11-25T18:21:05Z,CONTRIBUTOR,"@jenfly did you find a solution how to make opendap authentication work with `xarray`? Might be worthwhile posting it here, even though the issue has to do with the backends.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,186169975 https://github.com/pydata/xarray/issues/1132#issuecomment-262557502,https://api.github.com/repos/pydata/xarray/issues/1132,262557502,MDEyOklzc3VlQ29tbWVudDI2MjU1NzUwMg==,3404817,2016-11-23T16:06:46Z,2016-11-23T16:06:46Z,CONTRIBUTOR,"Great, `safe_cast_to_index` works nicely (it passes my test). I added the change to the existing PR. Do we need to add more groupby tests to make sure the solution is safe for other cases (e.g. other data types)?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,190683531 https://github.com/pydata/xarray/issues/1132#issuecomment-262233644,https://api.github.com/repos/pydata/xarray/issues/1132,262233644,MDEyOklzc3VlQ29tbWVudDI2MjIzMzY0NA==,3404817,2016-11-22T12:56:03Z,2016-11-22T13:21:04Z,CONTRIBUTOR,"OK, here is the minimal example: ```python import xarray as xr import pandas as pd def test_groupby_da_datetime(): """"""groupby with a DataArray of dtype datetime"""""" # create test data times = pd.date_range('2000-01-01', periods=4) foo = xr.DataArray([1,2,3,4], coords=dict(time=times), dims='time') # create test index dd = times.to_datetime() reference_dates = [dd[0], dd[2]] labels = reference_dates[0:1]*2 + reference_dates[1:2]*2 ind = xr.DataArray(labels, coords=dict(time=times), dims='time', name='reference_date') # group foo by ind g = foo.groupby(ind) # check result actual = g.sum(dim='time') expected = xr.DataArray([3,7], coords=dict(reference_date=reference_dates), dims='reference_date') assert actual.to_dataset(name='foo').equals(expected.to_dataset(name='foo')) ``` Making that, I found out that the problem only occurs when the DataArray used with `groupby` has **`dtype=datetime64[ns]`**. The problem is that we effectively feed the DataArray to [`pd.factorize`](http://pandas.pydata.org/pandas-docs/stable/generated/pandas.factorize.html) and that goes well for most data types: Pandas checks with the function [`needs_i8_conversion`](https://github.com/pandas-dev/pandas/blob/v0.19.1/pandas/types/common.py#L248-L251) whether it can factorize the DataArray and decides YES for our `datetime64[ns]`. But then [in `pd.factorize`](https://github.com/pandas-dev/pandas/blob/v0.19.1/pandas/core/algorithms.py#L295-L307) it fails because it tries to access `DataArray.view` to convert to `int64`. So as I see it there are three possible solutions to this: 1. Make Pandas' `pd.factorize` handle our `datetime` DataArrays better, 2. Add an attribute `.view` to DataArrays, or 3. Use the solution in the above PR, which means feeding only the NumPy `.values` to `pd.factorize`.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,190683531 https://github.com/pydata/xarray/issues/992#issuecomment-258949295,https://api.github.com/repos/pydata/xarray/issues/992,258949295,MDEyOklzc3VlQ29tbWVudDI1ODk0OTI5NQ==,3404817,2016-11-07T20:14:37Z,2016-11-07T20:14:37Z,CONTRIBUTOR,"Great to see you are pushing forward on this issue @jhamman and @shoyer. I would really have liked to contribute here, but it seems like there are quite some design choices to make, which are better left in your hands. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,173773358 https://github.com/pydata/xarray/issues/992#issuecomment-243367823,https://api.github.com/repos/pydata/xarray/issues/992,243367823,MDEyOklzc3VlQ29tbWVudDI0MzM2NzgyMw==,3404817,2016-08-30T08:22:32Z,2016-08-30T08:22:32Z,CONTRIBUTOR,"@jhamman sorry, I only now saw that you pointed to a previous issue on the same topic (with exactly the same considerations). I did not find that issue when I searched (for ""unlimited""). You were against changing `to_netcdf` [then](https://github.com/pydata/xarray/issues/678#issuecomment-164082151). Are you still? ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,173773358 https://github.com/pydata/xarray/issues/992#issuecomment-243365966,https://api.github.com/repos/pydata/xarray/issues/992,243365966,MDEyOklzc3VlQ29tbWVudDI0MzM2NTk2Ng==,3404817,2016-08-30T08:14:08Z,2016-08-30T08:14:08Z,CONTRIBUTOR,"The above solution would not require much more than that, in [`set_necessary_dimensions`](https://github.com/pydata/xarray/blob/master/xarray/backends/common.py#L222-L225), ``` def set_necessary_dimensions(self, variable): for d, l in zip(variable.dims, variable.shape): if d not in self.dimensions: self.set_dimension(d, l) ``` would become ``` def set_necessary_dimensions(self, variable): for d, l in zip(variable.dims, variable.shape): if d in self._unlimited_dimensions: l = None if d not in self.dimensions: self.set_dimension(d, l) ``` ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,173773358 https://github.com/pydata/xarray/issues/992#issuecomment-243364284,https://api.github.com/repos/pydata/xarray/issues/992,243364284,MDEyOklzc3VlQ29tbWVudDI0MzM2NDI4NA==,3404817,2016-08-30T08:06:49Z,2016-08-30T08:07:07Z,CONTRIBUTOR,"But maybe the `encoding` dict is not the way to go after all, since it contains entries per **variable**, while it is the **dimension** that must be unlimited. Currently the dataset variables can be created in any order and their necessary dimensions created whenever needed (in the [`set_necessary_dimensions`](https://github.com/pydata/xarray/blob/master/xarray/backends/common.py#L222-L225) function). I would **not** like to change that logic (e.g. towards creating all dimensions required by all variables first, before adding the data variables). So how about a new kw argument to `to_netcdf`, like ``` ds.to_netcdf(unlimited_dimensions=['time']) ``` or ``` ds.to_netcdf(dimension_unlimited={'time': True}) ``` (the second option better for explicitly setting {'time': False})? ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,173773358 https://github.com/pydata/xarray/issues/992#issuecomment-243350429,https://api.github.com/repos/pydata/xarray/issues/992,243350429,MDEyOklzc3VlQ29tbWVudDI0MzM1MDQyOQ==,3404817,2016-08-30T06:59:14Z,2016-08-30T06:59:14Z,CONTRIBUTOR,"I think it makes sense to preserve the `UNLIMITED` state through read/write. In my case, I subset a netCDF file along `lat` and `lon` dimensions, leaving the `time` dimension untouched and would therefore expect it to pass unchanged through `xarray` IO (staying `UNLIMITED`). However, when the dataset is indexed/subset/resampled along the unlimited dimension, it would make sense that its state is dropped. But that would require a lot of ifs and buts, so I suggest we leave that aside for now. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,173773358 https://github.com/pydata/xarray/issues/992#issuecomment-243253510,https://api.github.com/repos/pydata/xarray/issues/992,243253510,MDEyOklzc3VlQ29tbWVudDI0MzI1MzUxMA==,3404817,2016-08-29T20:56:55Z,2016-08-29T20:56:55Z,CONTRIBUTOR,"OK, I'd be up for taking a shot at it. Since it is per-variable and specific to netCDF, I guess the perfect place to add this is in the `encoding` dictionary that you can pass to [`to_netcdf`](https://github.com/pydata/xarray/blob/606e1d9c7efd72e10b530a688d6ef870e8ec1843/xarray/backends/api.py#L316), right? Maybe as key `unlimited`? E.g. ``` ds.to_netcdf(encoding={'time': dict(unlimited=True)}) ``` I need to look up whether netCDF allows for defining more than one unlimited dimension, otherwise that must throw an error. And then it is just about passing `None` as length to `CreateDimension`, at least in `netCDF4` and `scipy.io.netcdf`. But I did not look into how xarray handles that under the hood. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,173773358 https://github.com/pydata/xarray/issues/623#issuecomment-147962600,https://api.github.com/repos/pydata/xarray/issues/623,147962600,MDEyOklzc3VlQ29tbWVudDE0Nzk2MjYwMA==,3404817,2015-10-14T07:33:44Z,2015-10-14T07:33:44Z,CONTRIBUTOR,"Alright, I see. In that case we should not create an entirely new syntax for this - unless there are more people than just me interested in this feature. I can just use my own little convenience function that generates a series of array indices that can be fed to `isel`, something like this: ``` python def wrap_iselkw(ds, dim, istart, istop): """"""Returns a kw dict for indices from `istart` to `istop` that wrap around dimension `dim`"""""" n = len(ds[dim]) if istart > istop: istart -= n return { dim : np.mod(np.arange(istart, istop), n) } ``` ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,110979851 https://github.com/pydata/xarray/issues/623#issuecomment-147727880,https://api.github.com/repos/pydata/xarray/issues/623,147727880,MDEyOklzc3VlQ29tbWVudDE0NzcyNzg4MA==,3404817,2015-10-13T14:17:08Z,2015-10-13T14:17:08Z,CONTRIBUTOR,"@jhamman You guys seem to be always ahead of me - which is great! (I just did not notice it this time before I raised the issue...) But it would actually not be that hard to make selecting regions across the boundary of a circular dimension more convenient in `xray`. It would of course be great if it worked with real coordinate (longitude) values: ``` ds.sel(lon=slice(-90, 15)) ``` which, however, only works if the axis explicitly covers this range (e.g. has range -180E to 180E). If it ranges, say, from 0E to 360E, an empty DataArray is returned. There is no nice way of resolving this, I guess, because you would need to hard-code 360 or have it as a clumsy, non-CF-standard parameter and transform all values to some common range before trying to find the requested region. But it should be less problematic with ``` ds.isel(lon=slice(-100, 200)) ``` i.e. `isel` with negative slice start. As it is now, this also returns an empty DataArray for me (xray 0.6.0), which is in a way consistent with the `sel` behaviour. But asking for negative indices is actually a quite pythonic way of implying circular. So could this be implemented, now that netCDF4 supports non-contiguous indexing? ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,110979851 https://github.com/pydata/xarray/issues/442#issuecomment-115561175,https://api.github.com/repos/pydata/xarray/issues/442,115561175,MDEyOklzc3VlQ29tbWVudDExNTU2MTE3NQ==,3404817,2015-06-26T07:28:54Z,2015-06-26T07:28:54Z,CONTRIBUTOR,"That makes sense. Great that there is an option to `keep_attrs`. Closing this issue. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,90658514 https://github.com/pydata/xarray/issues/442#issuecomment-115177414,https://api.github.com/repos/pydata/xarray/issues/442,115177414,MDEyOklzc3VlQ29tbWVudDExNTE3NzQxNA==,3404817,2015-06-25T09:10:26Z,2015-06-25T09:10:38Z,CONTRIBUTOR,"Sorry for the confusion! The loss of attributes actually occurs when applying `.mean()` (rather than `.load()`). See this [notebook](https://gist.github.com/j08lue/c4a6b4bd504c0a7598b2) (same in [nbviewer](http://nbviewer.ipython.org/gist/j08lue/c4a6b4bd504c0a7598b2)) for an example with some opendap-hosted data. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,90658514 https://github.com/pydata/xarray/issues/438#issuecomment-113422235,https://api.github.com/repos/pydata/xarray/issues/438,113422235,MDEyOklzc3VlQ29tbWVudDExMzQyMjIzNQ==,3404817,2015-06-19T08:03:19Z,2015-06-19T08:03:44Z,CONTRIBUTOR,"[`netCDF4-python`](https://github.com/Unidata/netcdf4-python/) uses a dimension specified by the user or an unlimited dimension it finds in the dataset. Here is the [corresponding code section](https://github.com/Unidata/netcdf4-python/blob/97b756ed70ff77c3042263e900b36565276781c5/netCDF4/_netCDF4.pyx#L4787-L4826). ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,89268800 https://github.com/pydata/xarray/issues/438#issuecomment-113415070,https://api.github.com/repos/pydata/xarray/issues/438,113415070,MDEyOklzc3VlQ29tbWVudDExMzQxNTA3MA==,3404817,2015-06-19T07:44:25Z,2015-06-19T07:45:40Z,CONTRIBUTOR,"Here is a [print-out of the full dataset](https://gist.github.com/j08lue/65b0fe59d047e6ca3ec9) for POP ocean model output (see [that gist in nbviewer](http://nbviewer.ipython.org/gist/j08lue/65b0fe59d047e6ca3ec9)). I can see that the heuristics exclude variables from concatenation that are associated with dimensions of other variables. But why not just exclude all that do not have a time dimension? ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,89268800 https://github.com/pydata/xarray/issues/436#issuecomment-113127892,https://api.github.com/repos/pydata/xarray/issues/436,113127892,MDEyOklzc3VlQ29tbWVudDExMzEyNzg5Mg==,3404817,2015-06-18T11:47:42Z,2015-06-18T11:47:42Z,CONTRIBUTOR,"That is actually an excellent demonstration of the power of `xray` for climate data analysis, @shoyer. Something like this (including the pandas bridge) should be included in the documentation somewhere, for example under [Why xray?](http://xray.readthedocs.org/en/stable/why-xray.html). Just a thought... ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,88897697