Explain name matching rules for dimension and non-dimension coordinates
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 4.2k
- Forks
- 1.4k
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 14
Description
This arose as part of https://github.com/pydata/xarray/pull/3352. Xarray has important-to-understand name-matching rules for whether or not a coordinate array is a dimension coordinate or a non-dimension coordinate. To my knowledge, this is not in the documentation anywhere.
This is what I had, but we decided to remove it since it was overly complicated for a list of key terms; maybe it'll be helpful going forward:
Name matching rules: Xarray follows simple but important-to-understand name matching rules for dimensions and coordinates. Let
arrbe an array with an existing dimensionxand assigned new coordinatesnew_coords. Ifnew_coordsis a list-like for e.g.[1, 2, 3]then they must be assigned a name that matches an existing dimension. For example, ifarr.assign_coords({'x': [1, 2, 3]}).However, if
new_coordsis a one-dimensionalDataArray, then the rules are slightly more complex. In this case, if bothnew_coords's name and only dimension match any dimension name inarr.dims, it is assigned as a dimension coordinate toarr. Ifnew_coords's name matches a name inarr.dimsbut its own dimension name does not, it is assigned as a non-dimension coordinate with namenew_coords.dims[0]toarr. Otherwise, an exception is raised.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing xarray's existing documentation for coordinate assignment and the name-matching examples described in this issue. Document the rules distinguishing dimension and non-dimension coordinates, including the exception case; done when these cases are clearly discoverable in the documentation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 50/100