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

Add reader for LSA-SAF data #2529

Draft
wants to merge 8 commits into
base: main
Choose a base branch
from
Draft

Conversation

simonrp84
Copy link
Member

This PR adds a reader for data produced by EUMETSAT's LSA-SAF. Right now, it only supports land surface temperature files but I plan to add additional ones soon.
Tests need to be added as well, but I wanted to make a PR so gain some feedback on the way I've coded this before I do the testing for it.

  • Tests added
  • Fully documented

@codecov
Copy link

codecov bot commented Jul 17, 2023

Codecov Report

Merging #2529 (684af00) into main (8490966) will decrease coverage by 0.20%.
The diff coverage is 24.40%.

@@            Coverage Diff             @@
##             main    #2529      +/-   ##
==========================================
- Coverage   94.89%   94.69%   -0.20%     
==========================================
  Files         349      350       +1     
  Lines       50859    50986     +127     
==========================================
+ Hits        48263    48283      +20     
- Misses       2596     2703     +107     
Flag Coverage Δ
behaviourtests 4.31% <0.00%> (-0.02%) ⬇️
unittests 95.30% <24.40%> (-0.21%) ⬇️

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

Impacted Files Coverage Δ
satpy/readers/lsasaf_h5.py 24.40% <24.40%> (ø)

... and 3 files with indirect coverage changes

@simonrp84
Copy link
Member Author

pre-commit.ci autofix

@simonrp84
Copy link
Member Author

Kinda curious that there pre-commit.ci shows failures, I ran the pre-commit checks locally before pushing!

@coveralls
Copy link

Pull Request Test Coverage Report for Build 5574764301

  • 31 of 127 (24.41%) changed or added relevant lines in 1 file are covered.
  • 11 unchanged lines in 3 files lost coverage.
  • Overall coverage decreased (-0.2%) to 95.251%

Changes Missing Coverage Covered Lines Changed/Added Lines %
satpy/readers/lsasaf_h5.py 31 127 24.41%
Files with Coverage Reduction New Missed Lines %
satpy/tests/reader_tests/gms/test_gms5_vissr_l1b.py 3 98.67%
satpy/tests/reader_tests/gms/test_gms5_vissr_navigation.py 3 97.16%
satpy/tests/reader_tests/utils.py 5 84.85%
Totals Coverage Status
Change from base Build 5488743163: -0.2%
Covered Lines: 48396
Relevant Lines: 50809

💛 - Coveralls

@@ -0,0 +1,44 @@
reader:
name: lsasaf-geo
Copy link
Member

Choose a reason for hiding this comment

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

Is the name of the software "LSASAF GEO"? If not, then I'd say an underscore in the reader name would be more consistent. Or even "lsasaf" if there is no LEO version.

Comment on lines +179 to +194
@staticmethod
def _ensure_crs_extents_in_meters(crs, area_extent):
"""Fix units in Earth shape, satellite altitude and 'units' attribute."""
if 'kilo' in crs.axis_info[0].unit_name:
proj_dict = crs.to_dict()
proj_dict["units"] = "m"
if "a" in proj_dict:
proj_dict["a"] *= 1000.
if "b" in proj_dict:
proj_dict["b"] *= 1000.
if "R" in proj_dict:
proj_dict["R"] *= 1000.
proj_dict["h"] *= 1000.
area_extent = tuple([val * 1000. for val in area_extent])
crs = CRS.from_dict(proj_dict)
return crs, area_extent
Copy link
Member

Choose a reason for hiding this comment

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

Unused method? If not, I'm tempted to say we should just deal with the projection in kilometers if possible.

Comment on lines +79 to +81
if dsid_name in self.cache:
logger.debug('Get the data set from cache: %s.', dsid_name)
return self.cache[dsid_name]
Copy link
Member

Choose a reason for hiding this comment

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

  1. Is the cache ever actually written to?
  2. If it was, would it really provide a performance improvement?
  3. In what cases is the same file handler asked for the same DataArray multiple times?

Comment on lines +651 to +655
land_surface_temperature:
compositor: !!python/name:satpy.composites.SingleBandCompositor
prerequisites:
- name: 'lst'
standard_name: land_surface_temperature
Copy link
Member

Choose a reason for hiding this comment

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

I'm tempted to say this shouldn't be in visir yet. I'm also tempted to say this compositor should not exist...could you add the standard_name in the reader YAML and/or reader python code? Then this composite doesn't conflict with other readers who already have a product called "land_surface_temperature", but your enhancement based on standard_name would still be found.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants