Closed djhoese closed 3 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 95.94%. Comparing base (
834f45d
) to head (fc95ee1
). Report is 332 commits behind head on main.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Totals | |
---|---|
Change from base Build 9687731633: | 0.008% |
Covered Lines: | 51634 |
Relevant Lines: | 53760 |
Is there a way for the user to select which one is used? I can think of many circumstances in which the parallax corrected versions would be preferred (despite the metadata issues).
@simonrp84 At the moment, no. It would make sense, but maybe we save that for another PR if someone really wants it. Right now, besides this cloud height file, there are no other lon/lats available in the EDR files that I'm familiar with. We could either do a kwarg-style choice for users or there is (technically) the ability to customize the YAML right now and describe all the products you want and their specific lon/lats.
I got the "good enough" signal from Panu on slack. Merging...thanks for the reviews.
Totals | |
---|---|
Change from base Build 9687731633: | 0.009% |
Covered Lines: | 51641 |
Relevant Lines: | 53767 |
The VIIRS EDR CloudHeight files includes not only normal lon/lat arrays but a parallax corrected lon/lat. These parallax lon/lats don't include proper metadata (ex.
_FillValue
) so loading them causes fill values to remain like-999.9
instead of NaN. My previous code in this reader was rather naive and basically said if a variable name contained "longitude" or "latitude" then we should use it as the geolocation for our data arrays. This code was picking up the parallax corrected lon/lats instead of the "standard" ones. This PR is an attempt at making the reader smarter at choosing the right lon/lat arrays.CC @kathys
AUTHORS.md
if not there already