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/6996#issuecomment-1237982464,https://api.github.com/repos/pydata/xarray/issues/6996,1237982464,IC_kwDOAMm_X85Jyh0A,10050469,2022-09-06T10:45:36Z,2022-09-06T10:45:36Z,MEMBER,"Sorry false alarm the bug that caused salem tests to fail is indeed solved by https://github.com/pydata/xarray/pull/6857
Sorry for the noise.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1362895131
https://github.com/pydata/xarray/issues/6996#issuecomment-1237920815,https://api.github.com/repos/pydata/xarray/issues/6996,1237920815,IC_kwDOAMm_X85JySwv,10050469,2022-09-06T09:46:49Z,2022-09-06T09:46:49Z,MEMBER,"> Is there an older version where it returned copies?
Yes, tests started to fail on [salem](https://github.com/fmaussion/salem) which I haven't maintained in quite a long time. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1362895131
https://github.com/pydata/xarray/issues/6996#issuecomment-1237918086,https://api.github.com/repos/pydata/xarray/issues/6996,1237918086,IC_kwDOAMm_X85JySGG,10050469,2022-09-06T09:44:20Z,2022-09-06T09:44:20Z,MEMBER,Yes sorry I also tested on `main` and this still occurs. Tagging this as bug.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1362895131
https://github.com/pydata/xarray/pull/6569#issuecomment-1120430372,https://api.github.com/repos/pydata/xarray/issues/6569,1120430372,IC_kwDOAMm_X85CyGkk,10050469,2022-05-08T14:37:07Z,2022-05-08T14:37:07Z,MEMBER,"I've edited a few more sentences, to me this is ready to merge!
I've been struggling with groupby a good deal of my week and I added a warning regarding groupby as well. Feel free to disagree, but I've been unable to get it to work on a large datasets across multiple files yet (see [pangeo discourse post](https://discourse.pangeo.io/t/dask-xarray-and-swap-memory-polution-on-local-linux-cluster/2453)).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1224347682
https://github.com/pydata/xarray/pull/5981#issuecomment-1116275051,https://api.github.com/repos/pydata/xarray/issues/5981,1116275051,IC_kwDOAMm_X85CiQFr,10050469,2022-05-03T16:08:37Z,2022-05-03T16:08:37Z,MEMBER,@Illviljan and other devs - I still think this small change would be a nice addition for accessibility and teaching. Let me know if we can purse or if I should close this.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1051772149
https://github.com/pydata/xarray/pull/5981#issuecomment-974864775,https://api.github.com/repos/pydata/xarray/issues/5981,974864775,IC_kwDOAMm_X846G0GH,10050469,2021-11-21T17:59:22Z,2021-11-21T17:59:22Z,MEMBER,"Side note: with this design (no call to repr() in format()) we would mimick numpy's behavior:
```python
a = np.array([0.1, 0.2])
a.__format__("""")
Out[16]: '[0.1 0.2]'
a.__repr__()
Out[17]: 'array([0.1, 0.2])'
```
However I'm quite surprised as to why ``.__format__("""")`` works on non-scalar arrays but not with other specifiers - this is discussed somehow in https://github.com/numpy/numpy/issues/5543 . I think it's okay for xarray to defer to whatever numpy is doing here, but of course we can also keep the status-quo, it's quite a small change after all. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1051772149
https://github.com/pydata/xarray/pull/5981#issuecomment-966987656,https://api.github.com/repos/pydata/xarray/issues/5981,966987656,IC_kwDOAMm_X845ow-I,10050469,2021-11-12T10:21:34Z,2021-11-12T11:04:58Z,MEMBER,"Note that there would be a way to change the behavior to:
```python
print(da) -> lengthy repr
print('{}'.format(da) -> fall back to numpy.__format__
```
This would break backwards compatibility, but I think it would be my preference - there are some chances that it brakes some code (in documentation pages maybe?), but I don't think that many people rely on `'{}'.format(da)` to return `__repr__` ...","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1051772149
https://github.com/pydata/xarray/issues/5976#issuecomment-966634872,https://api.github.com/repos/pydata/xarray/issues/5976,966634872,IC_kwDOAMm_X845na14,10050469,2021-11-11T21:22:39Z,2021-11-11T21:22:57Z,MEMBER,"> @fmaussion how would you envision this working for non-scalar arrays? Would it just raise?
Yes, similar to numpy:
```python
da = xr.DataArray([1, 2, 3]).data
print(f'{da}')
print(f'{da:d}')
[1 2 3]
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
in
1 da = xr.DataArray([1, 2, 3]).data
2 print(f'{da}')
----> 3 print(f'{da:d}')
TypeError: unsupported format string passed to numpy.ndarray.__format__
```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1051241489
https://github.com/pydata/xarray/issues/5146#issuecomment-966524050,https://api.github.com/repos/pydata/xarray/issues/5146,966524050,IC_kwDOAMm_X845m_yS,10050469,2021-11-11T18:21:31Z,2021-11-11T18:21:31Z,MEMBER,The OP bug is now fixed on latest xarray. See #5148 for a related issue with dimension names. ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,856728083
https://github.com/pydata/xarray/issues/5162#issuecomment-820278259,https://api.github.com/repos/pydata/xarray/issues/5162,820278259,MDEyOklzc3VlQ29tbWVudDgyMDI3ODI1OQ==,10050469,2021-04-15T09:29:55Z,2021-04-15T09:29:55Z,MEMBER,"http://xarray.pydata.org/en/stable/generated/xarray.DataArray.rolling.html
What did you try? What did not work out?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,858671865
https://github.com/pydata/xarray/issues/5073#issuecomment-806944421,https://api.github.com/repos/pydata/xarray/issues/5073,806944421,MDEyOklzc3VlQ29tbWVudDgwNjk0NDQyMQ==,10050469,2021-03-25T15:24:32Z,2021-03-25T15:24:32Z,MEMBER,"> I think it's a DeprecationWarning since we're removing it rather than changing its behavior
Ha! I'm no expert either. I learned one thing recently though: `DeprecationWarnings` are silenced by python per default when not raised directly from `__main__` and are therefore invisible for many users.
https://stackoverflow.com/questions/66590950/deprecationwarning-is-not-raised-on-import
https://stackoverflow.com/questions/55377831/difference-between-deprecationwarning-pendingdeprecationwarning-and-futurewarni ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,840258082
https://github.com/pydata/xarray/issues/4364#issuecomment-802665473,https://api.github.com/repos/pydata/xarray/issues/4364,802665473,MDEyOklzc3VlQ29tbWVudDgwMjY2NTQ3Mw==,10050469,2021-03-19T08:57:11Z,2021-03-19T08:57:11Z,MEMBER,"Another consequence is that [this example in the docs](https://xarray.pydata.org/en/stable/plotting.html#multidimensional-coordinates) is now meaningless / misleading. I've just come across the series of discussions in cartopy about this issue - it looks quite complex and I'm also not sure yet what to do in xarray in the mean time.
> Wouldn't allowing infer_interval=False and passing ordinary arrays as x and y be a good solution?
I'm not sure what you mean by that? You can always set `infer_interval=False` at the xarray level? ","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,683777199
https://github.com/pydata/xarray/issues/3961#issuecomment-749504491,https://api.github.com/repos/pydata/xarray/issues/3961,749504491,MDEyOklzc3VlQ29tbWVudDc0OTUwNDQ5MQ==,10050469,2020-12-22T11:56:07Z,2020-12-22T11:56:07Z,MEMBER,"Just adding my +1 here, and also mention that (if memory allows), `ds.load()` also helps. (related: https://github.com/pydata/xarray/issues/4710)","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,597657663
https://github.com/pydata/xarray/issues/4710#issuecomment-749503934,https://api.github.com/repos/pydata/xarray/issues/4710,749503934,MDEyOklzc3VlQ29tbWVudDc0OTUwMzkzNA==,10050469,2020-12-22T11:54:37Z,2020-12-22T11:54:37Z,MEMBER,"Thanks for the tip @markelg.
yes, it seems indeed very much related. Closing this in favor of #3961","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,771127744
https://github.com/pydata/xarray/issues/4414#issuecomment-690268138,https://api.github.com/repos/pydata/xarray/issues/4414,690268138,MDEyOklzc3VlQ29tbWVudDY5MDI2ODEzOA==,10050469,2020-09-10T12:58:22Z,2020-09-10T12:58:22Z,MEMBER,"Thanks a lot for this suggestion! I'll let the others chime in as well, but there are a few things to consider here:
- xarray's plotting capability is not meant to be ""publication ready"" but ""as close as possible to the data"". I.e. units like `degrees_north`, etc. have to stay like this because it unambiguously shows where the data came from and how users can access it from the file, etc.
- in general, making the plots nicer with opinionated defaults like yours would be a nice addition to the xarray ecosystem. It could live in a separate package, and use the [accessor](http://xarray.pydata.org/en/stable/internals.html#extending-xarray) syntax to extend xarray. For example, my own little extension works this way and does opinionated stuff with the accessor: https://salem.readthedocs.io
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,697814535
https://github.com/pydata/xarray/issues/4166#issuecomment-647184580,https://api.github.com/repos/pydata/xarray/issues/4166,647184580,MDEyOklzc3VlQ29tbWVudDY0NzE4NDU4MA==,10050469,2020-06-21T21:33:20Z,2020-06-21T21:33:20Z,MEMBER,"L67: try to replace
`ds_all = xr.merge([xr.open_dataset(f) for f in flist])`
by
`ds_all = xr.open_mfdataset(flist)`
You'll need to install [dask](https://docs.dask.org) for this to work. Note that if you have A LOT of files this might still take some time.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,642452713
https://github.com/pydata/xarray/issues/4142#issuecomment-642554262,https://api.github.com/repos/pydata/xarray/issues/4142,642554262,MDEyOklzc3VlQ29tbWVudDY0MjU1NDI2Mg==,10050469,2020-06-11T10:20:02Z,2020-06-11T10:20:02Z,MEMBER,"As a not-so-active-but-still-interested xarray dev my opinion doesn't count much, but I would be a proponent of having the rasterio backend live outside of xarray proper.
At the time we wrote the rasterio->DataArray conversion we already noticed a lot of issues regarding differences between the two datamodels, and rio-xarray shows that there is a lot of logic and dev work necessary for this to go smoothly, which would be better handled outside of xarray.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,636493109
https://github.com/pydata/xarray/pull/3854#issuecomment-597643353,https://api.github.com/repos/pydata/xarray/issues/3854,597643353,MDEyOklzc3VlQ29tbWVudDU5NzY0MzM1Mw==,10050469,2020-03-11T13:44:08Z,2020-03-11T13:44:08Z,MEMBER,If you want to test builds on RTD before merging you can use the fix-docs branch for that and check its status here: https://readthedocs.org/projects/xray/builds/ ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,578448001
https://github.com/pydata/xarray/issues/3697#issuecomment-590925187,https://api.github.com/repos/pydata/xarray/issues/3697,590925187,MDEyOklzc3VlQ29tbWVudDU5MDkyNTE4Nw==,10050469,2020-02-25T15:30:39Z,2020-02-25T15:30:39Z,MEMBER,"> Is there a downside to this?
Wouldn't we loose the possibility explore older version of the docs? Or is doctr also providing this service?
It seems so silly to have to reivent readthedocs just because of their CI...","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,550335922
https://github.com/pydata/xarray/issues/2723#issuecomment-582972581,https://api.github.com/repos/pydata/xarray/issues/2723,582972581,MDEyOklzc3VlQ29tbWVudDU4Mjk3MjU4MQ==,10050469,2020-02-06T15:56:33Z,2020-02-06T15:56:33Z,MEMBER,I think we should seriously consider removing all rasterio logic in xarray and make rioxarray an optional dependency to read geotiff files with xarray.,"{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,404088563
https://github.com/pydata/xarray/pull/2751#issuecomment-558605566,https://api.github.com/repos/pydata/xarray/issues/2751,558605566,MDEyOklzc3VlQ29tbWVudDU1ODYwNTU2Ng==,10050469,2019-11-26T12:23:44Z,2019-11-26T12:23:44Z,MEMBER,"I've noted that the very recent ERA5 data is also cast to float32 at decoding, although the scale and offset params are float64. I think it would be a very valuable addition to xarray to do this properly: @daoudjahdou are you still willing to work on this PR? Otherwise I'll try to pick this up when time permits.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,407746874
https://github.com/pydata/xarray/issues/3399#issuecomment-542223429,https://api.github.com/repos/pydata/xarray/issues/3399,542223429,MDEyOklzc3VlQ29tbWVudDU0MjIyMzQyOQ==,10050469,2019-10-15T13:53:27Z,2019-10-15T13:53:27Z,MEMBER,"Hi, the docs is here: http://xarray.pydata.org/en/stable/indexing.html#more-advanced-indexing
So your example would read:
```python
import numpy as np
import xarray as xr
da = xr.DataArray(np.arange(16).reshape((4,4)), coords=[('lat', [40,45,50,55]), ('lon', [5,10,15,20])])
points = da.sel(lat=xr.DataArray([40.1, 42.3, 39.78], dims='z'),
lon=xr.DataArray([7.1, 6.2, 13.2], dims='z'),
method='nearest')
```
Arguably, the ""more advanced indexing"" title could be renamed to something more explicit.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,507211596
https://github.com/pydata/xarray/issues/3257#issuecomment-526550941,https://api.github.com/repos/pydata/xarray/issues/3257,526550941,MDEyOklzc3VlQ29tbWVudDUyNjU1MDk0MQ==,10050469,2019-08-30T10:27:22Z,2019-08-30T12:38:00Z,MEMBER,"> Can't we have a nightly build of docker images with all the xarray depencencies?
This would help on Travis yes, but not on RTD which doesn't support docker. But otherwise yes, I've also found that CI is faster and more reliable with docker. In terms of resources ""in general"", I wonder if it wouldn't be nice to share a common testing image base with other packages of the pydata ecosytem. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484711431
https://github.com/pydata/xarray/issues/3257#issuecomment-526545364,https://api.github.com/repos/pydata/xarray/issues/3257,526545364,MDEyOklzc3VlQ29tbWVudDUyNjU0NTM2NA==,10050469,2019-08-30T10:07:59Z,2019-08-30T10:07:59Z,MEMBER,"RTD is struggling with resources, and I can understand that. What is really annoying (and the problem is often the same on travis) is that the conda install is taking a huge part of the build process resources. See e.g. https://github.com/readthedocs/readthedocs.org/issues/6025 , where I ended up using pip for very satisfying results (!).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484711431
https://github.com/pydata/xarray/issues/3227#issuecomment-525329069,https://api.github.com/repos/pydata/xarray/issues/3227,525329069,MDEyOklzc3VlQ29tbWVudDUyNTMyOTA2OQ==,10050469,2019-08-27T14:32:33Z,2019-08-27T14:32:33Z,MEMBER,"If I understand well, this is really just about the temporary files, right? In this case, a cleaning block with a `:suppress:` directive should be enough, yes.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,482023929
https://github.com/pydata/xarray/issues/3268#issuecomment-525268978,https://api.github.com/repos/pydata/xarray/issues/3268,525268978,MDEyOklzc3VlQ29tbWVudDUyNTI2ODk3OA==,10050469,2019-08-27T12:00:02Z,2019-08-27T12:00:02Z,MEMBER,"> could you change your accessor code to store its state in Dataset.attrs instead?
Yes, although `attrs` would be bad as well because they are lost in many operations. The current ""best practice"" would be to use `coords` for this, as in https://github.com/pydata/xarray/issues/1271#issuecomment-280574680
I [never bothered](https://github.com/fmaussion/salem/issues/62) to get this done (my library is quite niche and not mean to become widely used), but if we remove the caching mechanism in xarray, it would be one more incentive to make the switch.
> So you work on the assumption that no new potentially useful coords will be added after the first invocation of your accessor?
Yes. In almost all use cases I know of this won't happen. Typically, the users have to create (or open) an xarray object that salem understands before calling the accessor anyway.
> Or do you have logic that invalidates your cache every time the state of the coords changes?
No. I didn't think about that before today ;-). But you are right: if users of salem's accessor change the coordinates *after* calling the accessor, then bad things might happen. Experience shows that this rarely happens (never happened to me), but I can see how this can fire back.
Altogether, these are good arguments to remove the caching mechanism I believe.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,485708282
https://github.com/pydata/xarray/issues/3268#issuecomment-525252528,https://api.github.com/repos/pydata/xarray/issues/3268,525252528,MDEyOklzc3VlQ29tbWVudDUyNTI1MjUyOA==,10050469,2019-08-27T11:03:47Z,2019-08-27T11:04:10Z,MEMBER,"Interesting, thanks!
As an accessor maintainer, I can ensure that at least one accessor implementation is storing state ;-). But this state is based on the xarray object itself: for example, we derive georeferencing information and store the names of the coordinate variabless we know are going to be useful to us later. That is, every new call to `__init__` based on a modified object will trigger a new parsing, and we don't come into the situation you describe above.
Getting rid of the caching logic would mean some performance loss to us, yes, but I don't know if it's ""worse"" than the circular reference issue you describe or not.
","{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 1, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,485708282
https://github.com/pydata/xarray/pull/3162#issuecomment-515449766,https://api.github.com/repos/pydata/xarray/issues/3162,515449766,MDEyOklzc3VlQ29tbWVudDUxNTQ0OTc2Ng==,10050469,2019-07-26T13:23:48Z,2019-07-26T13:23:48Z,MEMBER,"Yes, network test are not run on travis: https://github.com/pydata/xarray/blob/1a5b6305be4261f04b130a84f7780c9b5dafc943/conftest.py","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,473142248
https://github.com/pydata/xarray/pull/2255#issuecomment-514707122,https://api.github.com/repos/pydata/xarray/issues/2255,514707122,MDEyOklzc3VlQ29tbWVudDUxNDcwNzEyMg==,10050469,2019-07-24T16:36:06Z,2019-07-24T16:36:06Z,MEMBER,">> I'm curious, are there features in rioxarray that could be pushed upstream?
> Depends on what the xarray maintainers would like to add. I would definitely like to see the open_rasterio function in rioxarray absorbed back into xarray. Things have just been really slow moving with the other PRs/issues.
Put another way: why don't we put all the logic in rioxarray and make rioxarray an optional dependency of xarray to open rio files?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,336371511
https://github.com/pydata/xarray/pull/3013#issuecomment-501884771,https://api.github.com/repos/pydata/xarray/issues/3013,501884771,MDEyOklzc3VlQ29tbWVudDUwMTg4NDc3MQ==,10050469,2019-06-13T21:25:32Z,2019-06-13T21:25:32Z,MEMBER,"Thanks @ecarrara !
> but the TestRasterio::test_serialization fails
This is not the case anymore, right? This test is here to ensure that the dataarrays we are creating with `open_rasterio` are compatible with the NetCDF model. I think it is good to try to keep it that way.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,454337592
https://github.com/pydata/xarray/issues/2995#issuecomment-497063685,https://api.github.com/repos/pydata/xarray/issues/2995,497063685,MDEyOklzc3VlQ29tbWVudDQ5NzA2MzY4NQ==,10050469,2019-05-29T18:49:37Z,2019-05-29T18:49:37Z,MEMBER,"> This takes about a minute to open for me.
It took me much longer earlier this week when I tried :roll_eyes: Is the bottleneck in the parsing of the coordinates?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,449706080
https://github.com/pydata/xarray/issues/2962#issuecomment-492625308,https://api.github.com/repos/pydata/xarray/issues/2962,492625308,MDEyOklzc3VlQ29tbWVudDQ5MjYyNTMwOA==,10050469,2019-05-15T12:01:42Z,2019-05-15T12:01:42Z,MEMBER,Thanks! If you want you can also accept the stackoverflow answer for later reference,"{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,444367776
https://github.com/pydata/xarray/issues/2962#issuecomment-492623485,https://api.github.com/repos/pydata/xarray/issues/2962,492623485,MDEyOklzc3VlQ29tbWVudDQ5MjYyMzQ4NQ==,10050469,2019-05-15T11:55:17Z,2019-05-15T11:55:17Z,MEMBER,"> But I can't figure out what was the code doing without create this new one ""common dimension""
It is doing what is called ""orthogonal indexing"", but with interpolation. The resulting shape of the output is then (2, 2, 2) in your case, but could be any (t, y, x) as given by the size of each dimension indexer.
Maybe this helps a little: http://xarray.pydata.org/en/stable/indexing.html#vectorized-indexing","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,444367776
https://github.com/pydata/xarray/issues/2962#issuecomment-492612763,https://api.github.com/repos/pydata/xarray/issues/2962,492612763,MDEyOklzc3VlQ29tbWVudDQ5MjYxMjc2Mw==,10050469,2019-05-15T11:17:05Z,2019-05-15T11:17:05Z,MEMBER,"Yes, it is possible. It is a bit ""less intuitive"" at first sight, but powerful and documented here: http://xarray.pydata.org/en/stable/interpolation.html#advanced-interpolation
The call you need to make is:
```python
blah.interp(longitude=('z', lon), latitude=('z', lat))
```","{""total_count"": 2, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 1, ""eyes"": 0}",,444367776
https://github.com/pydata/xarray/pull/2919#issuecomment-488999383,https://api.github.com/repos/pydata/xarray/issues/2919,488999383,MDEyOklzc3VlQ29tbWVudDQ4ODk5OTM4Mw==,10050469,2019-05-03T08:11:58Z,2019-05-03T08:11:58Z,MEMBER,"> How about adding a comment saying that this may/may not work and suggest a workaround
Thanks for the suggestion! I've decided against it because it will be too wordy - let's see if this is really affecting that many people first.
Thanks @grinsted for the PR!","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,437126178
https://github.com/pydata/xarray/pull/2919#issuecomment-487489532,https://api.github.com/repos/pydata/xarray/issues/2919,487489532,MDEyOklzc3VlQ29tbWVudDQ4NzQ4OTUzMg==,10050469,2019-04-29T08:22:47Z,2019-04-29T08:22:47Z,MEMBER,"> I wonder why it desn't work with pip.
Because of that: https://github.com/mapbox/rasterio#ssl-certs . It will work, but not out-of-the box. I personally don't mind, but we might get a few ""your example doesn't work"" requests here although it has nothing to do with xarray, this is why I'm asking others devs before merging.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,437126178
https://github.com/pydata/xarray/pull/2919#issuecomment-487476404,https://api.github.com/repos/pydata/xarray/issues/2919,487476404,MDEyOklzc3VlQ29tbWVudDQ4NzQ3NjQwNA==,10050469,2019-04-29T07:28:36Z,2019-04-29T07:28:36Z,MEMBER,"Thanks! Yes, I've tested on a conda env and it works. So my take is that it probably won't work out-of-the box on debian/ubuntu/mint where rasterio is installed via pip.
So my question to @shoyer or @jhamman : should we change this example for the nicer code above, even if a minority of people (pip users like me) might find that this doesn't work for them?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,437126178
https://github.com/pydata/xarray/pull/2919#issuecomment-487007098,https://api.github.com/repos/pydata/xarray/issues/2919,487007098,MDEyOklzc3VlQ29tbWVudDQ4NzAwNzA5OA==,10050469,2019-04-26T10:16:40Z,2019-04-26T10:16:40Z,MEMBER,"@grinsted what OS are you running this on? I'm a bit concerned about this here: https://github.com/mapbox/rasterio#ssl-certs
I came into this while trying it locally, and even after setting the env variable I still get this error:
```
RasterioIOError: '/vsicurl/https://github.com/mapbox/rasterio/raw/master/tests/data/RGB.byte.tif' does not exist in the file system, and is not recognized as a supported dataset name.
```
I wonder if I'm the only one in that case, or if other users might be affected as well","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,437126178
https://github.com/pydata/xarray/pull/2618#issuecomment-487003189,https://api.github.com/repos/pydata/xarray/issues/2618,487003189,MDEyOklzc3VlQ29tbWVudDQ4NzAwMzE4OQ==,10050469,2019-04-26T10:02:26Z,2019-04-26T10:02:26Z,MEMBER,"I'm sorry this has stalled now - I think this is a nice addition.
@jsignell : would you have time to finish this up? ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,392361367
https://github.com/pydata/xarray/issues/2909#issuecomment-486999992,https://api.github.com/repos/pydata/xarray/issues/2909,486999992,MDEyOklzc3VlQ29tbWVudDQ4Njk5OTk5Mg==,10050469,2019-04-26T09:51:38Z,2019-04-26T09:51:38Z,MEMBER,"> too many references to pandas!
This is a tricky one. In the beginning we wanted people to come from pandas to xarray. It was kind of assumed that everybody uses and loves pandas, therefore will also use and love xarray. (my own experience).
But do we have to build the docs for non-pandas users as well? It could make quite a few things redundant with the pandas documentation...","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,435330735
https://github.com/pydata/xarray/pull/2919#issuecomment-486619296,https://api.github.com/repos/pydata/xarray/issues/2919,486619296,MDEyOklzc3VlQ29tbWVudDQ4NjYxOTI5Ng==,10050469,2019-04-25T10:34:58Z,2019-04-25T10:34:58Z,MEMBER,Thanks! Can you do the same for the other example as well?,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,437126178
https://github.com/pydata/xarray/issues/2918#issuecomment-486589435,https://api.github.com/repos/pydata/xarray/issues/2918,486589435,MDEyOklzc3VlQ29tbWVudDQ4NjU4OTQzNQ==,10050469,2019-04-25T09:22:03Z,2019-04-25T09:22:03Z,MEMBER,"> (or any other indexing operation)
Correction: only the windowed operations can be done lazily, the other ones will fail unless you load the data first.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,437058245
https://github.com/pydata/xarray/issues/2918#issuecomment-486574195,https://api.github.com/repos/pydata/xarray/issues/2918,486574195,MDEyOklzc3VlQ29tbWVudDQ4NjU3NDE5NQ==,10050469,2019-04-25T08:38:11Z,2019-04-25T08:38:28Z,MEMBER,"Xarray already supports this, the syntax is that of xarray though. It reads the files lazily, then access only what you select, e.g.:
```python
import os
import urllib.request
import matplotlib.pyplot as plt
import xarray as xr
# Download the file from rasterio's repository
url = 'https://github.com/mapbox/rasterio/raw/master/tests/data/RGB.byte.tif'
urllib.request.urlretrieve(url, 'RGB.byte.tif')
# Read the data
da = xr.open_rasterio('RGB.byte.tif')
da[:, 400:600, 400:600].plot.imshow();
```
(or [any other indexing](http://xarray.pydata.org/en/stable/indexing.html) operation)
","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,437058245
https://github.com/pydata/xarray/pull/2850#issuecomment-479547573,https://api.github.com/repos/pydata/xarray/issues/2850,479547573,MDEyOklzc3VlQ29tbWVudDQ3OTU0NzU3Mw==,10050469,2019-04-03T15:48:22Z,2019-04-03T15:48:22Z,MEMBER,"Thanks! @shoyer ! I guess the file I was working with must have been created with nectdf3 then, because otherwise I don't know how they managed to write this out...","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,424916834
https://github.com/pydata/xarray/pull/2850#issuecomment-479528667,https://api.github.com/repos/pydata/xarray/issues/2850,479528667,MDEyOklzc3VlQ29tbWVudDQ3OTUyODY2Nw==,10050469,2019-04-03T15:03:19Z,2019-04-03T15:03:19Z,MEMBER,"> It's very python related
I'm saying this because this happened with a real file I was working with. The file had a `CLASS` attribute on a variable, it can be read by xarray but not written out... ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,424916834
https://github.com/pydata/xarray/pull/2850#issuecomment-479527736,https://api.github.com/repos/pydata/xarray/issues/2850,479527736,MDEyOklzc3VlQ29tbWVudDQ3OTUyNzczNg==,10050469,2019-04-03T15:01:12Z,2019-04-03T15:01:12Z,MEMBER,"> One more request: can you link to a list of disallowed names in the docs somewhere?
I don't know if such a list exists. Do you know? It's very python related, because of `setattr`. It's confusing that it's only making a problem on variable objects, not on datasets.
So altogether I wouldn't worry much here, this is really an edge case.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,424916834
https://github.com/pydata/xarray/issues/2854#issuecomment-479389904,https://api.github.com/repos/pydata/xarray/issues/2854,479389904,MDEyOklzc3VlQ29tbWVudDQ3OTM4OTkwNA==,10050469,2019-04-03T08:23:51Z,2019-04-03T08:23:51Z,MEMBER,"This is puzzling. I've edited the example a bit for clarity, but I have no clue what's going on:
```python
import numpy as np
import xarray as xr
da = xr.DataArray(np.random.random((3, 4)),
dims=[""assets"", ""year""],
coords={""year"": range(2010, 2018, 2)},
name='var'
)
# Interpolate directly the DataArray
new_da = da.interp(year=[2011, 2015])
# Interpolate via dataset
new_ds = xr.Dataset({""var"": da.copy()}).interp(year=[2011, 2015])['var']
# Equivalent DAs
xr.testing.assert_identical(new_da, new_ds)
# Indexing works
xr.testing.assert_identical(new_da.loc[{""year"": 2015}], new_ds.loc[{""year"": 2015}])
# Assignment doesn't
new_da.loc[{""year"": 2015}] = 42
new_ds.loc[{""year"": 2015}] = 42 # Fails
---------------------------------------------------------------------------
IndexError Traceback (most recent call last)
in ()
21 # Assignment doesn't
22 new_da.loc[{""year"": 2015}] = 42
---> 23 new_ds.loc[{""year"": 2015}] = 42 # Fails
....
~/Documents/git/xarray/xarray/core/indexing.py in __getitem__(self, key)
1168 def __getitem__(self, key):
1169 array, key = self._indexing_array_and_key(key)
-> 1170 return array[key]
1171
1172 def __setitem__(self, key, value):
IndexError: index 2015 is out of bounds for axis 0 with size 2
```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,425905002
https://github.com/pydata/xarray/pull/2850#issuecomment-479382381,https://api.github.com/repos/pydata/xarray/issues/2850,479382381,MDEyOklzc3VlQ29tbWVudDQ3OTM4MjM4MQ==,10050469,2019-04-03T08:00:40Z,2019-04-03T08:00:40Z,MEMBER,"Done! Didn't edit ""what's new"" because this is a tiny change.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,424916834
https://github.com/pydata/xarray/pull/2865#issuecomment-479381445,https://api.github.com/repos/pydata/xarray/issues/2865,479381445,MDEyOklzc3VlQ29tbWVudDQ3OTM4MTQ0NQ==,10050469,2019-04-03T07:57:48Z,2019-04-03T07:57:48Z,MEMBER,"> Should I add tests for this ?
If there is a way, it would be great yes. You can build upon (or adapt) this example here:
https://github.com/pydata/xarray/blob/225868d232219440b188956531d5764ff4cd1b53/xarray/tests/test_backends.py#L3327-L3351
cc @scottyhq who wrote this code, as I don't think any of the xarray team uses this format.
Please also add a line to [whats-new.rst](https://github.com/pydata/xarray/blob/master/doc/whats-new.rst)
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,428374352
https://github.com/pydata/xarray/issues/2864#issuecomment-479063221,https://api.github.com/repos/pydata/xarray/issues/2864,479063221,MDEyOklzc3VlQ29tbWVudDQ3OTA2MzIyMQ==,10050469,2019-04-02T15:51:52Z,2019-04-02T15:51:52Z,MEMBER,"Thanks for the great report!
> I can provide this patch in a pull request if needed.
Please, do ;-)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,428300345
https://github.com/pydata/xarray/issues/2861#issuecomment-478570138,https://api.github.com/repos/pydata/xarray/issues/2861,478570138,MDEyOklzc3VlQ29tbWVudDQ3ODU3MDEzOA==,10050469,2019-04-01T13:03:34Z,2019-04-01T13:03:34Z,MEMBER,"Thanks, I could download them. Can you tell us what the problem with these files is, that we might have to solve in xarray?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,427644858
https://github.com/pydata/xarray/issues/2861#issuecomment-478546784,https://api.github.com/repos/pydata/xarray/issues/2861,478546784,MDEyOklzc3VlQ29tbWVudDQ3ODU0Njc4NA==,10050469,2019-04-01T11:47:27Z,2019-04-01T11:47:27Z,MEMBER,"> Up to now I never thought about that the 'notnull' method is acting on more than only the data itself
All xarray operations will return xarray objects. And xarray will try to match coordinates wherever possible.
> However, the coordinates are already mathematically identical
In your example above, they are not. Can you help us to reproduce the error with a [Minimal Complete Verifiable Example](http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports)?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,427644858
https://github.com/pydata/xarray/issues/2861#issuecomment-478538543,https://api.github.com/repos/pydata/xarray/issues/2861,478538543,MDEyOklzc3VlQ29tbWVudDQ3ODUzODU0Mw==,10050469,2019-04-01T11:17:46Z,2019-04-01T11:19:28Z,MEMBER,"xarray is ""coordinate aware"", i.e. it will try hard to prevent users doing bad things with non matching coordinates (yes, the fact that your `ref` and `proof` are ""not entirely consistent somehow regarding coordinates"" looks like you are doing bad things ;-).
If I understand what you want, this should do the trick:
```python
proof[""WSS""].where(ref[""WSS""].notnull().data) # use .data here to get back to numpy
```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,427644858
https://github.com/pydata/xarray/pull/2860#issuecomment-478538825,https://api.github.com/repos/pydata/xarray/issues/2860,478538825,MDEyOklzc3VlQ29tbWVudDQ3ODUzODgyNQ==,10050469,2019-04-01T11:18:40Z,2019-04-01T11:18:40Z,MEMBER,Thanks!,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,427604384
https://github.com/pydata/xarray/pull/1820#issuecomment-478082082,https://api.github.com/repos/pydata/xarray/issues/1820,478082082,MDEyOklzc3VlQ29tbWVudDQ3ODA4MjA4Mg==,10050469,2019-03-29T17:24:17Z,2019-03-29T17:24:17Z,MEMBER,@benbovy is the checklist still up-to-date? The length of it is a bit scary TBH ;-),"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,287844110
https://github.com/pydata/xarray/pull/1820#issuecomment-478026711,https://api.github.com/repos/pydata/xarray/issues/1820,478026711,MDEyOklzc3VlQ29tbWVudDQ3ODAyNjcxMQ==,10050469,2019-03-29T14:52:19Z,2019-03-29T14:52:19Z,MEMBER,"> I would be extremely pleased if anyone is willing to jump in and help on the front-end part (HTML/CSS)! See the checklist at the top of this PR. Unfortunately, my limited expertise in this area makes me rather unproductive.
yeah, I guess this is the major issue here. Who could we get in to help out? Does @pydata/xarray know anyone from the extended community with an interest in these things?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,287844110
https://github.com/pydata/xarray/issues/2847#issuecomment-476252880,https://api.github.com/repos/pydata/xarray/issues/2847,476252880,MDEyOklzc3VlQ29tbWVudDQ3NjI1Mjg4MA==,10050469,2019-03-25T15:39:09Z,2019-03-25T15:39:09Z,MEMBER,"> A hint in the documentation may hinder others to fall into this pit.
Agreed. Would you like to submit a pull-request?
> Also it would be nice to have intervals serialized into netCDF since they are quite common structures.
There are ways to deal with intervals in the CF conventions, but what we really need is a way for xarray to truly *understand* intervals, which is a much bigger endeavor. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,424538928
https://github.com/pydata/xarray/issues/2848#issuecomment-476196344,https://api.github.com/repos/pydata/xarray/issues/2848,476196344,MDEyOklzc3VlQ29tbWVudDQ3NjE5NjM0NA==,10050469,2019-03-25T13:28:19Z,2019-03-25T13:28:19Z,MEMBER,"> it would save time and frustration if instead of failing, open_dataset would simply issue a warning for any variable it could not decode, and proceed to decode those that it can
I tend to agree, but changing this now would break all code which relies on `try ... except` logic to check if files can be decoded or not. I'm not sure it's worth changing it at this stage...","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,424545013
https://github.com/pydata/xarray/pull/2642#issuecomment-472368810,https://api.github.com/repos/pydata/xarray/issues/2642,472368810,MDEyOklzc3VlQ29tbWVudDQ3MjM2ODgxMA==,10050469,2019-03-13T10:37:34Z,2019-03-13T10:37:34Z,MEMBER,"@shoyer pep8speaks now support `#noqa` : https://github.com/OrkoHunter/pep8speaks/issues/96#issuecomment-472310933
I wonder if it's still relevant for us since your change though.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,395332265
https://github.com/pydata/xarray/issues/2723#issuecomment-460396203,https://api.github.com/repos/pydata/xarray/issues/2723,460396203,MDEyOklzc3VlQ29tbWVudDQ2MDM5NjIwMw==,10050469,2019-02-04T20:15:36Z,2019-02-04T20:15:36Z,MEMBER,"Sorry for being late on this one. Yes, I agree that the ""coordinate attribute"" is worth a try.
To avoid redundancy in the name one could name the coord variable attributes simply `wkt` and `proj4`, like:
```
array(0)
Coordinates:
crs int64 0
Attributes:
wkt: PROJCS[""UTM Zone 15, Northern Hemisphere"",GEOGCS[""WGS 84"",D...
proj4: +proj=...
```","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,404088563
https://github.com/pydata/xarray/pull/2715#issuecomment-459036333,https://api.github.com/repos/pydata/xarray/issues/2715,459036333,MDEyOklzc3VlQ29tbWVudDQ1OTAzNjMzMw==,10050469,2019-01-30T17:35:40Z,2019-01-30T17:35:40Z,MEMBER,I'm going to merge this tomorrow unless there are further concerns,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,403458737
https://github.com/pydata/xarray/pull/2593#issuecomment-458608075,https://api.github.com/repos/pydata/xarray/issues/2593,458608075,MDEyOklzc3VlQ29tbWVudDQ1ODYwODA3NQ==,10050469,2019-01-29T16:30:03Z,2019-01-29T16:30:03Z,MEMBER,"> I can't diagnose what's wrong from the error message (something to do with conda it seems)
Some connection error. I restarted Travis, let's see if this happens again.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,387924616
https://github.com/pydata/xarray/issues/792#issuecomment-458314129,https://api.github.com/repos/pydata/xarray/issues/792,458314129,MDEyOklzc3VlQ29tbWVudDQ1ODMxNDEyOQ==,10050469,2019-01-28T21:46:18Z,2019-01-28T21:46:18Z,MEMBER,"especially because there is not robust logic as to how to check for coordinates being evenly spaced. I remember this topic has been discussed somewhere already, but I don't remember where.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,140264913
https://github.com/pydata/xarray/issues/2722#issuecomment-458313603,https://api.github.com/repos/pydata/xarray/issues/2722,458313603,MDEyOklzc3VlQ29tbWVudDQ1ODMxMzYwMw==,10050469,2019-01-28T21:44:36Z,2019-01-28T21:44:36Z,MEMBER,"Thanks @snowman2 ! I don't think there is much discussion necessary about whether we should use WKT or not, the question is rather how? WKT strings are quite complex and verbose, but this should not be a big issue.
We used proj4 strings in xarray because it's what rasterio's `to_string` would give us back, and we need a canonical string representation for serialization to netCDF. I don't know how many users rely on the rasterio backend's `crs` attribute to be a proj4 string, but I guess that it's at least a few.
So, what should we do? My preferred solution right now would be to deprecate the `crs` attribute and replace it with two explicit `proj4_crs` and `wkt_crs` attributes to cover all use cases.
Thoughts?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,403971686
https://github.com/pydata/xarray/issues/792#issuecomment-458311494,https://api.github.com/repos/pydata/xarray/issues/792,458311494,MDEyOklzc3VlQ29tbWVudDQ1ODMxMTQ5NA==,10050469,2019-01-28T21:37:53Z,2019-01-28T21:37:53Z,MEMBER,"yes, also the current solution isn't too bad as well.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,140264913
https://github.com/pydata/xarray/pull/2715#issuecomment-458257810,https://api.github.com/repos/pydata/xarray/issues/2715,458257810,MDEyOklzc3VlQ29tbWVudDQ1ODI1NzgxMA==,10050469,2019-01-28T19:00:17Z,2019-01-28T19:00:17Z,MEMBER,can your merge from master? The failing tests should be solved by https://github.com/pydata/xarray/pull/2720,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,403458737
https://github.com/pydata/xarray/pull/2659#issuecomment-453471377,https://api.github.com/repos/pydata/xarray/issues/2659,453471377,MDEyOklzc3VlQ29tbWVudDQ1MzQ3MTM3Nw==,10050469,2019-01-11T10:29:22Z,2019-01-14T22:12:04Z,MEMBER,">> Maybe we could change it so that attrs is only included if it is non-empty.
> How do people feel about this? If folks are fine with it as is, then LGTM.
I'd rather have an empty dict as in the current implementation (like xarray)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,396501063
https://github.com/pydata/xarray/pull/2659#issuecomment-452048428,https://api.github.com/repos/pydata/xarray/issues/2659,452048428,MDEyOklzc3VlQ29tbWVudDQ1MjA0ODQyOA==,10050469,2019-01-07T19:16:05Z,2019-01-07T19:16:05Z,MEMBER,"> It just occurred to me that it would be nice to have some extra info about the data, such as dtype.
II was about to ask about it ;-). What other attribute than `dtype` were you thinking about?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,396501063
https://github.com/pydata/xarray/pull/2612#issuecomment-451421221,https://api.github.com/repos/pydata/xarray/issues/2612,451421221,MDEyOklzc3VlQ29tbWVudDQ1MTQyMTIyMQ==,10050469,2019-01-04T11:36:00Z,2019-01-04T11:36:00Z,MEMBER,This is (one more time) an extremely useful addition to xarray - thanks so much @fujiisoup !,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,391477755
https://github.com/pydata/xarray/pull/2645#issuecomment-451243718,https://api.github.com/repos/pydata/xarray/issues/2645,451243718,MDEyOklzc3VlQ29tbWVudDQ1MTI0MzcxOA==,10050469,2019-01-03T19:03:29Z,2019-01-03T19:03:29Z,MEMBER,"> I expect some will feel its too soon to merge this
I never wrote py2 code myself so I don't think I'm of the ""conservative"" type, but I wonder if this PR will make it harder to provide bugfix cherry-picks on the hypothetical py2 compatible `0.11.x` branch? Or do we want to ditch this possibility right away and simply focus on the bright py3-only future?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,395431629
https://github.com/pydata/xarray/pull/2618#issuecomment-449067569,https://api.github.com/repos/pydata/xarray/issues/2618,449067569,MDEyOklzc3VlQ29tbWVudDQ0OTA2NzU2OQ==,10050469,2018-12-20T17:04:30Z,2018-12-20T17:04:30Z,MEMBER,"> Do we really want a np.masked_array or do we just want an array with np.Nans in it? I prefer nans, but I guess the downside is type conversion for ints?
Masked arrays come with huge performance drops, I don't think we should use these.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,392361367
https://github.com/pydata/xarray/pull/2618#issuecomment-448542055,https://api.github.com/repos/pydata/xarray/issues/2618,448542055,MDEyOklzc3VlQ29tbWVudDQ0ODU0MjA1NQ==,10050469,2018-12-19T10:15:33Z,2018-12-19T10:15:33Z,MEMBER,"I wonder if `nodatavals` is the only attribute for masking - in the doc (https://rasterio.readthedocs.io/en/latest/topics/masks.html) they also mention `nodata`, which in my experience is also used","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,392361367
https://github.com/pydata/xarray/pull/2571#issuecomment-447687361,https://api.github.com/repos/pydata/xarray/issues/2571,447687361,MDEyOklzc3VlQ29tbWVudDQ0NzY4NzM2MQ==,10050469,2018-12-16T23:40:32Z,2018-12-16T23:40:32Z,MEMBER,"> +1 for putting this in ""Breaking changes""
Sorry for being so slow. I just done it, will merge tomorrow once the tests pass.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,384004189
https://github.com/pydata/xarray/pull/2571#issuecomment-443420763,https://api.github.com/repos/pydata/xarray/issues/2571,443420763,MDEyOklzc3VlQ29tbWVudDQ0MzQyMDc2Mw==,10050469,2018-12-01T11:51:50Z,2018-12-01T11:51:50Z,MEMBER,"Thanks! Made the change as requested. Regarding the general design:
> With this implementation, if one decodes the times, and then saves things back out to a file, a ""time bounds"" variable will contain units and calendar attributes even though it might not have them initially. I'm not sure if this is a big deal (in this case it is simply adding redundant metadata), but I just wanted to bring it up in case it was a concern.
I agree - I don't think it is a big deal either. It must also be noted that this might break some code in downstream libraries (including mine) which has built workarounds for this and will now error because the bounds are already decoded. Here also, I'm quite confident that this is an edge case but its worth mentioning. Should I put my what's new in ""Breaking changes"" instead?
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,384004189
https://github.com/pydata/xarray/pull/2571#issuecomment-443026008,https://api.github.com/repos/pydata/xarray/issues/2571,443026008,MDEyOklzc3VlQ29tbWVudDQ0MzAyNjAwOA==,10050469,2018-11-29T23:00:10Z,2018-12-01T11:45:09Z,MEMBER,"I addressed all comments except the fixtures, which seemed a bit overkill (but I simplified the tests). Thanks!","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,384004189
https://github.com/pydata/xarray/issues/2561#issuecomment-441349361,https://api.github.com/repos/pydata/xarray/issues/2561,441349361,MDEyOklzc3VlQ29tbWVudDQ0MTM0OTM2MQ==,10050469,2018-11-24T07:24:23Z,2018-11-24T07:24:23Z,MEMBER,"> Actually, this shows up in our online docs too
My apologies for the oversight! And thanks for the fix.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,383405975
https://github.com/pydata/xarray/issues/2565#issuecomment-441228064,https://api.github.com/repos/pydata/xarray/issues/2565,441228064,MDEyOklzc3VlQ29tbWVudDQ0MTIyODA2NA==,10050469,2018-11-23T12:23:00Z,2018-11-23T12:24:17Z,MEMBER,"Good points!
> I do notice the time variable in your file has a bounds attribute, which points to the name time_bnds. Is that something required by CF conventions? We might be able to rely on that.
Yes, `bounds` is a CF name:
http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#cell-boundaries
It seems reasonable to assume that the bounds should share the same units as time, therefore I think that the workaround you are using could actually be implemented in xarray, but the actual implementation might be a bit messy...
(it would be much simpler if CF would prescribe the units to also be available at the the `time_bnds` level...)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,383791450
https://github.com/pydata/xarray/issues/2565#issuecomment-441222614,https://api.github.com/repos/pydata/xarray/issues/2565,441222614,MDEyOklzc3VlQ29tbWVudDQ0MTIyMjYxNA==,10050469,2018-11-23T11:54:14Z,2018-11-23T11:54:14Z,MEMBER,I am actually in favor of 3: also decode `time_bnds`,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,383791450
https://github.com/pydata/xarray/issues/2561#issuecomment-441215148,https://api.github.com/repos/pydata/xarray/issues/2561,441215148,MDEyOklzc3VlQ29tbWVudDQ0MTIxNTE0OA==,10050469,2018-11-23T11:16:31Z,2018-11-23T11:16:31Z,MEMBER,"> Obviously a problem with computation.rst, but could someone help me please?
I doubt this is an xarray problem: we didn't write the documentation with this use case in mind. If you find a way to solve the problem that doesn't brake our Sphinx documentation, then please let us know!","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,383405975
https://github.com/pydata/xarray/issues/2562#issuecomment-441042589,https://api.github.com/repos/pydata/xarray/issues/2562,441042589,MDEyOklzc3VlQ29tbWVudDQ0MTA0MjU4OQ==,10050469,2018-11-22T14:13:17Z,2018-11-22T14:13:17Z,MEMBER,"This is the expected behavior, see: http://xarray.pydata.org/en/stable/generated/xarray.DataArray.where.html","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,383534360
https://github.com/pydata/xarray/issues/2551#issuecomment-437707951,https://api.github.com/repos/pydata/xarray/issues/2551,437707951,MDEyOklzc3VlQ29tbWVudDQzNzcwNzk1MQ==,10050469,2018-11-11T21:46:02Z,2018-11-11T21:46:02Z,MEMBER,"> but now operates lazily.
If so, how does the dataset access the data if the file is closed? Shouldn't it raise an error instead?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,379177627
https://github.com/pydata/xarray/issues/2551#issuecomment-437705060,https://api.github.com/repos/pydata/xarray/issues/2551,437705060,MDEyOklzc3VlQ29tbWVudDQzNzcwNTA2MA==,10050469,2018-11-11T21:08:13Z,2018-11-11T21:08:13Z,MEMBER,Actually I have to ask: why is it possible to to an operation on a closed dataset? What is happening under the hood which creates this error and wasn't earlier?,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,379177627
https://github.com/pydata/xarray/issues/2551#issuecomment-437664983,https://api.github.com/repos/pydata/xarray/issues/2551,437664983,MDEyOklzc3VlQ29tbWVudDQzNzY2NDk4Mw==,10050469,2018-11-11T12:10:36Z,2018-11-11T12:10:36Z,MEMBER,"> Yep, that looks a bug on your end. Were you using autoclose=True before?
No, the exact same piece of code works without error with xarray prev 0.11. Closing this now!","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,379177627
https://github.com/pydata/xarray/issues/2551#issuecomment-437574599,https://api.github.com/repos/pydata/xarray/issues/2551,437574599,MDEyOklzc3VlQ29tbWVudDQzNzU3NDU5OQ==,10050469,2018-11-10T10:39:09Z,2018-11-10T10:40:35Z,MEMBER,"> I am slightly regretting not doing a release candidate here,
I should be better placed than anyone to anticipate and test more frequently on master :roll_eyes:
So this reproduces the problem on my machine and [travis](https://travis-ci.org/pydata/xarray/builds/453229051?utm_source=github_status&utm_medium=notification). Note the misplaced computation out of the `with` block:
```python
import xarray as xr
import numpy as np
import netCDF4
import os
try:
os.remove('test.nc')
except OSError:
pass
thick = np.zeros((180, 200), np.float32)
ds = xr.Dataset()
ds['thick'] = (('y', 'x'), thick)
ds.to_netcdf('test.nc')
with xr.open_dataset('test.nc') as ds:
dummy = ds.thick.isel(x=('z', [1, 3, 4]), y=('z', [7, 2, 1]))
dummy.min() # this is the issue
with netCDF4.Dataset('test.nc', 'a') as nc:
nc.variables['thick'][:] = thick
```
I guess this was actually a bug in our code, but for some reason it worked fine with earlier xarray versions. I'm not sure if this requires action on the xarray side in the end...","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,379177627
https://github.com/pydata/xarray/issues/2535#issuecomment-436257224,https://api.github.com/repos/pydata/xarray/issues/2535,436257224,MDEyOklzc3VlQ29tbWVudDQzNjI1NzIyNA==,10050469,2018-11-06T13:45:34Z,2018-11-06T13:45:34Z,MEMBER,I can reproduce this on my machine - also linux. This is going to be hard to track down though. ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,376389539
https://github.com/pydata/xarray/issues/2505#issuecomment-433133764,https://api.github.com/repos/pydata/xarray/issues/2505,433133764,MDEyOklzc3VlQ29tbWVudDQzMzEzMzc2NA==,10050469,2018-10-25T17:15:54Z,2018-10-25T17:15:54Z,MEMBER,"Did any other library have a warning for this? I think that if we follow the lead of ipython, matplotlib and https://python3statement.org/ then all we have to do is make 0.12 non-installable on py2, and py2 users will stick to 0.11 *ad vitam æternam*.
It would be quite mean to have them listen to a warning all the time they import xarray on top of that :smile:
ipython [docs](https://ipython.readthedocs.io/en/stable/) have a big warning banner though ","{""total_count"": 3, ""+1"": 3, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,373574495
https://github.com/pydata/xarray/pull/2433#issuecomment-432794262,https://api.github.com/repos/pydata/xarray/issues/2433,432794262,MDEyOklzc3VlQ29tbWVudDQzMjc5NDI2Mg==,10050469,2018-10-24T19:20:50Z,2018-10-24T19:20:50Z,MEMBER,"> If not, I can send in a PR to document this bit
I've used the [gallery](http://xarray.pydata.org/en/latest/auto_gallery/plot_cartopy_facetgrid.html#sphx-glr-auto-gallery-plot-cartopy-facetgrid-py) to document these kind of things. It's a bit lost in the doc currently though.
> (the use of _mappables is not very obvious; maybe we should make it public?)
Looks like we need it for these kind of feature, right?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,362918990
https://github.com/pydata/xarray/issues/2497#issuecomment-431583686,https://api.github.com/repos/pydata/xarray/issues/2497,431583686,MDEyOklzc3VlQ29tbWVudDQzMTU4MzY4Ng==,10050469,2018-10-20T13:50:25Z,2018-10-20T13:50:25Z,MEMBER,"Thanks! See https://github.com/pydata/xarray/pull/2498
(Note that GitHub allows to edit files online and does the branching / PR stuff for you, so that small fixes like this can be done exclusively online.)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,372134568
https://github.com/pydata/xarray/issues/2483#issuecomment-429559621,https://api.github.com/repos/pydata/xarray/issues/2483,429559621,MDEyOklzc3VlQ29tbWVudDQyOTU1OTYyMQ==,10050469,2018-10-13T17:22:52Z,2018-10-13T17:22:52Z,MEMBER,"@am-thyst you are using a relatively old version of python (3.4), and the conda packages are probably not being updated anymore.
Using miniconda is fine, especially if you use [conda forge](https://conda-forge.org/) (`conda config --add channels conda-forge`).
If you want to stay up to date in the future, define a new environment with a newer version of python (3.7 is the latest) and install your packages from there:
```
conda config --add channels conda-forge
conda create -n myenv python=3.7
source activate myenv (linux/mac) or activate myenv (windows)
conda install xarray
```
Doc: https://conda.io/docs/user-guide/tasks/manage-environments.html","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,369695807
https://github.com/pydata/xarray/pull/2462#issuecomment-427649012,https://api.github.com/repos/pydata/xarray/issues/2462,427649012,MDEyOklzc3VlQ29tbWVudDQyNzY0OTAxMg==,10050469,2018-10-07T12:19:27Z,2018-10-07T12:19:27Z,MEMBER,"> Weird that @stickler-ci broke. We're still using it at pandas-gbq and it's working well.
I could try to reactivate it now that I've deactivated it. Still suspicious that clicking @stickler-ci gives a 404 error.
I like pep8speaks for it's less verbose messaging (all in one message that gets updated after each new commit) and for the fact that pandas is also using it, but I have no strong opinion about it.
If we use pep8speaks we should use the same config as pandas though, and we should ask them about `#noqa` : done here: https://github.com/OrkoHunter/pep8speaks/issues/96
","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,366653476
https://github.com/pydata/xarray/pull/2462#issuecomment-427585414,https://api.github.com/repos/pydata/xarray/issues/2462,427585414,MDEyOklzc3VlQ29tbWVudDQyNzU4NTQxNA==,10050469,2018-10-06T16:04:40Z,2018-10-06T16:04:40Z,MEMBER,"I also have the impression that noqa are ignored by pep8speask, although I haven't seen any related issue on [their repo](https://github.com/OrkoHunter/pep8speaks/issues). Probably another reason for a diff_only option for now.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,366653476
https://github.com/pydata/xarray/pull/2462#issuecomment-427584175,https://api.github.com/repos/pydata/xarray/issues/2462,427584175,MDEyOklzc3VlQ29tbWVudDQyNzU4NDE3NQ==,10050469,2018-10-06T15:47:58Z,2018-10-06T15:47:58Z,MEMBER,"> Why do we need diff_only
I was worried about all the unrelated pep8 errors on this PR: https://github.com/pydata/xarray/pull/2463
Although I'm not sure where they come from.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,366653476
https://github.com/pydata/xarray/pull/2462#issuecomment-427042220,https://api.github.com/repos/pydata/xarray/issues/2462,427042220,MDEyOklzc3VlQ29tbWVudDQyNzA0MjIyMA==,10050469,2018-10-04T14:33:26Z,2018-10-04T14:33:26Z,MEMBER,I think we need a set-up file to set diff_only on PR. See the pandas pep8speaks template: https://github.com/pandas-dev/pandas/blob/master/.pep8speaks.yml,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,366653476
https://github.com/pydata/xarray/pull/2462#issuecomment-426935090,https://api.github.com/repos/pydata/xarray/issues/2462,426935090,MDEyOklzc3VlQ29tbWVudDQyNjkzNTA5MA==,10050469,2018-10-04T08:43:15Z,2018-10-04T08:43:15Z,MEMBER,Thanks! I just switched off stickler which is still broken anyway. ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,366653476
https://github.com/pydata/xarray/pull/2426#issuecomment-423624789,https://api.github.com/repos/pydata/xarray/issues/2426,423624789,MDEyOklzc3VlQ29tbWVudDQyMzYyNDc4OQ==,10050469,2018-09-21T18:08:02Z,2018-09-21T18:08:02Z,MEMBER,"Appart from a pep8 line length problem LGTM too!
Sitckler is on strike (https://github.com/pydata/xarray/issues/2428)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,362443466
https://github.com/pydata/xarray/issues/2209#issuecomment-423251446,https://api.github.com/repos/pydata/xarray/issues/2209,423251446,MDEyOklzc3VlQ29tbWVudDQyMzI1MTQ0Ng==,10050469,2018-09-20T16:39:58Z,2018-09-20T16:39:58Z,MEMBER,Closed via https://github.com/rtfd/readthedocs.org/issues/4432,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,328572578
https://github.com/pydata/xarray/issues/2422#issuecomment-423111183,https://api.github.com/repos/pydata/xarray/issues/2422,423111183,MDEyOklzc3VlQ29tbWVudDQyMzExMTE4Mw==,10050469,2018-09-20T09:29:14Z,2018-09-20T09:29:28Z,MEMBER,"> I cannot reproduce this with a dataset with decreasing latitude
Maybe a MPL version issue? Because our docs are also afffected, see:
- http://xarray.pydata.org/en/stable/plotting.html#two-dimensions
- http://xarray.pydata.org/en/latest/plotting.html#two-dimensions
> @fmaussion I'd appreciate it if you could look at this
I will have a look now","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,361818115
https://github.com/pydata/xarray/issues/2422#issuecomment-422955254,https://api.github.com/repos/pydata/xarray/issues/2422,422955254,MDEyOklzc3VlQ29tbWVudDQyMjk1NTI1NA==,10050469,2018-09-19T20:55:32Z,2018-09-19T20:55:32Z,MEMBER,"Looks like a difficult thing to test, also...","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,361818115
https://github.com/pydata/xarray/issues/2424#issuecomment-422954244,https://api.github.com/repos/pydata/xarray/issues/2424,422954244,MDEyOklzc3VlQ29tbWVudDQyMjk1NDI0NA==,10050469,2018-09-19T20:52:12Z,2018-09-19T20:52:12Z,MEMBER,"> I suppose it would be good to sort out #2422 (Plot2D no longer sorts coordinates before plotting)
That together with https://github.com/pydata/xarray/pull/2398 would be great","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,361915770
https://github.com/pydata/xarray/pull/2398#issuecomment-422864322,https://api.github.com/repos/pydata/xarray/issues/2398,422864322,MDEyOklzc3VlQ29tbWVudDQyMjg2NDMyMg==,10050469,2018-09-19T16:14:48Z,2018-09-19T16:14:48Z,MEMBER,"> But we can save that for another PR :)
See also https://github.com/pydata/xarray/issues/1288 : ``integrate`` is the next on my list ;) - I can try to give it a go if @fujiisoup doesn't want to do it himself","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,356698348