Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update VIIRS L1b reader to use additional netcdf attributes #2891

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

simonrp84
Copy link
Member

@simonrp84 simonrp84 commented Aug 29, 2024

The VIIRS L1b reader (NASA format VIIRS data) misses some netCDF attributes that may be useful to users.
This PR adds those attributes: The day/night flag (Day, Night or Both) and the starting plus ending orbital direction (Ascending or Descending). I also added a test to make sure the attrs are being read.

  • Tests added

Copy link

codecov bot commented Aug 29, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.13%. Comparing base (869e4fe) to head (5d3de96).
Report is 138 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2891   +/-   ##
=======================================
  Coverage   96.13%   96.13%           
=======================================
  Files         383      383           
  Lines       55688    55691    +3     
=======================================
+ Hits        53534    53537    +3     
  Misses       2154     2154           
Flag Coverage Δ
behaviourtests 3.88% <0.00%> (-0.01%) ⬇️
unittests 96.22% <100.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@coveralls
Copy link

coveralls commented Aug 29, 2024

Pull Request Test Coverage Report for Build 13574300409

Details

  • 3 of 3 (100.0%) changed or added relevant lines in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 96.237%

Totals Coverage Status
Change from base Build 13543289700: 0.0%
Covered Lines: 53784
Relevant Lines: 55887

💛 - Coveralls

Copy link
Member

@djhoese djhoese left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I'm fine with this as a short term solution, I think this is yet another case of the readers maybe being too restrictive/inflexible for what some users really want. Or rather, it forces us to draw the line on what satpy readers really are. Are they generic readers that provide all the information from the files in a semi-standard way? Or do they provide only the information that is shared between all (most) Satpy readers (the data + common metadata)?

Side question: Should the orbit information go in an orbital_parameters sub-dictionary like we do for lon/lat/alt information: https://satpy.readthedocs.io/en/stable/reading.html#orbital-parameters

Comment on lines 37 to 51
@property
def day_night_flag(self):
"""Get the day/night flag."""
return self["/attr/DayNightFlag"]

@property
def start_direction(self):
"""Get the swath start direction flag."""
return self["/attr/startDirection"]

@property
def end_direction(self):
"""Get the swath end direction flag."""
return self["/attr/endDirection"]

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see a reason for these to be properties on the class. Could you change this to just access self["/attr/endDirection"] (and the others) directly in the get_metadata method?

Comment on lines 206 to 208
"day_night": self.day_night_flag,
"start_direction": self.start_direction,
"end_direction": self.end_direction,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could/should one or more of these go into an orbital_parameters sub-dictionary?

https://satpy.readthedocs.io/en/stable/reading.html#dataset-metadata

Copy link
Member

@mraspaud mraspaud left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mraspaud
Copy link
Member

While I'm fine with this as a short term solution, I think this is yet another case of the readers maybe being too restrictive/inflexible for what some users really want. Or rather, it forces us to draw the line on what satpy readers really are. Are they generic readers that provide all the information from the files in a semi-standard way? Or do they provide only the information that is shared between all (most) Satpy readers (the data + common metadata)?

If you ask me, I think we should provide everything that is in the file

Side question: Should the orbit information go in an orbital_parameters sub-dictionary like we do for lon/lat/alt information: https://satpy.readthedocs.io/en/stable/reading.html#orbital-parameters

I think it’s fine like it in now.

@mraspaud
Copy link
Member

@djhoese ok to merge this?

@djhoese djhoese added enhancement code enhancements, features, improvements component:readers labels Mar 21, 2025
Copy link
Member

@djhoese djhoese left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed in slack, could you please move start/end_direction to a new orbital_parameters sub-dictionary. Also copy start/end_orbit to that dictionary too so it'll be in both places for backwards compatibility. I think these 4 keys should be added to the orbital parameters documentation here: https://satpy.readthedocs.io/en/stable/reading.html#orbital-parameters

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component:readers enhancement code enhancements, features, improvements
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants