Feature #552


Added by Mark over 7 years ago. Updated about 7 years ago.

Status:ClosedStart date:2014-04-24
Priority:NormalDue date:
Assignee:Paul% Done:


Target version:Candidate for next bugfix release


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.

FiordlandBlended_ll.nc (1.4 MB) Mark, 2014-04-24 15:57

FiordlandBlended_xy.nc (1.47 MB) Mark, 2014-04-24 15:57

FiordlandBlended_ll.ps (1.98 MB) Mark, 2014-04-24 16:43

grdcut_test.sh Magnifier (334 Bytes) Mark, 2014-04-24 16:43

FiordlandBlended_xy.ps (1.98 MB) Mark, 2014-04-24 16:43


#1 Updated by Paul over 7 years ago

  • Status changed from New to Resolved

It may be simpler to just cut the grid as needed with grdcut -Zn; we would have to do the same kind of calculation inside grdproject so might as well use grdcut.

#2 Updated by Mark over 7 years ago

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.

grdcut: Processing input grid
grdcut: Your -Z limits produced no subset - output grid is identical to input grid
grdcut: File spec: W E S N dx dy nx ny:
grdcut: Old:grdcut: -72.3673124116 72.3673124116 -72.6275425253 72.2251788385 0.167516926879 0.232135771416 865 625
grdcut: New:grdcut: -72.3673124116 72.3673124116 -72.6275425253 72.2251788385 0.167516926879 0.232135771416 865 625

#3 Updated by Paul over 7 years ago

  • Target version set to Candidate for next bugfix release

I see. Needed to add a third flavor via -Zr here (NaN considered to be within z range). So now -Zn gives what you want. In r13089.

#4 Updated by Remko over 7 years ago

  • Status changed from Resolved to Feedback

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.

              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 not also 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:
  1. All nodes inside the new region are also inside the z-range (this appear to be what -Zn does now)
  2. All nodes outside the new region are also outside the z-range (this appears to be what -Z or -Zr do now)

This is independent of how to deal with NaNs.

#5 Updated by Paul over 7 years ago

OK, I agree with stripping the side with most NaNs, then repeat until no NaNs. Will have a look.

#6 Updated by Paul over 7 years ago

  • Status changed from Feedback to In Progress

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.

#7 Updated by Paul over 7 years ago

  • Status changed from In Progress to Resolved
  • Assignee set to Paul
  • % Done changed from 0 to 100

I believe this one is fixed. I added two new test scripts in test/grdcut (shrink.sh and cut.sh) and both work.

#8 Updated by Paul about 7 years ago

  • Status changed from Resolved to Closed

Closing this for now; test scripts work as intended.

Also available in: Atom PDF