Fix VII (METimage) reader angles names#3317
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3317 +/- ##
==========================================
- Coverage 96.34% 96.33% -0.02%
==========================================
Files 463 463
Lines 58916 58916
==========================================
- Hits 56760 56754 -6
- Misses 2156 2162 +6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
pnuu
left a comment
There was a problem hiding this comment.
LGTM
Just wondering whether "observation" and "satellite" zenith angles are the same thing? It could be argued that observation zenith angle is the angle in which the satellite makes the measurement, while satellite zenith angle is the angle the satellite is seen from the observed location.
|
Yeah, I think "sensor", "viewing", "observation" and "satellite" _zenith are used interchangeably in the community - even in satpy each one of these is used. I went for "satellite" since that's what the default modifiers use, e.g. satpy/satpy/etc/composites/visir.yaml Lines 52 to 63 in 579e797 I checked and at the center of the swath the value is 0 (not 90), so that's as expected I'd say. |
|
To confirm even more that the file variable indeed contains the commonly used viewing/satellite angle (the angle under which the satellite is seen from the ground): the METimage scanner goes up to +- 54.21°, while the "observation angle" data in the file goes up to e.g. 66.8° in my test granule. So I think we're good :) |
|
Thanks for confirming! CI build for Windows is failing on unrelated |
This PR fixes the names of satellite and solar angles in the yaml file of the VII/METimage reader, so that they adhere to the convention and are correctly used in predefined modifiers, such as the
sunz_correcteddefined ingeneric.yaml. As discussed in https://pytroll.slack.com/archives/C0LNH7LMB/p1765897278746739 .Before this PR, the sunz_correction was not using the in-file angles as they could not be found due to the different name, causing issues when correcting Scenes with granules that were far apart in time; see the bright overcorrection over Europe, solved by this PR:


before
after