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.
>
> 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
>>>>>
>>>>>
netcdf-java archives: