GRASS and GMT: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
Line 36: Line 36:
==== Importing CPT color tables ====
==== Importing CPT color tables ====


* Import GMT style .cpt color table files with the '''r.cpt2grass''' script on the [[GRASS_AddOns#r.cpt2grass|Add-ons]] page.
* Import GMT style .cpt [[Color tables|color table]] files with the '''r.cpt2grass''' script on the [[GRASS_AddOns#r.cpt2grass|Add-ons]] page.
** [[GRASS_AddOns#r.cpt2grass|r.cpt2grass]] - Import GMT color rules
** [[GRASS_AddOns#r.cpt2grass|r.cpt2grass]] - Import GMT color rules
: For a large collection of GMT .cpt files see http://sview01.wiredworkplace.net/pub/cpt-city/
: For a large collection of GMT .cpt files see http://sview01.wiredworkplace.net/pub/cpt-city/

Revision as of 07:40, 26 August 2009

GMT (The Generic Mapping Tools)

GMT (Generic Mapping Tools) is a Free software package for creating publication quality cartography.

GMT homepage: http://gmt.soest.hawaii.edu

Importing from GMT

Raster

Old style binary grd

  • Import using r.in.bin with the -h flag.
Note: (in case you missed it) r.in.bin -h was written to be used with the old style GMT grd format.

New style NetCDF grd

  • r.in.gdal should be used for the new NetCDF GMT grd format directly.
See the GDAL netCDF driver page.
  • If you wish to use the r.in.bin -h method with a NetCDF based grd file you will need to reformat the GMT grid into the old format:
grdreformat in.grd out.grd=bf


For an example of importing a GMT grid to GRASS, see this page.

Vectors

Coloring

Importing CPT color tables

For a large collection of GMT .cpt files see http://sview01.wiredworkplace.net/pub/cpt-city/

Exporting GRASS maps to GMT


(Supplied by the GRASS Users Group of Davis, California)

Currently there are several *.out.GMT permutations on the Add-ons page, in several different languages (bash, python, etc.), and each of which with relative pros/cons. An effort to unify these approaches would save much of the current difficulties in moving complex raster+vector data into a GMT-friendly format. A simple road map toward this goal is outlined below.


To aid custom scripting, g.region in GRASS 6.5+ supports the -t flag to output the current region in GMT's W/E/S/N region format.


Raster

  • Conversion of GRASS raster data to GMT compatible binary grids

A combination of r.out.bin | xyz2grd can accomplish this. Several attempts at generalizing this procedure have been proposed: r.out.gmt.py, r.out.gmt (Hamish and Dylan), r.out.gmt.sh (Dylan, based Hamish's work).

  • Imagery data e.g. aerial photos

For multiband imagery data, the following commands will export the different colour bands: 

r.mapcalc "image.red=r#image; image.green=g#image; image.blue=b#image"
r.out.bin -h input=image.red output=image.red.grd
r.out.bin -h input=image.green output=image.green.grd
r.out.bin -h input=image.blue output=image.blue.grd

They can then be plotted with: 

grdimage image.red.grd image.green.grd image.blue.grd -J -R -B ...etc.

Vector

  • Conversion of GRASS vector data to GMT compatible ascii files

There is currently an effort (with some funding!), see some of the chatter on the GRASS and GMT mailing lists: GRASS-list GMT-help

  • OGR now supports GMT vector (multiline) output, so it is easy to convert data to GMT format for plotting. Use the v.out.ogr module.

Coloring

  • Conversion of GRASS raster color data into GMT compatible CPT files

David Finlayson's r.out.gmt.py does a nice job of this. Once we decide on an optimal language to implement the routines in this may need translation.

Symbology

  • Automatic conversion of symbology data stored in a gis.m or QGIS saved state to GMT options

Ideas expressed on various mailing list, haven't seem much since. It should be a relatively simple excercise in XML parsing to convert symbology stored in a QGIS project file into something that GMT can use.

Development plans

  • General approach:

Since GMT relies on a sequence of specialized programs to "build-up" a postscript file, some thought must be put into how the conversion should take place. As usual, form should follow function- maximum flexibility, robustness, and accuracy being primary objectives. However, a simple means of creating high quality 2D maps would be a tremendous (I think) addition to the GRASS toolset. Especially since this is something frequently cited by critics. --DylanBeaudette 02:47, 10 December 2006 (CET)

1. should we continue down the well troden path of single-use, highly efficient programs for the various conversion steps: i.e v.out.GMT, r.out.GMT, etc.?

2. should there be a unified approach to the process: something akin to ps.map - GMT.map ?

Tutorials

Retrieved from "https://grasswiki.osgeo.org/w/index.php?title=GRASS_and_GMT&oldid=9473"