>
> 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?
>
I am not sure if you mean my two images from the previous mail (I didn't
see any from Martin), so I will answer to that.
I am using the netcdf-java libraries to read, extract and reproject the
netcdf. Then I pipe the resulting grid through the geotools libraries to
create a geotiff.
The image then is from that tif loaded into QGIS over an openstreetmap
background in lat/long (epsg:4326).
The software is completely open, so it could be looked at, if necessary.
I was using 4.6.15, since that is what is currently used by geotools. But I
also tried to use the 5.5.3 release (thanks for being so well backwards
compatible) and the results on these datasets are exactly the same for the
two versions.
Thanks,
Andrea
>
> 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
>>>>>
>>>>>
