You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The list of standardized area definitions in areas.yaml is growing, with e.g. different resolutions, operating modes and sub-satellite points. Currently 36 standardized area definitions are hard coded in areas.yaml, with quite a bit of duplicate information.
This also allows for limited flexibility. A recent example is the change in sub-satellite point of the MSG SEVIRI IODC service from 41.5E to 45.5E. An easy solution would be to just change the lon_0 in the IODC-related area definitions. This would however lead to errors if users use this for older data for which the lon_0 is still 41.5E, for which the sub-satellite point was still 41.5E. Of course these is also the possibility to add a new set of (five) area definitions for the IODC service at this new longitude. But that's what I would like to avoid.
Describe the solution you'd like
An extended or new helper function that compute/construct the area definitions dynamically when called, instead of just looking for hard coded entries in areas.yaml.
Example Code
Below is a small prototype of the proposed helper function together with a dictionary containing all information currently used for the 36 standardized SEVIRI, FCI and ABI area definitions.
Describe any changes to existing user workflow
Either this helper function could be used stand-alone. Or, if possible, it could be integrated in satpy.resample.get_area_def with the following workflow:
satpy.resample import get_area_def
adef = get_area_def(area_id)
if adef is None: # No area definition with that name found in areas.yaml
check if area_id matches an expected pre-defined format
chop up area_id into platform, instrument, service, resolution and sub-satellite point longitude assuming a pre-defined format
adef = new_helper_function(platform, instrument, service, resolution, lon_0)
The text was updated successfully, but these errors were encountered:
As discussed in the meeting today, here are some options that might be good ideas:
Auto-generate the YAML file with some utility script. We get the benefit of python for-loops and shared information (ex. extents that are the same between multiple areas) while still having YAML that can be saved in git, linked to on github (for user support/questions), and other tools can use the YAML directly instead of having to use dynamically created areas (ex. a page on the sphinx docs which lists the areas and shows the user a boundary).
A utility function that takes the information the user knows (satellite, instrument, resolution, etc) and finds the best area of the satpy builtin "standard" areas that matches that description. Or perhaps this function returns a list of possible ones.
A utility function that lists all the names of the areas in the builtin Satpy areas file. Could be the same function as described above, but with no additional parameters specified.
Refactor area loading in Satpy and/or pyresample to load from multiple files where YAML files are separated based on some property (satellite or instrument or something else).
Also discussed was the possibility of using YAML aliases to reuse information across multiple definitions. This makes things harder to read but means that things that are easy to mistype aren't duplicated (ex. area extents).
I also brought up the possibility of adding something to satpy's pre-commit config to detect changes in the auto-generate python script and then run it to generate the YAML on commit. This way the YAML should never be out of sync with the script.
Feature Request
Is your feature request related to a problem? Please describe.
The list of standardized area definitions in
areas.yaml
is growing, with e.g. different resolutions, operating modes and sub-satellite points. Currently 36 standardized area definitions are hard coded inareas.yaml
, with quite a bit of duplicate information.This also allows for limited flexibility. A recent example is the change in sub-satellite point of the MSG SEVIRI IODC service from 41.5E to 45.5E. An easy solution would be to just change the
lon_0
in the IODC-related area definitions. This would however lead to errors if users use this for older data for which thelon_0
is still 41.5E, for which the sub-satellite point was still 41.5E. Of course these is also the possibility to add a new set of (five) area definitions for the IODC service at this new longitude. But that's what I would like to avoid.Describe the solution you'd like
An extended or new helper function that compute/construct the area definitions dynamically when called, instead of just looking for hard coded entries in
areas.yaml
.Example Code
Below is a small prototype of the proposed helper function together with a dictionary containing all information currently used for the 36 standardized SEVIRI, FCI and ABI area definitions.
Describe any changes to existing user workflow
Either this helper function could be used stand-alone. Or, if possible, it could be integrated in
satpy.resample.get_area_def
with the following workflow:The text was updated successfully, but these errors were encountered: