satpy CF Writer does not return CF-compliant CRS encoding for geostationary (and other projections)

[TomLav]

Describe the bug

As per the CF convention, the vast majority of CRS are expected to be stored together with axis coordinate variables with unit of m (meters) and standard_name of projection_x_coordinate (and the pending projection_y_coordinate). At present, satpy's CF Writer uses always m and projection_x_coordinate thus it is correct most of the time.

However, the CF convention has some notable exceptions : the Geostationary and the Rotated Pole projections.

The Rotated Pole projection expects standard_names: grid_latitude and grid_longitude with unit degrees

The Geostationary projection expects standard_names: projection_x_angular_coordinate and projection_y_angular_coordinate with units radians. In that very case (and I believe this is the only case in CF), CF wants us to store coordinates that are not those used by pyproj (pyproj uses meters for the geostationary projection). This means that the satpy CF writer should convert the coordinates it gets from the AreaDefinition object before writing them to the CF file. Here is the pending conversion when reading from a CF file.

Fixing the writer is not difficult in itself. But this "feature" has been in the satpy CF writer for a long time, so we should be careful when fixing it, as user pipelines might fail.

Tagging @ghiggi , @djhoese , @mraspaud as this has been discussed with them in the context of the recent CFWriter refactoring #2524 .

[djhoese]

I think now that pyresample handles both cases when loading an area from a NetCDF file (geostationary in meters and geostationary in radians), it should be less of a pain for backwards compatibility. By that I mean if a user is saving a CF file with Satpy and then loading it with Satpy, it should "just work". That doesn't help users who were using the files outside of Satpy. I also really don't want to make yet another keyword argument to control the projection units. I guess we could have a satpy.config option for it and then eventually deprecate it...eh I don't know.