Provided by: gmt_4.5.11-1build1_amd64 bug


       grdblend - Blend several partially over-lapping grids into one large grid


       grdblend          blendfile          -Ggrdfile         -Ixinc[unit][=|+][/yinc[unit][=|+]]
       -Rwest/east/south/north[r] [ -Nnodata ] [ -Q ] [ -Zscale ] [ -V ] [ -W ] [ -fcolinfo ]


       grdblend reads a listing of grid files and blend parameters and creates a binary grid file
       by  blending  the other grids using cosine-taper weights.  grdblend will report if some of
       the nodes are not filled in with data.  Such  unconstrained  nodes  are  set  to  a  value
       specified by the user [Default is NaN].  Nodes with more than one value will be set to the
       weighted average value.  Note: Due to the row-by-row i/o nature of operations in  grdblend
       we only support the netCDF and native binary grid formats for both input and output.

              ASCII file with one record per grid file to include in the blend.  Each record must
              contain three items, separated by spaces or tabs: the gridfile name, the -R-setting
              for  the  interior  region,  and the relative weight wr.  In the combined weighting
              scheme, this grid will be given zero weight outside its domain, weight = wr  inside
              the  interior  region, and a 2-D cosine-tapered weight between those end-members in
              the boundary strip.  However, if a negative wr is given then the sense of  tapering
              is  inverted  (i.e.,  zero  weight  inside its domain).  If the inner region should
              instead exactly match the grid region then specify a - instead of  the  -R-setting.
              If the ASCII file is not given grdblend will read standard input.

       -G     grdfile is the name of the binary output grid file.  (See GRID FILE FORMATS below).
              Only netCDF and native binary grid formats are supported.

       -I     x_inc [and optionally y_inc] is the  grid  spacing.  Optionally,  append  a  suffix
              modifier.   Geographical (degrees) coordinates: Append m to indicate arc minutes or
              c to indicate arc seconds.  If one of the units e, k, i, or n is appended  instead,
              the  increment  is  assumed  to  be  given  in meter, km, miles, or nautical miles,
              respectively, and will be converted to the  equivalent  degrees  longitude  at  the
              middle  latitude of the region (the conversion depends on ELLIPSOID).  If /y_inc is
              given but set to 0 it will be reset equal to x_inc; otherwise it will be  converted
              to  degrees latitude.  All coordinates: If = is appended then the corresponding max
              x (east) or y (north) may be slightly adjusted to fit exactly the  given  increment
              [by  default  the  increment  may  be  adjusted  slightly to fit the given domain].
              Finally, instead of giving an increment you may specify the number of nodes desired
              by appending + to the supplied integer argument; the increment is then recalculated
              from the number of nodes and the domain.  The resulting increment value depends  on
              whether  you  have  selected  a  gridline-registered  or pixel-registered grid; see
              Appendix B for details.  Note: if -Rgrdfile is used then grid spacing  has  already
              been initialized; use -I to override the values.

       -R     xmin, xmax, ymin, and ymax specify the Region of interest.  For geographic regions,
              these limits correspond to west, east, south, and north and you may specify them in
              decimal  degrees  or in [+-]dd:mm[][W|E|S|N] format.  Append r if lower left
              and upper right map coordinates are given instead of w/e/s/n.  The  two  shorthands
              -Rg and -Rd stand for global domain (0/360 and -180/+180 in longitude respectively,
              with -90/+90 in latitude).  Alternatively, specify the name  of  an  existing  grid
              file  and  the  -R  settings  (and grid spacing, if applicable) are copied from the
              grid.  For calendar  time  coordinates  you  may  either  give  (a)  relative  time
              (relative  to  the  selected  TIME_EPOCH and in the selected TIME_UNIT; append t to
              -JX|x), or (b) absolute time of the form [date]T[clock] (append T  to  -JX|x).   At
              least  one  of  date and clock must be present; the T is always required.  The date
              string must be of the form [-]yyyy[-mm[-dd]] (Gregorian calendar) or yyyy[-Www[-d]]
              (ISO  week  calendar),  while  the clock string must be of the form hh:mm:ss[.xxx].
              The use of delimiters and their type and positions must  be  exactly  as  indicated
              (however, input, output and plot formats are customizable; see gmtdefaults).


       -N     No data.  Set nodes with no input grid to this value [Default is NaN].

       -Q     Create  a header-less grid file suitable for use with grdraster.  Requires that the
              output grid file is a native format (i.e., not netCDF).

       -V     Selects verbose mode, which will send progress  reports  to  stderr  [Default  runs

       -W     Do  not  blend,  just  output the weights used for each node.  This option is valid
              when only one input grid is provided [Default makes the blend].

       -Z     Scale output values by scale before writing to file. [1].

       -f     Special formatting of input and/or output  columns  (time  or  geographical  data).
              Specify  i  or  o  to  make  this apply only to input or output [Default applies to
              both].  Give one or more columns (or column ranges) separated by commas.  Append  T
              (absolute calendar time), t (relative time in chosen TIME_UNIT since TIME_EPOCH), x
              (longitude), y (latitude), or f (floating point) to each  column  or  column  range
              item.  Shorthand -f[i|o]g means -f[i|o]0x,1y (geographic coordinates).


       By  default  GMT  writes  out grid as single precision floats in a COARDS-complaint netCDF
       file format.  However, GMT is able to produce grid files in many other commonly used  grid
       file formats and also facilitates so called "packing" of grids, writing out floating point
       data as 2- or 4-byte integers. To specify the precision, scale and offset, the user should
       add  the  suffix =id[/scale/offset[/nan]], where id is a two-letter identifier of the grid
       type and precision, and scale and offset are  optional  scale  factor  and  offset  to  be
       applied  to  all  grid  values,  and  nan is the value used to indicate missing data.  See
       grdreformat(1) and Section 4.17 of the GMT  Technical  Reference  and  Cookbook  for  more

       When  writing  a netCDF file, the grid is stored by default with the variable name "z". To
       specify another variable name varname, append ?varname to the file name.   Note  that  you
       may  need  to escape the special meaning of ? in your shell program by putting a backslash
       in front of it, or by placing the filename and suffix between quotes or double quotes.


       When the output grid  type  is  netCDF,  the  coordinates  will  be  labeled  "longitude",
       "latitude", or "time" based on the attributes of the input data or grid (if any) or on the
       -f or -R options. For example, both -f0x -f1t  and  -R  90w/90e/0t/3t  will  result  in  a
       longitude/time grid. When the x, y, or z coordinate is time, it will be stored in the grid
       as relative time since epoch as specified by TIME_UNIT and TIME_EPOCH in the  .gmtdefaults
       file  or  on  the command line.  In addition, the unit attribute of the time variable will
       indicate both this unit and epoch.


       To create a grid file from the four grid files piece_?.nc, make the blendfile like this     -R<subregion_1> 1     -R<subregion_2> 1     -R<subregion_3> 1     -R<subregion_4> 1

       Then run

       grdblend blend.job -G -R<full_region> -I<dx/dy> -V


       Currently, all grids processed must have the exact same node registration and grid spacing
       as the final output grid.


       GMT(1), grd2xyz(1), grdedit(1) grdraster(1)