>
> Forgot to send this to mail list. BTW, I prefer the github issues on the
> relevant repository, which keeps everything public.
>
Noted. And I actually would also prefer that. I just wasn't sure what the
policy about this was, since it is kind of an error on the data producer
side.
> it looks like they forgot to add false_easting and false_northing
> parameters.
>
>
> If I use the following ncml to add those:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <netcdf xmlns="http://www.unidata.ucar.edu/namespaces/netcdf/ncml-2.2";
>
> location="03_tas_EUR-11_CNRM-CERFACS-CNRM-CM5_rcp85_r1i1p1_CNRM-ALADIN63_v2_day_20510101-20551231.nc">
>
> <variable name="Lambert_Conformal" >
> <attribute name="false_easting" type="float" value="2800" />
> <attribute name="false_northing" type="float" value="2800" />
> </variable>
>
> </netcdf>
>
> i get the attached image
>
You are right... From my conversions I was also seeing a distortion. But
indeed it seems to just be a shift, same way as for the rotatedpole issues.
Well, I have to admit that I am quite glad about it, since that means that
the projection part is properly handled.
Thanks a ton,
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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 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/
>>
> _______________________________________________
> 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/
>
