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
Harmonise AreaDefinition namings in EUM geos readers and sort geos areas in areas.yaml #1485
Harmonise AreaDefinition namings in EUM geos readers and sort geos areas in areas.yaml #1485
Conversation
…sary proj_id and description from test dicts
Codecov Report
@@ Coverage Diff @@
## master #1485 +/- ##
=======================================
Coverage 90.87% 90.88%
=======================================
Files 241 241
Lines 35113 35173 +60
=======================================
+ Hits 31908 31966 +58
- Misses 3205 3207 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
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.
Wow, so many changes. Nice job. Had a few small style questions and comments.
satpy/etc/areas.yaml
Outdated
@@ -1,3 +1,212 @@ | |||
# This file contains a set of pre-defined areas to be used for resampling purposes. | |||
|
|||
# ---------------------------------------------------------------------------------------------------------------------- |
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.
Thoughts on an 80 character limit for this file? There are ways in YAML to make multiline strings if we need to (for the area "description" if those get long.
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 have no opinion on this, so as you wish.
I guess we could go with:
description: >-
MSG SEVIRI Full Earth Scanning service
area definition with 3 km resolution
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.
Yeah I just noticed that it was hard to read all the section headers because of how long they were. Could have been my browser window width or GitHub imposing a character/column limit.
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.
Done! Noticed that simply splitting the lines without the >-
works the same (folding with a space, no end newline).
lower_left_xy: [-4823148.089050828, 1969764.6783588605] | ||
upper_right_xy: [4178061.408400173, 5570248.477339261] | ||
|
||
EastEurope: |
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.
Is this an area that existed before? If so, did it have the same name? Regardless, EastEurope, EuropeCanary, and SouthAmerica are pretty generic names for geostationary specific areas. Obviously, whatever amount of South America SEVIRI sees in its geostationary full disk isn't going to be the best for other datasets that are more "central" to South America.
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.
Ah I see now that these were old areas. Did we decide we'd come up with better names for these in a later PR?
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.
Yeah, those are all old areas. And yes, I think another PR is needed for the general cleanup/renaming, and possibly adding a deprecation warning. For now, I relegated to deprecation only the old full-disk ones.
# ---------------------------------------------------------------------------------------------------------------------- | ||
# ------------------------------------------------ Areas to be deprecated ---------------------------------------------- | ||
# ---------------------------------------------------------------------------------------------------------------------- | ||
# This section contains areas that are obsolete. |
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.
Is it possible for satpy to issue a warning when someone uses an obsolete area name?
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.
Not currently, but I think we could add it. The cases where someone does new_scn = scn.resample('obsolete_area')
would be very easy to handle. The cases where someone is manually specifying a path to the areas.yaml file and requesting it might be harder since there are a few utilities doing that and most are in pyresample which doesn't know or care about the areas defined in satpy.
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 guess yes, e.g. a check for deprecated areas could be placed in satpy.resample.get_area_def()
, which is what is used to get the destination AreaDefinition out of the yaml when resampling... TBD in #819
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.
Good work! Just one request: Since we discovered during the PCW that the SEVIRI Native area extent is slightly different from msg_seviri_fes_1/3km
, I think it would be nice to mention that in NativeMSGFileHandler.get_area_def
.
@sfinkens Thanks! Good idea, I added a notice in the native and netcdf 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.
LGTM. thanks for sorting this out and also for fixing the documentation weblinks!
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 like the changes in the seviri nc reader aren't covered, otherwise LGTM
Oh, also, proj_id should really be deprecated, so should we just set it to an empty value here instead? |
@mraspaud I was wondering the same about the Regarding the NetCDF tests: yes the changes are not covered, because there's almost no test at all for the NetCDF reader. So I figured I would leave it for now, planning to add comprehensive tests in another dedicated PR. Is it ok? |
I'm ok with leaving the nc part uncovered for now. |
Note that the AreaDefinition area extents returned by this function for Native data will be slightly | ||
different compared to the area extents returned by the SEVIRI HRIT reader. | ||
This is due to slightly different pixel size values when calculated using the data available in the files. E.g. | ||
for the 3 km grid: | ||
|
||
``Native: data15hd['ImageDescription']['ReferenceGridVIS_IR']['ColumnDirGridStep'] == 3000.4031658172607`` | ||
``HRIT: np.deg2rad(2.**16 / pdict['lfac']) * pdict['h'] == 3000.4032785810186`` | ||
|
||
This results in the Native 3 km full-disk area extents being approx. 20 cm shorter in each direction. | ||
|
||
The method for calculating the area extents used by the HRIT reader (CFAC/LFAC mechanism) keeps the | ||
highest level of numeric precision and is used as reference by EUM. For this reason, the standard area | ||
definitions defined in the `areas.yaml` file correspond to the HRIT ones. | ||
|
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.
Excellent, thanks!
Conflicts: satpy/readers/seviri_base.py satpy/readers/seviri_l1b_hrit.py satpy/readers/seviri_l1b_native.py satpy/readers/seviri_l1b_nc.py
@mraspaud added a commit that replaces all |
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 all for your help and discussions! |
This PR contributes to #1248 by standardizing the way AreaDefinition's
area_id
,description
andproj_id
are returned in geostationary data readers of EUMETSAT data (L1 SEVIRI and FCI).It follows the convention
<platform>_<instrument>_<service>_<resolution>
for thearea_id
. A generic formatting functionget_geos_area_naming
is implemented in_geos_area
.New standard areas for SEVIRI and FCI are added to
areas.yaml
.It also starts the work on #819 by sorting the geostationary areas.
Changes "globe" to "disk" in area descriptions to close #1187.
flake8 satpy