GMT, the “Generic Mapping Tools” [1], is a package I’ve heard about over the years but had never used. Mostly I’d heard that it was (1) very old, (2) mostly used in the academic/research community, (3) heavily tied to Postscript, and (4) completely independent of the “modern” open source GIS tools, e.g. those making up the OSGeo stack.
GMT came up recently during some discussions with a client of mine, so I decided it was time to download it and give it a try. Turns out that all four of those things I’d heard were true – and in good ways.
History and purpose
The first release of GMT was in 1988 – before some of you, I fear, were born – by some graduate students at Columbia University. With subsequent funding from NSF and contributions from developers and users all over the world, over the next quarter century it went through several major revisions and this year a significantly improved version 5.0 is coming out. It is available under the Gnu Public License (GPL).
GMT is a collection of dozens of command-line tools all designed to address various aspects of turning raw data into charts, plots, and maps: gridding, filtering, contouring, histogramming, labeling, and plotting. For us lidar folks, you can use the GMT tools to do things like take an ASCII table of XYZ points and produce a (gridded) DEM or an (ungridded) TIN, and then in turn produce a very nice colorized, shaded, 3D plot of the surface.
In what is surely a smart move, the GMT team does not attempt to support the innumerable set geospatial file formats in use today. Rather, they tend to restrict themselves to the basics – ASCII data tables, netCDF for gridded data sets, and PostScript for outputting the rendered maps and plots. (Other open source tools, such as GDAL [2], can be used for format conversions.)
Installation and setup
GMT is independent of other common pieces of the circa-2012 classical open source geospatial stack, which makes installation and setup rather painless. Under Windows, you need only to first install GhostScript and GSView (GPL-licensed libraries for interpreting and viewing PostScript files) and then install GMT itself; there are no other dependences to work through. After next setting a few environment variables, the tools are ready to run.
An example
As I’m only learning GMT now myself, so I’m just going to present a much abbreviated version of a tutorial I found on the web [3].
I have file data.xyz with 32K lines of XYZ points, like this:
-106.9345100000 34.0808400000 1471.8819580078
-106.9344101969 34.0808400000 1471.9831542969
-106.9343103937 34.0808400000 1472.0913085938
...
Let’s try to make a colored surface plot of the data.
The first thing we want to do is find the bounding box of the file, using the minmax command:
$ minmax data.xyz
data.xyz: N = 31365
<-106.93451/-106.90916>
<34.06863/34.08084>
<1406.28051758/1472.74768066>
We see we actually have 31,365 points and we have the actual ranges of the X, Y, and Z fields. We will now use those range to produce a base map for our plot.
(The ellipsis indicates some options omitted for pedagogical clarity; they specify the projection and some styling directives.) The PostScript output produced, data.ps, is shown in Figure 1.
Next, we generate a binary gridded data set in the file data.grd, using the surface command. There are a number of options to control the surface construction algorithm; we will use the defaults here.
$ surface data.xyz -Gdata.grd \
-R-106.93451/-106.90916/34.06863/34.08084 \
-I0.0001/0.0001
Now we will get fancy and generate a color palette table (ramp), named data.cpt, specifically scaled for our data set:
$ grd2cpt data.grd ... > data.cpt
(Again we have omitted some styling options.) Now we are ready to turn our binary gridded data file into an actual rendered image using our colors:
$ grdimage data.grd ... -Cdata.cpt >> data.ps
The grdimage command produces postscript output, which we append to the PostScript base map we made earlier. Our surface plot is shown in Figure 2.
Lots of little tools
It took five steps to make our plot: the GMT system follows the Unix tool philosophy of many small tools that each perform a specific function and can be “strung together” in a pipeline-like fashion. As we said, there are several dozen GMT tools like this, and the combined power of them produces some very impressive illustrations.
The next time you need to create some custom-styled renderings of your hard-won lidar data, consider spending an afternoon with GMT. Their website has a gallery of examples [4] to inspire you.
And one more thing
In a previous column we mentioned LASzip [5], Martin Isenburg’s open source library for lossless compression of LAS files. At the 2012 Geospatial World Forum this month, LASzip received the Technology Innovation Award in LiDAR Processing. Congratulations to Martin on his work, and a big thank you to him as well for making the code open so that everyone can take advantage of this now de facto LAZ standard format.
Reach our audience of Professional land surveyors and Geo-Technology professionals with your career ad. Feel free to contact us if you need additional information.
Authors 
(The ellipsis indicates some options omitted for pedagogical clarity; they specify the projection and some styling directives.) The PostScript output produced, data.ps, is shown in Figure 1.
The grdimage command produces postscript output, which we append to the PostScript base map we made earlier. Our surface plot is shown in Figure 2.
