Create Voronoi distance, node, or natural nearest-neighbor grid on a sphere
gmt sphdistance [ table ] -Ggrdfile [ -C ] [ -D ] [ -Ed|n|z[dist] ] [ -Iincrement ] [ -Lunit ] [ -Nnodetable ] [ -Qvoronoi.txt ] [ -Rregion ] [ -V[level] ] [ -bbinary ] [ -dnodata ] [ -eregexp ] [ -hheaders ] [ -iflags ] [ -jflags ] [ -qiflags ] [ -rreg ] [ -:[i|o] ] [ --PAR=value ]
Note: No space is allowed between the option flag and the associated arguments.
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.
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.
Name of the output grid to hold the computed distances (but see -E for other node value options).
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.
Used to skip duplicate points since the algorithm cannot handle them. [Default assumes there are no duplicates].
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 natural 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 .
x_inc [and optionally y_inc] is the grid spacing. Geographical (degrees) coordinates: Optionally, append a increment unit. Choose among 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 +e 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 +n to the supplied integer argument; the increment is then recalculated from the number of nodes, the registration, and the domain. The resulting increment value depends on whether you have selected a gridline-registered or pixel-registered grid; see GMT File Formats for details. Note: If -Rgrdfile is used then the grid spacing and the registration have already been initialized; use -I and -r to override these values.
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.
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.
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).
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). Set geographic regions by specifying ISO country codes from the Digital Chart of the World using -Rcode1,code2,…[+r|R[incs]] instead: Append one or more comma-separated countries using the 2-character ISO 3166-1 alpha-2 convention. To select a state of a country (if available), append .state, e.g, US.TX for Texas. To specify a whole continent, prepend = to any of the continent codes AF (Africa), AN (Antarctica), AS (Asia), EU (Europe), OC (Oceania), NA (North America), or SA (South America). Use +r to modify the bounding box coordinates from the polygon(s): Append inc, xinc/yinc, or winc/einc/sinc/ninc to adjust the region to be a multiple of these steps [no adjustment]. Alternatively, use +R to extend the region outward by adding these increments instead, or +e which is like +r but it ensures that the bounding box extends by at least 0.25 times the increment [no extension]. 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 and registration, if applicable) are copied from the grid. Appending +uunit 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.
- -bi[ncols][t] (more …)
Select native binary format for primary 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.
- -e[~]“pattern” | -e[~]/regexp/[i] (more …)
Only accept data records that match the given pattern.
- -h[i|o][n][+c][+d][+msegheader][+rremark][+ttitle] (more …)
Skip or produce header record(s).
- -icols[+l][+ddivide][+sscale][+ooffset][,…][,t[word]] (more …)
Select input columns and transformations (0 is first column, t is trailing text, append word to read one word only).
- -je|f|g (more …)
Determine how spherical distances are calculated.
- -qi[~]rows[+ccol][+a|f|s] (more …)
Select input rows or data range(s) [default is all rows].
- -r[g|p] (more …)
Set 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 exit (NOTE: on Windows just use -).
- -+ or just +
Print an extensive usage (help) message, including the explanation of any module-specific option (but not the GMT common options), then exit.
- -? or no arguments
Print a complete usage (help) message, including the explanation of all options, then exit.
Temporarily override a GMT default setting; repeatable. See gmt.conf for parameters.
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, absolute time is under the control of FORMAT_DATE_OUT and FORMAT_CLOCK_OUT, whereas general floating point values are formatted according to FORMAT_FLOAT_OUT. Be aware that the format in effect can lead to loss of precision in ASCII 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.
Note: Below are some examples of valid syntax for this module.
The examples that use remote files (file names starting with
can be cut and pasted into your terminal for testing.
Other commands requiring input files are just dummy examples of the types
of uses that are common but cannot be run verbatim as written.
To compute a distance grid of the distances between a set of points in the remote file hotspots.txt and then contour them on a sphere with a 200 km interval and annotations every 1000 km, try:
gmt begin map gmt sphtriangulate @hotspots.txt -Qv -D > t.txt gmt sphdistance -Rg -I1 -Qt.txt -Gt.nc -Lk gmt grdcontour t.nc -JG-140/30/7i -C200 -A1000 -Bafg gmt end show
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
The STRIPACK algorithm and implementation expect that there are no duplicate points in the input. It is best that the user ensures that this is the case. GMT has tools, such as blockmean and others, to combine close points into single entries. Also, sphdistance has a -D option to determine and exclude duplicates, but it is a very brute-force yet exact comparison that is very slow for large data sets. Detection of duplicates in the STRIPACK library will exit the module.
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.