Open adybbroe opened 5 years ago
My current position on this is that enhancements, as they are currently, do not work for interactive use...or at least not well. To the new users things magically just look good (default/builtin enhancements). To users who want to change the default enhancement for a product it is relatively impossible.
I think we need to avoid adding any more keyword arguments to existing methods. Enhancements are important enough that they could require a new method on the Scene or a method as an xarray accessor (scn[my_chan].satpy.enhance(...)
).
The other related topic to this is the idea of user "profiles" where all YAML configurations can be grouped in to separate "profiles". So people wanting to produce standard EUMETSAT recipes/enhancements versus SMHI versus SSEC versus NOAA can choose a profile for that configuration.
@djhoese I buy what you are saying, fully, you know the design and code better than I! Concerning the "profiles" I haven't heard that, but sounds adequate, can say something more? Is there another issue for this?
Feature Request
Is your feature request related to a problem? Please describe.
In the case where you have several types of enhancements for the same combinations of bands/channels it is currently necessary to list each one of the composites and enhancements eventhough the recipes in the composite YAML file are identical.
Maybe it would be an idea to have a default enhancement to each composite and the option to specify an optional enhancement when loading and displaying/storeing the RGB!?
Describe the solution you'd like
The user would do something like this then:
scene.load([fire_temperature], enhancement_recipe="awips")
There is probably a better keyword argument name than the one chosen here!
Describe any changes to existing user workflow I think such an implementation doesn't impact any backward compatibility
Additional context