Use CF bounds for grid-cell corners where available - #187
Merged
Conversation
Descriptors that read a grid from a file have always found the corners of each grid cell by interpolating between cell centers and extrapolating at the ends of the grid. When a file follows the CF conventions and gives the `bounds` of its coordinates, those bounds describe the cells exactly, so use them instead. `get_corners_1d()` stitches `(n, 2)` bounds into `n + 1` corners, coping with bounds given either along the coordinate or always from the lower to the upper edge (as is common for descending latitude). `get_corners_2d()` turns `(ny, nx, 4)` bounds into `(ny + 1, nx + 1)` corner arrays. CF does not say which vertex of a cell comes first or which direction the four vertices are traversed in, so the ordering is worked out by finding the one where neighboring cells share vertices, considering latitude and longitude together since either alone is ambiguous. Bounds that describe cells with gaps or overlaps between them (1D) or that neighboring cells do not share (2D) cannot be represented by arrays of corners, so those cases warn and fall back to interpolating and extrapolating, as do a `bounds` attribute that points to a variable that is missing or the wrong shape. A file with no `bounds` attribute takes the old path silently. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Cover both the cases where the CF `bounds` of a coordinate are used and those where they cannot be and corners are interpolated and extrapolated instead. For 2D coordinates, check each of the vertex orderings a file might use. The datasets are built in memory so no mapping tools are needed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Add a section to the docs for each descriptor that reads a grid from a file describing when the CF `bounds` of the coordinates are used and when corners are interpolated and extrapolated from cell centers instead. Add the new `get_corners_1d()` and `get_corners_2d()` to the API reference. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Descriptors that read a grid from a file have always found the corners of each grid cell by interpolating between cell centers and extrapolating at the ends of the grid. When a file follows the CF conventions and gives the
boundsof its coordinates, those bounds describe the cells exactly, so use them instead.Version bumped to 2.4.0 for a release.