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/2209#issuecomment-407678876,https://api.github.com/repos/pydata/xarray/issues/2209,407678876,MDEyOklzc3VlQ29tbWVudDQwNzY3ODg3Ng==,810663,2018-07-25T08:37:53Z,2018-07-25T08:37:53Z,NONE,"> Pinging @pelson who have some ideas in mind on how to address this problem.
The ideas relate to the fetching of the index, which will take orders of magnitude less time than the resolve and download stages in ``conda``. They aren't entirely unrelated though, as a smaller index (the proposal) would result in fewer options for the conda solver to have to work through. No matter what we do, caching the binaries will have the same impact, though it is a challenge to cache sensibly without having a *really* large cache... You may find that caching an environment.yaml actually has more of an impact than caching the binaries themselves (i.e. this means you continue to download the binaries each time, but don't do a conda resolve each time).","{""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/2164#issuecomment-404830736,https://api.github.com/repos/pydata/xarray/issues/2164,404830736,MDEyOklzc3VlQ29tbWVudDQwNDgzMDczNg==,810663,2018-07-13T13:17:44Z,2018-07-13T13:17:44Z,NONE,"> This could probably either be done in a separate package
Why a separate package and not in nc-time-axis? (Or alternatively, just in cftime, as you say)
FWIW https://github.com/SciTools/nc-time-axis/issues/16 tried to get the ball rolling on clarifications around the CalendarDateTime object. That was necessary in the days when there was a single PhoneyDateTime object, that didn't have calendar information associated with it. It seems that some refactoring is very plausible in nc-time-axis at this point. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,324740017
https://github.com/pydata/xarray/pull/814#issuecomment-354980754,https://api.github.com/repos/pydata/xarray/issues/814,354980754,MDEyOklzc3VlQ29tbWVudDM1NDk4MDc1NA==,810663,2018-01-03T10:33:21Z,2018-01-03T10:33:21Z,NONE,Closed by #1750?,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,145140657
https://github.com/pydata/xarray/pull/1750#issuecomment-354977934,https://api.github.com/repos/pydata/xarray/issues/1750,354977934,MDEyOklzc3VlQ29tbWVudDM1NDk3NzkzNA==,810663,2018-01-03T10:19:16Z,2018-01-03T10:19:16Z,NONE,"Apologies for the delay. This is a great first pass. Definitely more metadata sharing possible, but I'm glad this has been merged - let's grow the capability as required. If any issues crop up, please feel free to ping me & @bjlittle. 👍 ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,278286073
https://github.com/pydata/xarray/pull/814#issuecomment-262359050,https://api.github.com/repos/pydata/xarray/issues/814,262359050,MDEyOklzc3VlQ29tbWVudDI2MjM1OTA1MA==,810663,2016-11-22T20:39:23Z,2016-11-22T20:39:23Z,NONE,"This is looking pretty comprehensive to me. Could maybe do with a couple of tests perhaps, but otherwise 👍 .","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,145140657
https://github.com/pydata/xarray/pull/814#issuecomment-228703831,https://api.github.com/repos/pydata/xarray/issues/814,228703831,MDEyOklzc3VlQ29tbWVudDIyODcwMzgzMQ==,810663,2016-06-27T10:00:54Z,2016-06-27T10:00:54Z,NONE,"> @pelson @rhattersley any tips on handling the edge cases of cubes with some, but not all missing dim_coords?
I might consider something like (untested):
```
for dim in xrange(cube.ndim):
try:
dim_coord = cube.coord(dim_coords=True, dimensions=(dim,))
except iris.exceptions.CoordinateNotFoundError:
index_coord = range(cube.shape[dim])
```
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,145140657
https://github.com/pydata/xarray/pull/814#issuecomment-204692732,https://api.github.com/repos/pydata/xarray/issues/814,204692732,MDEyOklzc3VlQ29tbWVudDIwNDY5MjczMg==,810663,2016-04-02T10:40:59Z,2016-04-02T10:40:59Z,NONE,"Thanks for pinging @shoyer. I'll also ping @rhattersley, and one of us will take a good look in the next few days. :+1:
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,145140657
https://github.com/pydata/xarray/issues/657#issuecomment-157616130,https://api.github.com/repos/pydata/xarray/issues/657,157616130,MDEyOklzc3VlQ29tbWVudDE1NzYxNjEzMA==,810663,2015-11-18T06:25:27Z,2015-11-18T06:25:27Z,NONE,"Thanks @fmaussion - I've raised it in https://github.com/SciTools/cartopy/issues/700. Thanks for putting together the self contained example - it's fine to have xray as a dependency on that. FWIW you would do something like `plt.pcolormesh(lons, lats, l1 + l2, transform=ccrs.PlateCarree())` if you didn't have a DataArray.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,117002929
https://github.com/pydata/xarray/issues/657#issuecomment-157008004,https://api.github.com/repos/pydata/xarray/issues/657,157008004,MDEyOklzc3VlQ29tbWVudDE1NzAwODAwNA==,810663,2015-11-16T11:56:46Z,2015-11-16T11:56:46Z,NONE,"There is definitely scope for being smarter with cartopy's pcolormesh. There isn't an issue for it yet, but would be happy if you opened up a performance related issue in cartopy. pcolormesh will always be slower than imshow, but in most cases, not an order of magnitude slower!
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,117002929