issue_comments

Indeed. Thanks to all people involved!

I think either way works. Probably easiest to fork this branch and then merge in the latest from master. On Thu, Nov 30, 2017 at 3:38 PM Neil Parley notifications@github.com wrote:

I think also I could make you a contributor or transfer the branch to someone. So that might be an option too.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pydata/xarray/pull/814#issuecomment-348225565, or mute the thread https://github.com/notifications/unsubscribe-auth/ABKS1oT1qWWy-o5CJe6Y45Y-DsGhjTucks5s7swSgaJpZM4H9jGH .

No worries! The great thing about GitHub is that it's pretty easy for someone else to pick up your work :)

On Tue, Jun 20, 2017 at 12:25 AM, Neil Parley notifications@github.com wrote:

Sorry guys I don't have time to do anything on this (or any open source stuff) at the moment.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pydata/xarray/pull/814#issuecomment-309667894, or mute the thread https://github.com/notifications/unsubscribe-auth/ABKS1jC8Vrt_NKYbc4Z3-sgDpRAfaDqsks5sF3PXgaJpZM4H9jGH .

Yes, we would still love to get this in, though it might need a few other changes to work now. Could you open a new PR with the tests added back in? (Assuming Neil is not interested in picking this back up)

On Mon, Jun 19, 2017 at 8:58 AM, DWesl notifications@github.com wrote:

If you're still looking for the old tests, it looks like they disappeared in the last merge commit, f48de5 https://github.com/pydata/xarray/pull/814/commits/f48de5a3ea916b80a7bfc070c3c1c3549e931189#diff-48ab4ba033ad06981f566a2e2f561f5aL1819 .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pydata/xarray/pull/814#issuecomment-309484883, or mute the thread https://github.com/notifications/unsubscribe-auth/ABKS1gi9-YLVTLayYcMiFTqVSUy1v729ks5sFpqkgaJpZM4H9jGH .

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

Indeed, merging this is really just blocked on tests right now. We need at least something so we can verify that this basically works.

No worries, no rush here from my end :). On Sun, Jun 26, 2016 at 1:35 PM Neil Parley notifications@github.com wrote:

@shoyer https://github.com/shoyer I have not forgotten about this PR, I just been working a lot on a pandas PR updating the ci and it's been taking up a lot of my spare time.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/pydata/xarray/pull/814#issuecomment-228596914, or mute the thread https://github.com/notifications/unsubscribe/ABKS1tPi3K7IyPa2MwwQWDfnrwMemmetks5qPmQJgaJpZM4H9jGH .

@pelson @rhattersley any tips on handling the edge cases of cubes with some, but not all missing dim_coords?

@nparley I would hate for this to get lost. I'm OK merging this before it covers every edge case -- let's just document the limitations and leave that for later cleanup.

OK, I was not paying attention here with #860 -- I assumed that the build problem was with the build including Iris, but it was actually the other build that started spontaneously failing.

I'm afraid I already merged that PR, so could you please try rebasing again? Sorry for the hassle! On the plus side, I think using conda-forge will ultimately work better than using all the separate channels.

@nparley Let's see if https://github.com/pydata/xarray/pull/860 works. I think that will probably solve the CI issue (at least on Travis-CI).

@rhattersley I think this function is cleaner without the cf_var_name argument, so I would probably remove it. That said, I usually try to avoid issuing warnings at all.

@jhamman and I have a few minor suggestions, but otherwise this looks good!

This PR needs "what's new" and "api" entries in the docs.

One other thing that I noticed from the latest example -- it would be nice to covert cell methods from Cubes into string attributes on DataArrays.

Is there any way to know for sure whether a coordinate has been automatically created? Or is the name the only clue?

I'm afraid the name is the only clue. My inclination would be not to do anything special here to "un-name" default coordinates, assuming Iris has a straightforward way to get rid of them. Dimensions like dim0 come up quickly in demo code but rarely in practice -- it's mostly a signal to the user that the should pick a meaningful name.

If this is the way to do things then does this comment need deleting?

Yes, that comment is out of date. I'm currently refactoring that code though, so let me take care care of it.

There's a separate argument about whether or not xarray should automatically convert cubes when passed into the xarray.DataArray constructor. We do this for pandas objects, but not any other labelled array types, currently.

There's no good solution for representing bounds in xarray -- we can put these as coordinates on Dataset objects, but they aren't supported on DataArray objects. I had some plans to add an IntervalIndex type to pandas (https://github.com/pydata/pandas/pull/8707) which would let us support bounds, but honestly I'm not sure if/when I'll finish that.

This is awesome!

Let's try to add some documentation -- at least a mention in What's New.

CC @pelson