Forgot to send this to mail list. BTW, I prefer the github issues on the relevant repository, which keeps everything public. ---------- Forwarded message --------- From: John Caron <jcaron1129@xxxxxxxxx> Date: Tue, Jun 28, 2022 at 6:16 PM Subject: Re: [netcdf-java] cordex rotatedpole help To: andrea antonello <andrea.antonello@xxxxxxxxx> 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 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/ >
Attachment:
Screenshot from 2022-06-28 18-11-32.png
Description: PNG image
netcdf-java archives: