As for the rotated latlon:
first, thanks Martin for your analysis. i have some notes about that in the
code, but of course have forgotten the details. I will look closely at your
docs sometime and see if theres something to improve on my end.
second, im seeing that the recent 5.x library has some bugs in how it
displays that projection, but your visualization doesnt show those
problems. what software is that from, and what version netcdf-java does it
use?
On Tue, Jun 28, 2022 at 3:10 PM andrea antonello <andrea.antonello@xxxxxxxxx>
wrote:
> 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/
>>>
>> _______________________________________________
> 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/
>
