Provided by: gmt-common_5.2.1+dfsg-3build1_all 
NAME
sphdistance - Make Voronoi distance, node, or nearest-neighbor grid on a sphere
SYNOPSIS
sphdistance [ table ] grdfile [ ] [ d|n|z[dist] ] [ increment ] [ unit ] [ nodetable ] [
voronoi.txt ] [ region ] [ [level] ] [ -b<binary> ] [ -d<nodata> ] [ -h<headers> ] [
-i<flags> ] [ -r ] [ -:[i|o] ]
Note: No space is allowed between the option flag and the associated arguments.
DESCRIPTION
sphdistance reads one or more ASCII [or binary] files (or standard input) containing lon,
lat and performs the construction of Voronoi polygons. These polygons are then processed
to calculate the nearest distance to each node of the lattice and written to the specified
grid. The Voronoi algorithm used is STRIPACK. As an option, you may provide
pre-calculated Voronoi polygon file in the format written by sphtriangulate, thus
bypassing the memory- and time-consuming triangularization.
REQUIRED ARGUMENTS
-Ggrdfile
Name of the output grid to hold the computed distances.
OPTIONAL ARGUMENTS
table One or more ASCII (or binary, see -bi[ncols][type]) data table file(s) holding a
number of data columns. If no tables are given then we read from standard input.
-C For large data sets you can save some memory (at the expense of more processing) by
only storing one form of location coordinates (geographic or Cartesian 3-D vectors)
at any given time, translating from one form to the other when necessary [Default
keeps both arrays in memory]. Not applicable with -Q.
-Ed|n|z[dist]
Specify the quantity that should be assigned to the grid nodes. By default we
compute distances to the nearest data point [-Ed]. Use -En to assign the ID
numbers of the Voronoi polygons that each grid node is inside, or use -Ez for a
nearest-neighbor grid where we assign all nodes inside the polygon the z-value of
the center node. Optionally, append the resampling interval along Voronoi arcs in
spherical degrees [1].
-Ixinc[unit][=|+][/yinc[unit][=|+]]
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 s
to indicate arc seconds. If one of the units e, f, k, M, n or u is appended
instead, the increment is assumed to be given in meter, foot, km, Mile, nautical
mile or US survey foot, respectively, and will be converted to the equivalent
degrees longitude at the middle latitude of the region (the conversion depends on
PROJ_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 App-file-formats for details.
Note: if -Rgrdfile is used then the grid spacing has already been initialized; use
-I to override the values.
-Lunit Specify the unit used for distance calculations. Choose among d (spherical degree),
e (m), f (feet), k (km), M (mile), n (nautical mile) or u survey foot. A spherical
approximation is used unless PROJ_ELLIPSOID is set to an actual ellipsoid.
-Nnodetable
Read the information pertaining to each Voronoi polygon (the unique node lon, lat
and polygon area) from a separate file [Default acquires this information from the
ASCII segment headers of the output file]. Required if binary input via -Q is used.
-Qvoronoi.txt
Append the name of a file with pre-calculated Voronoi polygons [Default performs
the Voronoi construction on input data]. For binary data -bi you must specify the
node information separately (via -N).
-R[unit]west/east/south/north[/zmin/zmax][r]
west, east, south, and north specify the region of interest, and you may specify
them in decimal degrees or in [+-]dd:mm[:ss.xxx][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 for grid creation, give
Rcodelon/lat/nx/ny, where code is a 2-character combination of L, C, R (for left,
center, or right) and T, M, B for top, middle, or bottom. e.g., BL for lower left.
This indicates which point on a rectangular region the lon/lat coordinate refers
to, and the grid dimensions nx and ny with grid spacings via -I is used to create
the corresponding region. Alternatively, specify the name of an existing grid file
and the -R settings (and grid spacing, if applicable) are copied from the grid.
Using -Runit expects projected (Cartesian) coordinates compatible with chosen -J
and we inversely project to determine actual rectangular geographic region. For
perspective view (-p), optionally append /zmin/zmax. In case of perspective view
(-p), a z-range (zmin, zmax) can be appended to indicate the third dimension. This
needs to be done only when using the -Jz option, not when using only the -p option.
In the latter case a perspective view of the plane is plotted, with no third
dimension.
-V[level] (more ...)
Select verbosity level [c].
-bi[ncols][t] (more ...)
Select native binary input. [Default is 2 input columns].
-bo[ncols][type] (more ...)
Select native binary output. [Default is same as input].
-d[i|o]nodata (more ...)
Replace input columns that equal nodata with NaN and do the reverse on output.
-h[i|o][n][+c][+d][+rremark][+rtitle] (more ...)
Skip or produce header record(s).
-icols[l][sscale][ooffset][,...] (more ...)
Select input columns (0 is first column).
-r (more ...)
Set pixel node registration [gridline].
-:[i|o] (more ...)
Swap 1st and 2nd column on input and/or output.
-^ or just -
Print a short message about the syntax of the command, then exits (NOTE: on Windows
use just -).
-+ or just +
Print an extensive usage (help) message, including the explanation of any
module-specific option (but not the GMT common options), then exits.
-? or no arguments
Print a complete usage (help) message, including the explanation of options, then
exits.
--version
Print GMT version and exit.
--show-datadir
Print full path to GMT share directory and exit.
ASCII FORMAT PRECISION
The ASCII output formats of numerical data are controlled by parameters in your gmt.conf
file. Longitude and latitude are formatted according to FORMAT_GEO_OUT, whereas other
values are formatted according to FORMAT_FLOAT_OUT. Be aware that the format in effect can
lead to loss of precision in the output, which can lead to various problems downstream. If
you find the output is not written with enough precision, consider switching to binary
output (-bo if available) or specify more decimals using the FORMAT_FLOAT_OUT setting.
GRID VALUES PRECISION
Regardless of the precision of the input data, GMT programs that create grid files will
internally hold the grids in 4-byte floating point arrays. This is done to conserve memory
and furthermore most if not all real data can be stored using 4-byte floating point
values. Data with higher precision (i.e., double precision values) will lose that
precision once GMT operates on the grid or writes out new grids. To limit loss of
precision when processing data you should always consider normalizing the data prior to
processing.
EXAMPLES
To construct Voronoi polygons from the points in the file testdata.txt and then calculate
distances from the data to a global 1x1 degree grid, use
gmt sphdistance testdata.txt -Rg -I1 -Gglobedist.nc
To generate the same grid in two steps using sphtriangulate separately, try
gmt sphtriangulate testdata.txt -Qv > voronoi.txt
gmt sphdistance -Qvoronoi.txt -Rg -I1 -Gglobedist.nc
SEE ALSO
gmt, sphtriangulate, triangulate
REFERENCES
Renka, R, J., 1997, Algorithm 772: STRIPACK: Delaunay Triangulation and Voronoi Diagram on
the Surface of a Sphere, AMC Trans. Math. Software, 23(3), 416-434.
COPYRIGHT
2015, P. Wessel, W. H. F. Smith, R. Scharroo, J. Luis, and F. Wobbe