Fix 'awips_tiled' writer producing an invalid y coordinate #1776
Conversation
This file contains 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
|
Looks like it was made into a PR here: pydata/xarray#5630 4 days ago, merged, and then released immediately. |
|
See #1777 for fixes. |
|
@djhoese As noted in slack, the area_extent and range of y coordinates are consistent. The y coordinate is increasing from a negative value to a positive value. I only checked the fixed grid that was broken before the bug fix. I will check the grid that was okay before the bug fix and make sure it is still okay and get back to you. |
|
Navigation and tiles looking good for both 211e and us_1km grids with clavrx data. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
@joleenf pointed out that something was wrong in the coordinates with the 'awips_tiled' writer. After spending a while tracking it down I discovered that the
add_offsetwas being set to the.min()value of the Y coordinate data. The Y data is always in descending order (negative scale_factor) so using the min as the add_offset results in the scale in-file values being-5119, -5118, ..., 0. For the existing templates, these values are int16 with_Unsigned = 'true'which means these negative values are incorrect (and -1 is the fill value). It is all just bad overall and resulted in invalid Y coordinates when unscaled from the file.@joleenf do you think you'd be able to test this with some of the other stuff you've been doing before I merge it?