issue_comments

So I'll say that taking my dataset and running nc.squeeze() was illustrative to the problem here. I see now that if a Dataset has scalar coordinates, they apply to every DataArray/Variable inside. So I see what prompts the current behavior.

I think the mismatch in my mental model is due to me coming from netCDF CF land, where coordinates for a variable are based on: 1. Other variables that match relevant shared dimension names 2. Those explicitly listed in the coordinates attribute

I see now that xarray does NOT implement that model.

This was provoked by challenges creating a new DataArray, but I see those can be solved by passing in both dims and coords (when coords contains some scalar coords).

One way to fix this would be to never associate non-dim coords when creating a DataArray for a dimension coordinate. But I think it may be better to encourage users to use .variable instead.

The behavior I'd advocate for is that a subsetting/selection operation should never add new coordinates that weren't previously present.

What do you mean by "previously present"? We'd have to track state of some sort, which doesn't seem ideal. Alternatively, the user could use .sel(time=[0]). That would preserve the identity of time as a dimension coordinate (of size 1), and it would not get associated when extracting lat

IMO, it's not correctly implementing the rule as you phrased it. You said "still present", which isn't the case here since the coordinate wasn't present before.

Another way of describing the current behavior would be that xarray keeps around "every coordinate which could possibly still be valid," which is determined based upon dimension names.

The main challenge is that "Coordinate variables should not have their coordinates changed" doesn't really make sense in Xarray's data model. Only Dataset or DataArray objects have coordinates, which apply to the the entire Dataset/DataArray.

Let me give an example of why we might want to keep scalar coordinates around. Consider a Dataset where lat and lon need to be represented as 2D arrays, along x and y dimensions. If we index out a single lat/lon point, i.e., ds.isel(x=0, y=0) it would have scalar coordinates "x", "y", "lat" and "lon." If we now convert any of these to a DataArray, arguably all the coordinates are still valid.

IMO, it's not correctly implementing the rule as you phrased it. You said "still present", which isn't the case here since the coordinate wasn't present before.

The behavior I'd advocate for is that a subsetting/selection operation should never add new coordinates that weren't previously present. That by itself would be less surprising. It would also help make things more sensible given that the coordinate is only added currently in the scalar case--if you ask for more data, the coordinate isn't added, which is also unexpected given the scalar case.

This was an intentional design choice, back in the early days of Xarray.

The rule Xarray uses for choosing which coordinates to associate with a DataArray created from a Dataset or DataArray is "every coordinate whose dimensions are still present on the new DataArray." This includes scalar coordinates, which are always kept around (because their dimensions are always included).

What rule would you suggest instead? I agree that the behavior in this case "feels" wrong, but keep in mind that once time because a scalar coordinate, Xarray doesn't have any way of knowing that it used to have its own dimension.