Hi John,
thanks for your reply.
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.
>
For the LambertConformal I haven't yet found a way to fix it or any tool
that would display the data properly. As you can see in your modified
image, there is quite some shift:
[image: lambertconformal_shift.png]
But I will try to find a way to define the coordinates and send them in.
Instead, regarding
the
02_tas_AFR-22_CCCma-CanESM2_rcp85_r1i1p1_CCCma-CanRCM4_r2_day_20510101-20551231.nc
rotated pole, this is what I read with the libs:
Proj X Axis (rlon): -24.75 -> 60.3900146484375 (388) extent:
85.1400146484375
Proj Y Axis (rlat): -45.869998931884766 -> 42.35000228881836 (402)
extent: 88.22000122070312
Time Axis (time): 2051-01-01T12:00:00Z -> 2055-12-31T12:00:00Z (1825)
Longitude: -179.88999938964847 -> 179.8900146484375 extent:
359.78001403808594
Latitude: -45.869998931884766 -> 42.35000228881836 extent:
88.22000122070312
resulting in:
[image: image.png]
while the right extents are these:
Longitude: -24.75 -> 60.390014648437486 extent: 85.14001464843749
Latitude: -45.869998931884766 -> 42.35000228881836 extent:
88.22000122070312
[image: image.png]
Thank you,
cheers,
Andrea
>
> 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/
>>
>
