Prepare for Satpy 1.0

[djhoese]

People at the Pytroll User Days suggested that we release a Satpy 1.0 sooner rather than later. This would help users justify using Satpy in operational settings (ex. "see it's stable"). We currently have a 1.0 milestone:

https://github.com/pytroll/satpy/milestone/7

But I'd like this issue to be a brainstorm/discussion about what else could or should be set for 1.0. On the day of writing this we just had our monthly pytroll meeting and a couple things came up that are backwards compatibility breaking enough that they could go in a 1.0 release:

Enhancement changes

1. Change default enhancement to a linear/null/error function. Suggestions that were brought up in the meeting today was keeping the linear min/max default enhancement for single band data, do a no-op null enhancement for multi-band composites that are uint8, but otherwise raise an error. An alternative to the error could be a warning and then the min/max enhancement. Related: Add image 'mode' as identifying attribute to enhancements #817
2. Change default brightness temperature enhancement: How many people like dark clouds and how many like light clouds? The current default produces dark clouds.
3. Change default reflectance enhancement: The current default was a compromise between me and @mraspaud if I remember correctly. I wanted gamma 2.0 for a square root operation, but I believe Martin (and @pnuu) use a linear stretch (dynamic min/max or static crude?). Is gamma 1.5 really the best default?

What other ideas do people have, not just enhancement changes?

[djhoese]

Another possible breaking change (slightly): #789

[djhoese]

One thing that was discussed in the monthly meeting today that might be good for 1.0 or might be too much, would be restructured or adding to the ability to specify enhancements for different datasets. The overall issue is that mapping what enhancement is used for a particular composite is relatively difficult because of how many YAML files there are and how the enhancements are defined (generic standard_name versus name-specific ones versus all the other ways). Sometimes it might be nice to define the enhancement on the composite itself (full enhancement definition similar to enhancement YAML files) or use a name of an enhancement in the composite definition that points to an enhancement defined in the enhancement YAML files. It was also discussed how the GeoIPS project structures things per-product with information on what data source provides the data, what variable from that data source, how that data is resampled, and what enhancements are applied, all in a single definition.

What the "best" solution is was not really determined, but we pointed out that there are "cons" to all solutions we thought of so far.

Redefining or restructuring all of this and how standard_name is used to connect datasets to their enhancement may be too much for a 1.0 release and may have to wait for a 2.0 release.

[gerritholl]

I've added #52 / #536 (which are pretty much duplicates) to the v1.0 milestone. Some of my colleagues appear somewhat shocked that, in satpy, we can load data with sc.load(["vis_06"], calibration="reflectance"), which is returned with a standard name toa_bidirectional_reflectance, but which is not a reflectance. This problem has been known for more than seven years and should IMO be fixed by the latest with v1.0.

[BENR0]

I would like to have fixes for #2332 and #2331
included. Probably these are not that common of a problem that users stumble about it a lot but I think these are quite serious "bugs" that should somehow be fixed in a v1.0 .

[BENR0]

A quick write up of the possible road map regarding the improvement of the reflectance calibration issue according to a discussion with @mraspaud and @gerritholl on the last day of the PCW.

1. Agree on name for new calibration -> Slack Poll (@mraspaud)
2. Check all readers what calibration and modification is done by default and in accordance with what is done include a deprecation warning that in the future this is going to change what is actually returned by requesting reflectance calibration.
3. Come up with a documentation for developers listing the steps for migrating readers to the "new calibration".
4. Possibly release a v1.0 even though not all readers a migrated.

[gerritholl]

2. Change default brightness temperature enhancement: How many people like dark clouds and how many like light clouds? The current default produces dark clouds

This is sufficiently controversial to needs its own issue.