Hello Andrea :-)
I did an analysis of "Rotated Pole" implementations in UCAR library and
PROJ a few months ago for trying to reverse engineering their
mathematical definitions. It was an attempt (still in progress) to get a
formal definition of this operation method in a way similar than what
EPSG does. My current understanding of the situation is documented there:
https://github.com/opengeospatial/MetOceanDWG/blob/main/MetOceanDWG%20Projects/Authority%20Codes%20for%20CRS/Pole%20rotation.md
In summary, while CF-convention cites only one pole rotation method
(namely "rotated_latitude_longitude"), the UCAR netCDF library has two
implementations: the above cited one and "rotated_latlon_grib". The
source code of those two implementations look totally different, but
they are really the same thing computed in different ways. The major
difference is that "rotated_latitude_longitude" rotates the /North/ pole
while "rotated_latlon_grib" rotates the /South/ pole. Rotating the wrong
pole causes an error of 180° in longitude and 90° - φ (or something like
that, I do not remember exactly) in latitude, which looks like what you
are observing with Africa. The method defined by CF-Convention rotates
the North pole, while the method defined by World Meteorological
Organization (WMO) used in GRIB files rotates the South pole.
Note: looking at the math, it appears that we do not need two distinct
implementations for the North pole and South pole cases. We can use the
South pole rotation (the one defined by WMO) as the fundamental
definition, and express the Norh pole case (the one defined by
CF-Conventions) with a transformation applied on the input parameters
before to delegate to the formulas of the South pole case. The above
link gives examples for testing the same coordinate operations with
UCAR, PROJ and Apache SIS libraries.
Martin
