-
Notifications
You must be signed in to change notification settings - Fork 303
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
Conversation
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
There was a problem hiding this 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.
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.
Yes, I don't think ABI will benefit from this. |
…em for the SEVIRI HRIT reader.
… SEVIRI native reader.
Looking good so far! any news on this ? |
@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. |
There was a problem hiding this 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.
There was a problem hiding this 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?
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 |
There was a problem hiding this 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.
…t contains private functions not designed for the user to use independently of satpy readers
Good idea, I've renamed this.
True, but that's probably something for a separate PR / issue as it also affects the other (non-GEO) sensors. |
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. |
There was a problem hiding this 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 ;)
satpy/readers/seviri_l1b_hrit.py
Outdated
@@ -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.""" |
There was a problem hiding this comment.
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
@djhoese are you happy with the changes now ? or is the documentation changed still not fully reversed ? |
There was a problem hiding this 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.
There was a problem hiding this 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.
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 #949Code to-do:
Checks to-do:
Tasks:
flake8 satpy