Difference between revisions of "GRASS and GMT"

From GRASS-Wiki
Jump to: navigation, search
(New style NetCDF grd: by layer)
(Raster: -f,-d)
Line 8: Line 8:
  
 
=== Raster ===
 
=== Raster ===
 +
 +
* Use the <tt>grdinfo</tt> utility from GMT to check the ''Grid file format''. See the <tt>grdreformat</tt> man page for an explanation of the codes.
 +
** Codes starting with '''n''' are "new format" (NetCDF) which can be read by [http://www.gdal.org/frmt_various.html#GMT GDAL] tools and imported with the {{cmd|r.in.gdal}} module.
 +
** Codes starting with '''b''' are "old format" which can be imported with the {{cmd|r.in.bin}} module.
  
 
==== Old style binary grd ====
 
==== Old style binary grd ====
  
* Import using '''r.in.bin''' with the -h flag.
+
* Import using {{cmd|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.
 
: ''Note:'' (in case you missed it) '''r.in.bin -h''' was written to be used with the old style GMT grd format.
 
<!-- insert 'r.in.bin -h' command line example here -->
 
<!-- insert 'r.in.bin -h' command line example here -->
 +
 +
* ''Grid file format'' codes (see above) ending in <tt>f</tt> contain floating point data and require that ''r.in.bin'' be passed the '''-f''' flag. Format codes ending in <tt>d</tt> contain double precision floating point data and require the '''-d''' flag.
  
 
==== New style NetCDF grd ====
 
==== New style NetCDF grd ====
  
* {{cmd|r.in.gdal}} should be used for the new NetCDF GMT grd format directly.
+
* {{cmd|r.in.gdal}} is used to import the new NetCDF GMT grd format.
 
: See the [http://www.gdal.org/frmt_various.html#GMT GDAL netCDF driver] page.
 
: See the [http://www.gdal.org/frmt_various.html#GMT GDAL netCDF driver] page.
 
<!-- insert r.in.gdal command line example here -->
 
<!-- insert r.in.gdal command line example here -->
  
* 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:
+
* If for some reason ''r.in.gdal'' doesn't work (e.g. your copy of GDAL wasn't build with GMT/NetCDF support) you can convert the new-style grid file into the old-style grid format and then proceed to import with the '''r.in.bin -h''' method as given above. Use the GMT <tt>grdreformat</tt> tool to perform the conversion:
 
  grdreformat in.grd out.grd=bf
 
  grdreformat in.grd out.grd=bf
  
* Sometimes you'll have to specify the layer in the input grid:
+
: Sometimes the new-style NetCDF grid contains multiple layers of data and you'll have to explicitly specify the layer in the input grid that you want. For example, if the layer is called "z":
 
  grdreformat in.grd'''?z''' out.grd=bf
 
  grdreformat in.grd'''?z''' out.grd=bf
  
* The <tt>grdinfo</tt> utility may give you some help, as well as <tt>gdalinfo</tt>
+
* Examination of the <tt>grdinfo</tt> utility's output may give you some help, as will the output of <tt>gdalinfo</tt>.
  
  
For an example of importing a GMT grid to GRASS, see [[Marine_Science#Bathymetric_data|this page]].
+
For an example of importing a GMT grid into GRASS, see [[Marine_Science#Bathymetric_data|this page]].
  
 
=== Vectors ===
 
=== Vectors ===

Revision as of 01:33, 28 December 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

  • Use the grdinfo utility from GMT to check the Grid file format. See the grdreformat man page for an explanation of the codes.
    • Codes starting with n are "new format" (NetCDF) which can be read by GDAL tools and imported with the r.in.gdal module.
    • Codes starting with b are "old format" which can be imported with the r.in.bin module.

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.
  • Grid file format codes (see above) ending in f contain floating point data and require that r.in.bin be passed the -f flag. Format codes ending in d contain double precision floating point data and require the -d flag.

New style NetCDF grd

  • r.in.gdal is used to import the new NetCDF GMT grd format.
See the GDAL netCDF driver page.
  • If for some reason r.in.gdal doesn't work (e.g. your copy of GDAL wasn't build with GMT/NetCDF support) you can convert the new-style grid file into the old-style grid format and then proceed to import with the r.in.bin -h method as given above. Use the GMT grdreformat tool to perform the conversion:
grdreformat in.grd out.grd=bf
Sometimes the new-style NetCDF grid contains multiple layers of data and you'll have to explicitly specify the layer in the input grid that you want. For example, if the layer is called "z":
grdreformat in.grd?z out.grd=bf
  • Examination of the grdinfo utility's output may give you some help, as will the output of gdalinfo.


For an example of importing a GMT grid into 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.
  • If outputting areas be sure to explicitly request them, otherwise data attributes may not be transfered. For example:
v.out.ogr input=RBD_F1v3 format=GMT type=area dsn=RBD_F1v3.gmt

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