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

Adds a common function for geostationary projection / area definition calculations #952

Merged
merged 33 commits into from
Nov 21, 2019
Merged

Conversation

simonrp84
Copy link
Member

@simonrp84 simonrp84 commented Oct 24, 2019

This PR adds a new common module that computes area extents / defitions for the geostationary satellites and is intended to replace the existing functions in each of the GEO readers, helping to reduce the amount of redundant code.
The calculations in hrit_base are used as a starting point, and this is inspired by issue #949

Code to-do:

  • Base code for module
  • Convert SEVIRI
  • Convert AHI
  • Convert AMI
  • Convert AGRI
  • Convert GOMS

Checks to-do:

  • Check SEVIRI
  • Check AHI
  • Check AMI
  • Check AGRI
  • Check GOMS

Tasks:

@mraspaud mraspaud added component:readers enhancement code enhancements, features, improvements labels Oct 24, 2019
@coveralls
Copy link

coveralls commented Oct 24, 2019

Coverage Status

Coverage increased (+0.1%) to 86.852% when pulling b27a12c on simonrp84:geos_proj into e7c56ca on pytroll:master.

@codecov
Copy link

codecov bot commented Oct 24, 2019

Codecov Report

Merging #952 into master will increase coverage by 0.1%.
The diff coverage is 93.67%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master     #952     +/-   ##
=========================================
+ Coverage   86.75%   86.85%   +0.1%     
=========================================
  Files         179      181      +2     
  Lines       27279    27456    +177     
=========================================
+ Hits        23665    23847    +182     
+ Misses       3614     3609      -5
Impacted Files Coverage Δ
satpy/tests/reader_tests/test_seviri_l1b_hrit.py 98.91% <ø> (-0.04%) ⬇️
satpy/readers/ahi_hsd.py 96.88% <100%> (-0.05%) ⬇️
satpy/readers/seviri_l1b_native.py 67.24% <100%> (+6.17%) ⬆️
satpy/readers/_geos_area.py 100% <100%> (ø)
satpy/tests/reader_tests/__init__.py 98.33% <100%> (+0.02%) ⬆️
satpy/readers/electrol_hrit.py 91.6% <100%> (+0.26%) ⬆️
satpy/readers/agri_l1.py 99.16% <100%> (+0.11%) ⬆️
satpy/readers/ami_l1b.py 97.47% <100%> (+0.15%) ⬆️
satpy/tests/reader_tests/test_ahi_hsd.py 97.82% <100%> (ø) ⬆️
satpy/tests/reader_tests/test_seviri_l1b_native.py 93.33% <100%> (+0.62%) ⬆️
... and 12 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e7c56ca...b27a12c. Read the comment docs.

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.

I'm a little concerned about the get_area_def utility method here. Mainly that to make it generic (to include ABI and AMI) would require the user passing in a and b and h and lon_0 and area name and ...

You end up passing a ton of arguments which makes the code reduction from using this function negligible. There are also special cases like ABI needing the sweep parameter or having special ways of naming things. Maybe the extent calculations should be the only thing that becomes a utility method?

Also note that I put a lot of work in the ABI extent calculations to make the extents nearly the same between all resolutions. So I may not want it to use a generic method.

@simonrp84
Copy link
Member Author

simonrp84 commented Oct 24, 2019

I'm a little concerned about the get_area_def utility method here...you end up passing a ton of arguments which makes the code reduction from using this function negligible.

Agreed, but hopefully the fact that all the computation is will now be done in a single module rather than in each reader will reduce the possibility for calculation errors, as we have all the code in one place.

Also note that I put a lot of work in the ABI extent calculations to make the extents nearly the same between all resolutions. So I may not want it to use a generic method.

Yes, I don't think ABI will benefit from this.

@mraspaud
Copy link
Member

mraspaud commented Nov 5, 2019

Looking good so far! any news on this ?

@simonrp84
Copy link
Member Author

@mraspaud No progress, funding proposal takes first priority! Hope to finish that sometime today and will then be able to work on research / satpy again.

@mraspaud
Copy link
Member

mraspaud commented Nov 5, 2019

No rush! We were just wondering when we would be able to use this feature for the new reader @adybbroe is working on (#886)

@simonrp84 simonrp84 marked this pull request as ready for review November 8, 2019 11:27
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, thanks for doing the tedious work of factorizing and testing for all these geo fileformats!
I have one question regarding AMI (see inline comment), and was wondering if the SAF readers should be using this too, but that could maybe come in a later PR. Looks good otherwise.

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.

Really nice. I had a few things that I'd like changed that I commented on. Otherwise, what are your thoughts on renaming the module to _geos_area.py to make it obvious that this is not a reader and not something normal users should need to look at.

I'm also not really a fan of our (pytroll as a whole) using the function name get_area_definition in multiple places. Is there a better name that we could use?

@djhoese
Copy link
Member

djhoese commented Nov 8, 2019

Oh one more thing, thoughts on keyword arguments versus a dictionary of arguments? Makes it so you can document every single keyword argument. You can still do get_area_extents(**pdict).

Copy link
Member

@sfinkens sfinkens left a comment

Choose a reason for hiding this comment

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

Nice initiative, thanks! This can probably also be used in goes-imager_nc and jma_hrit. Will create an issue for that. Nevertheless I have a few comments and questions.

@simonrp84
Copy link
Member Author

simonrp84 commented Nov 11, 2019

Really nice. I had a few things that I'd like changed that I commented on. Otherwise, what are your thoughts on renaming the module to _geos_area.py to make it obvious that this is not a reader and not something normal users should need to look at.

Good idea, I've renamed this.

I'm also not really a fan of our (pytroll as a whole) using the function name get_area_definition in multiple places. Is there a better name that we could use?

True, but that's probably something for a separate PR / issue as it also affects the other (non-GEO) sensors.

@simonrp84
Copy link
Member Author

Oh one more thing, thoughts on keyword arguments versus a dictionary of arguments? Makes it so you can document every single keyword argument. You can still do get_area_extents(**pdict).

To be honest I don't really have the time to make that change just now (as it'll require quite a bit of rewriting) but if you think it's important then I can keep it in mind for when I have some more spare time.

Copy link
Member

@sfinkens sfinkens left a comment

Choose a reason for hiding this comment

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

Looks good to me, thanks again! Only one tiny nitpick ;)

@@ -221,7 +224,7 @@ class HRITMSGPrologueEpilogueBase(HRITFileHandler):
"""Base reader for prologue and epilogue files."""

def __init__(self, filename, filename_info, filetype_info, hdr_info):
"""Initialize the file handler for prologue and epilogue files."""
"""Initialize the *logue readers."""
Copy link
Member

Choose a reason for hiding this comment

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

This should be reverted, too

@mraspaud
Copy link
Member

@djhoese are you happy with the changes now ? or is the documentation changed still not fully reversed ?

@djhoese
Copy link
Member

djhoese commented Nov 14, 2019

@mraspaud At least for me, GitHub still shows the wrong docstring formatting and @sfinkens is right about the other *logue changes that need to be reverted. We should build sphinx HTML before merging this to make sure the docstrings don't cause any issues.

Copy link
Collaborator

@sjoro sjoro left a comment

Choose a reason for hiding this comment

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

Thank you Simon for this very laborious work! This code clean-up / refactoring is very welcome! I can only comment the code bits dealing with SEVIRI and they look good to me and the unittests pass.

@mraspaud mraspaud requested a review from djhoese November 21, 2019 08:20
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.

Nice work @simonrp84. Looks like the docstring stuff is fixed. Thanks for taking the time to clear that up.

@mraspaud mraspaud merged commit 1fbfda5 into pytroll:master Nov 21, 2019
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.

Make a common function for geostationnary area_extent computation
6 participants