NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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: