issue_comments

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).

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.

Closed by #1750?

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. 👍

This is looking pretty comprehensive to me. Could maybe do with a couple of tests perhaps, but otherwise 👍 .

@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])

Thanks for pinging @shoyer. I'll also ping @rhattersley, and one of us will take a good look in the next few days. :+1:

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.

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!