CDO

hi!
with -remapnn,lon=27.85/lat=0.75 you define a completely new grid, there is not relation to the input grid. Hence CDO (or more precise CDI) use the default names. But yo can use a griddes file like this

#
# gridID 1
#
gridtype  = lonlat
gridsize  = 1
xsize     = 1
ysize     = 1
xname     = x
xlongname = "longitude" 
xunits    = "degrees_east" 
yname     = y
ylongname = "latitude" 
yunits    = "degrees_north" 
xvals     = 2 
yvals     = 44 

with xname and yname you can set the variable names in netcdf output. if you want to keep the names of your input, you can create such a file with the griddes operator from it.

hth
ralf

Thank you Ralf,

Is it possible to put xname/yname in command line?

cdo -s -L -f nc4 -remapnn,X=27.85/Y=0.75 ...
The above does not work ...

nope, sry. nothing like this

I did not mean to use -remapnn. Can we just select an existing grid point at X=27.85/Y=0.75?

you can try sellonlatbox or selindexbox, too

This issue was raised one year ago, and now I have time to continue the work.

When using sellonlatbox, if no grid point is included, then cdo will fail: "Latitudinal or Longitude dimension is too small"

How can we return to the nearest grid?

I dont like the solution: -remapnn,lon=27.85/lat=0.75
1. we have to remap the file
2. we have to specify the grid point. What if we dont have the knowledge?
3. we have to name the longitude and latitude. What if we dont have the knowledge?

Instead, it could be relatively easier for CDO to implement: when CDO finds "Latitudinal or Longitude dimension is too small", it picks up the nearest grid point and use the original names of latitudinal and longitude. Right?

hi!

Jay Su wrote:

This issue was raised one year ago, and now I have time to continue the work.

When using sellonlatbox, if no grid point is included, then cdo will fail: "Latitudinal or Longitude dimension is too small"

How can we return to the nearest grid?

I dont like the solution: -remapnn,lon=27.85/lat=0.75
1. we have to remap the file

it's nearest neighbor, so you get the data value at the nearest location.

2. we have to specify the grid point. What if we dont have the knowledge?

well, what do you know instead? you have to have some knowledge, right?

3. we have to name the longitude and latitude. What if we dont have the knowledge?

so you can select a bigger box and let CDO check, if there is a source location inside.

Instead, it could be relatively easier for CDO to implement: when CDO finds "Latitudinal or Longitude dimension is too small", it picks up the nearest grid point and use the original names of latitudinal and longitude. Right?

I don't like the idea of a fallback like this to be honest: The result of such an error could be any location on earth (depending on the input grid). I'd rather have no result than an unexpected one - sellonlatbox should return someting within that box or nothing. If you don't have enough knowledge about a search, you better work on that knowledge before getting a somewhat random result. There might be good reasons why the knowledge is not available - don't get me wrong. But in this case, there must be another method applied that call a tool with the same input.

you could for example use the non-zero return value of sellonlatbox to enlarge the area you originally covered with the box and run it again.

hth
ralf

Thank you Ralf,

First, I personally agree with your that no result is better than unexpected one. But we embedded cdo in our HTTP service and no result will cause more confusions. Unfortunately we are not able to output the error message to tell users the exact reason.

Second, users just want to subset a file. They dont necessarily have the knowledge of the grids and we are not expecting them to try another bounding box if the first try fails. We developers know the grids, but are hesitating to hard-code the grid information because the same tool is serving many products with totally different grids.

Last, "-remapnn,lon=27.85/lat=0.75" does not remap the dataset then select the grid point, but simply goes to the nearest point, right?

Thanks,
Jay

Jay Su wrote:

Thank you Ralf,

First, I personally agree with your that no result is better than unexpected one. But we embedded cdo in our HTTP service and no result will cause more confusions. Unfortunately we are not able to output the error message to tell users the exact reason.

Second, users just want to subset a file. They dont necessarily have the knowledge of the grids and we are not expecting them to try another bounding box if the first try fails. We developers know the grids, but are hesitating to hard-code the grid information because the same tool is serving many products with totally different grids.

hm, I think since users might select anything they like, some sort of error handling is needed. you don't need the while grid I guess. If your grids are lonlat, you only need to check the user input against min/max of lon and lat.

Last, "-remapnn,lon=27.85/lat=0.75" does not remap the dataset then select the grid point, but simply goes to the nearest point, right?

slighty: it creates a grid with a single point and the given location, and then it searches for the nearest gridpoint in the source grid and takes over this value for the output grid. So the data value is identical to the nearest point in the source but the location is a new one.

Thanks,
Jay

This kind of error handling is exactly what I expect cdo can do for us.

The user input is always within min/max, but the bounding box is so small that no grid point is included.

So we are really doing nearest remapping. I cant provide the result unless users explicitly ask for remapping. Is there any quick way to find the nearest grid point? I found cdo sinfon is pretty fast. Is it the only way I can grab the information then do some calculation?

Thanks,
Jay

Jay Su wrote:

This kind of error handling is exactly what I expect cdo can do for us.

still you would need to return this error to the user, like "Bounding Box is too small"

The user input is always within min/max, but the bounding box is so small that no grid point is included.

So we are really doing nearest remapping. I cant provide the result unless users explicitly ask for remapping. Is there any quick way to find the nearest grid point? I found cdo sinfon is pretty fast. Is it the only way I can grab the information then do some calculation?

in your background script you could

1. call sellonlatbox
2. check its exit code
3. in case its non-zero, you call remapnn with the user-given lon and lat values and return this file with a message to the user, what has happened

Thanks,
Jay