issue_comments

Yes. I think we have some existing internal machinery for this in align (see indexes). Indexes that are explicitly provided in coords (e.g., coords={'time': time_values}) should take precedence. Indexes that are incidentally included on another coordinate should not (e.g., coords={'day_of_week': DataArray(values, coords=[('time', time_values)])}).

OK great! To confirm: you're up for (1) - i.e. coords set the index; rather than an outer join with all available indexes.

Yes, I think there is a good case that explicitly provided coords should reindex the data. Possibly we should save this for the next major release (0.11) but it should happen. These cases currently result in an error so I'm not worried about backwards compatibility.

I'd be up for implementing this, if people agree. Let me know...

On reflection, I favor (1) pretty clearly. I don't have much experience with XRay, so I trust you more than I trust myself, but: - In our use cases, we care about exactly what the axes / coords are. So we need some single source of truth there. If I implemented this using the outer join, we wouldn't use it much! - I can't clearly visualize the use cases supporting the other side - where users have coords that they want to add 'in addition', but that aren't on a DataArray they're supplying. - I haven't heard of people being confused on the pandas index= parameter (although I'm absent from SO discussions etc, so may have missed them)

Let me know your thoughts. We should pick the right way, not the preference of the person implementing it, so chose what you think is best.

I'm sort of on the fence :). Pandas actually does (1), so there is some precedence for this:

``` In [12]: import pandas as pd

In [13]: df = pd.DataFrame({'x': list('abc')})

In [14]: df Out[14]: x 0 a 1 b 2 c

In [15]: pd.DataFrame(df, index=[1, 2]) Out[15]: x 1 b 2 c ```

That said, I know this has been a point of confusion for new pandas users, and I do like the current property of the Dataset constructor that it never removes data via alignment.

I don't see any obvious reason reason why coords should be treated differently than data_vars as far as data alignment in the Dataset constructor goes.

Two possibilities: 1. coords would take precedence, and all the DataArrays would be aligned to those. This is equivalent to the second example where arrays are added on with __setitem__ after construction 2. Everything is aligned with an outer join, nothing takes precedence (which I think means the constructor can never fail for alignment reasons)

I would favor (1), since you can be explicit about what coords you want to end up with; if you don't have a preference, you can neglect to supply coords and get the outer join.

But it sounds like you may favor (2)?

Is this desired behavior? I could imagine aligning to coords if they are explicitly supplied, but I don't know the nuances here.

Yes, I think aligning to coords (with an outer join) would probably be a good addition. This was not an intentional omission, just a scenario I did not anticipate. I don't see any obvious reason reason why coords should be treated differently than data_vars as far as data alignment in the Dataset constructor goes.