File remapping with wrong grid definition
Added by Fabrizio Amoruso over 1 year ago
Hallo everybody,
First of all I wanted to clarify that this problem has been solved in its own way, but I am looking for alternative solutions . I also searched for similar requests in this forum and stack overflow, but could not find one that exactly matches the issue encountered in this occasion. If there are already, it is probably my fault and I apologize.
I am asking alternative solutions because in case there were none I would need to provide feedback to the ECMWF for a faulty datafile being uploaded in COPERNICUS, but I am sure there is a resolution I am not aware of.
Problem description: a LAEA-gridded file could not be remapped using, e.g., cdo remapcon,r7200x3600 in.nc out.nc because the LAEA grid definition was incomplete (file is attached, monthly data file for April named APR_v1.nc; this is just a sample of a larger dataset of monthly data with the same recurring issue). The usual error message of "generic grid" applies here, of which many solutions can be found using ncatted, but this is not one of those cases.
Solution description : I had to use another LAEA-gridded file, export its grid with cdo griddes ref_file.nc > grid.txt and modify the existing faulty grid by copy-pasting missing information. You can find both "faulty" grid and correction grid attached. (faulty grid: grid.txt; correction: grid1.txt). Missing information were the grid type ("generic" instead of "projection") and the entire definition of the LAEA coordinates' system.
This problem has been solved because I had another similar file available, which came from a different project. However, how would one solve the issue without recurring to copypasting the correct information in the original file and regridding is unknown to me. The problem might arise from the fact that the original file contains both lat/lon Geo2D coordinates, as well as x/y projection coordinates.
Thanks for any help you could provide.
Replies (5)
RE: File remapping with wrong grid definition - Added by Karin Meier-Fleischer over 1 year ago
Hi Fabrizio,
there are two problems, one can be solved easily but not the other one. The coordinates attribute is missing for the data variables, it can be set with CDO's settattribute or NCO's ncatted.
E.g.
ncatted -O -a coordinates,ref_var_threshold,c,c,"lat lon" \
-a coordinates,relative_change,c,c,"lat lon" \
APR_v1.nc APR_v1_new.nc
The variables lon and lat contains missing values which is not allowed following the CF-convention IMO.
ncdump -v lon APR_v1.nc
...
data:
lon =
_, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _,
_, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _,
...
RE: File remapping with wrong grid definition - Added by Fabrizio Amoruso over 1 year ago
Hallo Karin,
Thanks for your reply, which seems to solve the problem using ncatted attribute association to coordinates. I expected this not to be the main issue, but it might solve the problem.
However, when implementing your solution and attempting to remap the LAEA-gridded file using remapcon, it outputs the following error message:
cdo remapcon (Abort): Source grid cell corner coordinates missing!
and aborts.
Using remapbil,r7200x3600 for higher resolution:
cdo remapbil (Warning): Source grid cell center longitudes out of range (min=-33.9/max=9.97e+36)!
cdo remapbil (Warning): Source grid cell center latitudes out of range (min=29.6/max=9.97e+36)!
Which, I suppose, is the result of attempting to remap a file presuming it is gridded using a different standard than the existing one.
Notably, remapbil outputs a working file that can be read using e.g. Panoply, while remapcon aborts the operation. Clearly, the resolution of the issue depends on the remapping algorithms.
As a matter of fact, when replacing the definition of the grid with a correct LAEA gridfile extracted from another file, it all works just fine.
What I am not really sure about is the cause of the problem with rempacon. Is this related to the issue pointed out in your reply, or is it caused by the remapping functions? I assume it is the second.
Many thanks again.
RE: File remapping with wrong grid definition - Added by Uwe Schulzweida over 1 year ago
The lon/lat coordinates contains missing values. It will work, if you select the area with valid coordinates:
ncatted -O -a coordinates,ref_var_threshold,c,c,"lat lon" -a coordinates,relative_change,c,c,"lat lon" APR_v1.nc APR_v1_new.nc cdo remapbil,r7200x3600 -selindexbox,1,1000,19,816 APR_v1_new.nc result.nc
RE: File remapping with wrong grid definition - Added by Uwe Schulzweida over 1 year ago
An alternativ solution is to ignore the present lon/lat coordinates. In this case CDO will recompute the coordinates from the projection parameter and you can also use remapcon:
ncatted -O -a grid_mapping,ref_var_threshold,c,c,"lambert_azimuthal_equal_area" \
-a grid_mapping,relative_change,c,c,"lambert_azimuthal_equal_area" \
-a grid_mapping,lon,c,c,"lambert_azimuthal_equal_area" \
-a grid_mapping,lat,c,c,"lambert_azimuthal_equal_area" \
-a _FillValue,lambert_azimuthal_equal_area,d,, APR_v1.nc APR_v1_new.nc
cdo remapbil,r7200x3600 APR_v1_new.nc result.nc
RE: File remapping with wrong grid definition - Added by Fabrizio Amoruso over 1 year ago
Hallo Uwe,
Many thanks for providing this very interesting solution to a problem that appears to recur also in other datasets on COPERNICUS.
My knowledge of nco/cdo was probably too limited to come to this very important part of the solution:
-a _FillValue,lambert_azimuthal_equal_area,d,, APR_v1.nc APR_v1_new.nc
Many thanks again!