Hi, a short update on my findings.
Martin, I do not think my problem is the one you are investigating. I
noticed that in the case 02 (Africa) of the linked datasets there is a
shift by 180 degrees.
Setting the longitude properly turns into proper results. But I didn't yet
find a way to understand when that is the case. If anyone with experience
could identify the reason, that would be great.
Now I also found another meteo dataset in LambertConformal that also
doesn't behave right. Since also Panolpy and ncWMS do not place the dataset
properly (it is shifted, scaled and rotated), I assume it is again
something with the dataset, else the projToLatLon should calculate the
result properly. Maybe a gentle soul can see something I do not in the
dataset's metadata: https://we.tl/t-ui4CZmQ0pS
Cheers,
Andrea
On Wed, Jun 22, 2022 at 8:12 AM andrea antonello <andrea.antonello@xxxxxxxxx>
wrote:
> 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/
>>
>
