GRASS and GMT: Difference between revisions
(→Importing from GMT: ogr) |
(→Exporting GRASS maps to GMT: ogr vects) |
||
Line 43: | Line 43: | ||
Currently there are several *.out.GMT permutations on the [[GRASS_AddOns|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. | Currently there are several *.out.GMT permutations on the [[GRASS_AddOns|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. | ||
* [[GRASS_AddOns#v.out.gmt|v.out.gmt]] - Vector export for GMT | * [[GRASS_AddOns#v.out.gmt|v.out.gmt]] - Vector export for GMT (rewrite to use new [http://www.gdal.org/ogr/drv_gmt.html OGR r/w support]?) | ||
* [[GRASS_AddOns#v.out.gmt|r.out.gmt]] - Raster export for GMT | * [[GRASS_AddOns#v.out.gmt|r.out.gmt]] - Raster export for GMT | ||
* [[GRASS_AddOns#v.out.gmt|r.out.gmt2]] - Raster export for GMT | * [[GRASS_AddOns#v.out.gmt|r.out.gmt2]] - Raster export for GMT |
Revision as of 04:49, 17 December 2008
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
Vectors
- Newer versions of OGR support GMT vectors for read/write. Import with the v.in.ogr module.
Coloring
Importing CPT color tables
- Import GMT style .cpt color table files with the r.cpt2grass script on the Add-ons page.
- r.cpt2grass - Import GMT color rules
- 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.
- v.out.gmt - Vector export for GMT (rewrite to use new OGR r/w support?)
- r.out.gmt - Raster export for GMT
- r.out.gmt2 - Raster export for GMT
Proper 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.
Proper 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).
Proper 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
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.
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
- Dane DEM uzyskane z radarowej misji promu kosmicznego - SRTM-3: Tutorial in Polish