Right now, grdproject returns a grid that fills the rectangle that fully encloses the projected locations of the nodes for the incoming grid. This means that the perimeter region will often have nans, because of the mismatch between the incoming rectangular grid and outgoing rectangular grid. Often I need a fully populate grid (i.e., with no nans). Would it be possible to add to grdproject the options either a minimum enclosing rectangle or a maximum enclosed rectangle for the output grid. The maximum enclosed rectangle would lie entirely within the projected limits of the input grid.

The reason that I ask is that at present, we have to use mapproject to find the easting,northing values for the corners and then to select a maximum enclosed rectangle. Then we have to project those easting and northing values back to lon, lat values to get the -R values for grdproject. I can live with this, but I thought it would not hurt to ask.

Thanks for the tip. I had no idea that grdcut could trim on the basis of nans. I agree, that this feature would solve the issue that I described. I tried this idea with the grid that I am working with, but grdcut -Zn did not recognize nans at the perimeter of the grid. The attached shell file and grid files illustrate the problem. You will see that grdcut -Zn pass the grid along with no changes (see verbose output below). The postscript image of the projected grid clearly shows the regions with nans as white sliver shaped arears on the lower left and lower right sides of the image.

I cannot really agree with the implementation of grdcut -Zn (nor probably of -Zr, but haven't looked at that).The example above FiordlandBlended_xy.nc has only strips of NaNs on the left and right side. Yet the top and bottom side are cut off, even though there are hardly any NaNs there.The algorithm should cut (one at the time) the edge that has the most NaNs. In this case the left and right edge would be cut off one after the other, leaving top and bottom in tact.

Also the explanation in the manual is very unclear, and likely wrong.

-Z[n|r]min/max
Determine the new rectangular region so that all nodes outside this region are also outside the given z-range [-inf/+inf]. To
indicate no limit on min or max, specify a hyphen (-). Normally, any NaNs encountered are simply skipped. Use -Zn to consider
a NaN to be outside the z-range so resulting grid is NaN-free, or -Zr to consider NaNs to be within the data range [Default
simply skips NaNs when making the range decision.

Clear in this case a lot of points are regarded outside that are notalso outside the given z-range. So that description is wrong. In this case the nodes inside the new rectangular region are all within the z-range. That is not the same as that all points outside the rectangular region are all outside the given z-range.

I also do not understand why the way the search is conducted depends on whether -Zr or -Zn is used. According to the man page the only difference is the -Zr considers NaN inside the z-range (always) and -Zn considers them outside the z-range. This should only distinguish how to deal with NaNs within the search, not the way the search is conducted.

What you might want to include though is whether you want to create a region where:

All nodes inside the new region are also inside the z-range (this appear to be what -Zn does now)

All nodes outside the new region are also outside the z-range (this appears to be what -Z or -Zr do now)

OK, redid how -Zn worked. Much simpler actually, just keeping track of how many nans along each boundary side and then move the max nan side inwards until no more NaNs. Also fixed some errors in -Zr, and improved the docs. Basically, -Z without n|r simply searches inwards until the boundary rows/cols each has a value within the range. Using -Zr simply consider NaN a value within the range, so finding a NaN stops the inward search. Finally -Zn continues the inward search until no Nans are present. In 13242.