Hi Andrea:
Attached is what i see
for
03_tas_EUR-11_CNRM-CERFACS-CNRM-CM5_rcp85_r1i1p1_CNRM-ALADIN63_v2_day_20510101-20551231.nc.
the lower left is (0,0) at 50N, 10E, which is what id expect for
LambertConformal{earth_radius=6371.229, par1=49.5, par2=49.5,
falseEasting=0.0, falseNorthing=0.0, lon0Degrees=10.5}}
For this and/or the rotated pole problems, do you know what it should
look like, for example, what the lat/lon corners of the grid are supposed
to be? I might be able to reverse engineer that.
regards, John
On Mon, Jun 27, 2022 at 3:31 AM andrea antonello <andrea.antonello@xxxxxxxxx>
wrote:
> 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/
>>>
>> _______________________________________________
> 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/
>
Attachment:
Screenshot from 2022-06-28 10-44-05.png
Description: PNG image
netcdf-java archives: