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/7350#issuecomment-1338119644,https://api.github.com/repos/pydata/xarray/issues/7350,1338119644,IC_kwDOAMm_X85PwhXc,2448579,2022-12-05T20:22:43Z,2022-12-05T20:25:31Z,MEMBER,"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`","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1473329967
https://github.com/pydata/xarray/issues/7350#issuecomment-1338121102,https://api.github.com/repos/pydata/xarray/issues/7350,1338121102,IC_kwDOAMm_X85PwhuO,1217238,2022-12-05T20:23:46Z,2022-12-05T20:23:46Z,MEMBER,"> 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.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1473329967
https://github.com/pydata/xarray/issues/7350#issuecomment-1336302962,https://api.github.com/repos/pydata/xarray/issues/7350,1336302962,IC_kwDOAMm_X85Ppl1y,1217238,2022-12-04T02:16:25Z,2022-12-04T02:16:25Z,MEMBER,"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.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1473329967