Hallo Martin,
nice to hear from you :-)
> 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.
>
that is interesting. You think that is the reason? From the findings in the
mentioned ncWMS issue, it seems that renaming some variables can lead to
proper results (with ncWMS), but when I do that, I am not even able to
properly handle the projection object (which changes in that case, need to
investigate more).
Did you find a solution to tweak this projection issue using just the
netcdf-java libraries?
Thank you,
Andrea
> Martin
>
>
> _______________________________________________
> NOTE: All exchanges posted to Unidata maintained email lists are
> recorded in the Unidata inquiry tracking system and made publicly
> available through the web. Users who post to any of the lists we
> maintain are reminded to remove any personal information that they
> do not want to be made public.
>
>
> netcdf-java mailing list
> netcdf-java@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> https://www.unidata.ucar.edu/mailing_lists/
>
