Tips and Tricks: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
(→‎Using QGIS as a frontend to GRASS: explain the connection)
 
(21 intermediate revisions by 5 users not shown)
Line 16: Line 16:
* GDAL homepage:  http://www.gdal.org
* GDAL homepage:  http://www.gdal.org


To use the two together, the GDAL-GRASS plugin must be installed:
Here is a nice tutorial for editing vectors using QGIS as a frontend to GRASS: [[Editing_GRASS_vectors_with_QGIS]] (''where did it go? unported from old wiki site?'' )
 
To use GDAL and GRASS together, the GDAL-GRASS plugin must be installed:


* [[Compile and install GRASS and QGIS with GDAL/OGR Plugin]]
* [[Compile and install GRASS and QGIS with GDAL/OGR Plugin]]
Line 34: Line 36:
While not a firm requirement, it is easier to start QGIS from within a GRASS session.
While not a firm requirement, it is easier to start QGIS from within a GRASS session.


* [http://wiki.qgis.org/qgiswiki/GrassCookbook QGIS GRASS Cookbook] - Recipes for common tasks
* [[QGIS GRASS Cookbook]] - Recipes for common tasks


===Importing SRTM30plus data===
===Importing SRTM30plus data===


SRTM30plus data consists of 33 files of global topography in the same format as the SRTM30 products distributed by the USGS EROS data center. The grid resolution is 30 second which is roughly one kilometer.
See [[Global_datasets#SRTM30plus_data|Global datasets]] page
 
Land data are based on the 1-km averages of topography derived from the USGS SRTM30 grided DEM data product created with data from the NASA Shuttle Radar Topography Mission. GTOPO30 data are used for high latitudes where SRTM data are not available.
 
Ocean data are based on the Smith and Sandwell global 2-minute grid between latitudes +/- 72 degrees. Higher resolution grids have been added from the LDEO Ridge Multibeam Synthesis Project and the NGDC Coastal Relief Model. Arctic bathymetry is from the International Bathymetric Chart of the Oceans (IBCAO).
 
All data are derived from public domain sources and these data are also in the public domain.
 
GRASS 6 script <code>r.in.srtm</code> described in GRASSNews vol. 3 won't work with this dataset (as it was made for the original SRTM HGT files). But you can import SRTM30plus tiles into GRASS this way:
 
r.in.bin -sb input=e020n40.Bathmetry.srtm output=e020n40_topex bytes=2 north=40 south=-10 east=60 west=20 r=6000 c=4800
r.colors e020n40_topex rules=etopo2


; Source
=== GMT (The Generic Mapping Tools) ===
: GRASS Users Mailing List http://grass.itc.it/pipermail/grassuser/2005-August/030018.html
; Getting SRTM30plus tiles
: ftp://topex.ucsd.edu/pub/srtm30_plus/data


===Exporting GRASS maps to GMT===
* [[GRASS and GMT]]


GMT (Generic Mapping Tools) is a Free software package for creating publication quality cartography.
GMT (Generic Mapping Tools) is a Free software package for creating publication quality cartography.
Line 62: Line 50:
GMT homepage:  http://gmt.soest.hawaii.edu
GMT homepage:  http://gmt.soest.hawaii.edu


Exporting GRASS maps to GMT:  http://169.237.35.250/~dylan/grass_user_group/#GMT_and_GRASS-overview
=== Interfacing R-Statistics with GRASS ===
<BR>(Supplied by the GRASS Users Group of Davis, California)
 
Currently there are several *.out.GMT permutations, several in 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:
 
====Proper conversion of GRASS raster color data into GMT compatible CPT files====
David Finlayson's [http://david.p.finlayson.googlepages.com/gisscripts 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: [http://david.p.finlayson.googlepages.com/gisscripts r.out.gmt.py], [http://bambi.otago.ac.nz/hamish/grass/r.out.gmt r.out.gmt] (Hamish and Dylan), [http://169.237.35.250/~dylan/grass_user_group/r.out.gmt.sh 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:
[http://grass.itc.it/pipermail/grassuser/2006-April/033659.html GRASS-list]
[http://www.nabble.com/Ideas-needed-regarding-OGR-reformatter-for-GMT-vector-(point-multiline)-files.-t2605255.html 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. --[[User:DylanBeaudette|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'' ?
 
===Interfacing R-Statistics with GRASS===
 
 
* All the necessary functions for the GRASS 6 interface are now in packages on CRAN, so that on Linux/Unix (or Mac OSX) installing rgdal from source with PROJ4 and GDAL installed, or Windows installing from binary, the required packages are: sp; maptools (now includes spmaptools); rgdal (now includes spGDAL, spproj); spgrass6 - now all on CRAN.
 
* http://grass.ibiblio.org/statsgrass/index.php#grassR
 
* R-Statistics homepage  http://www.r-project.org
 
* R Spatial Projects http://sal.uiuc.edu/csiss/Rgeo//


* http://r-spatial.sourceforge.net/xtra/xtra.RHnw.html#spgrass6
* [[GRASS_and_Rstat|GRASS and R]]


* Neural Networks with GRASS and R (posted by Markus Neteler on the grass-user mailing list) http://www.uam.es/proyectosinv/Mclim/pdf/MBenito_EcoMod.pdf
GRASS may be combined with R-Statistics to create a very powerful geostatistical analysis platform.


* Using R and GRASS with cygwin: It is possible to use Rterm inside the GRASS shell in cygwin, just as in Unix/Linux or OSX. You should not, however, start Rterm from a cygwin xterm, because Rterm is not expecting to be run in an xterm under Windows, and loses its input. If you use the regular cygwin bash shell, but need to start display windows, start X from within GRASS with startx &, and then start Rterm in the same cygwin shell, not in the xterm.
R-Statistics homepage  http://www.r-project.org


===Using GRASS with an on-line Web-GIS===
===Using GRASS with an on-line Web-GIS===
Line 132: Line 85:


Using the -X flag, or simply turning on X11Forwarding in the SSH configuration files, is not enough:  the symptoms in this case are that a d.mon window will function fine, but none of the Tcl/Tk dialogues will work, failing with an error message complaining either about Wish not behaving as expected, or a "Bad Atom".
Using the -X flag, or simply turning on X11Forwarding in the SSH configuration files, is not enough:  the symptoms in this case are that a d.mon window will function fine, but none of the Tcl/Tk dialogues will work, failing with an error message complaining either about Wish not behaving as expected, or a "Bad Atom".
==Quick tips ==
=== Checking categories pertaining to more than one feature ===
<!--====Discover multiple features having the same category====-->
v.build op=cdump map=mymap | gawk -F"|" '{print $1}' | uniq -dc
returns, e.g.<br />
5    35347<br />
(5 features with cat 35347)




=== Applying [[v.edit]] tools on a whole map ===
[[v.edit]] allows many powerful geometrical manipulations. Operations are performed on certain features you must point out with arguments like ''ids='', ''cats='', ''coords='', and so on. When you need to run a tool on the whole map (e.g. every boundary), then it can be annoying to describe them (e.g. provide a ''cats'' list). A common way is to use the -r (reverse selection) flag in combination with pointing at feature-ids equal to zero (i.e. empty selection) :
v.edit map=mymap type=boundary tool=merge ids=0 -r
=== Compensate the lack of line ends symbology in ps.map ===
[[ps.map]] does not allow to specify line-end (from- and to-nodes) symbols oriented in the same direction as the last (resp. first) segment. Typically you want to add arrowheads to a line vector. Here we suggest a one-line gas (grep/awk/sed) solution. The idea is to output a bunch of selected lines ("where" argument), extract concerned couples of vertices, calculate a position and an angle for each tip, then import this set of data in a point vector. This point vector can latter be invoked in a ps.map command file.
The next example illustrates the process for line vector ''mylines''. We want to be able to draw an arrow head at the to-node lines for which attribute ''code'' equals 3 or 5 :
<source lang="bash">
for i in `v.out.ascii input=mylines format=standard where="code=3 or code=5" \
  | grep -n 'L  ' | sed s/\:/' '/ | sed s/'  '/' '/ | awk '{print $1+$3-1}'`; do
    v.out.ascii input=mylines format=standard where="code=3 or code=5" \
      | sed -n ${i},$((i+2))p | \
      awk \
        'NR == 2 {x=$1;y=$2} NR == 1 {xi=$1;yi=$2} \
        NR == 3 {cat=$2} END {pi=3.14159;OFS="|"; \
        print cat,x,y,atan2(yi-y,xi-x)/pi*180}';
done \
  | v.in.ascii -n out=myarrowheads x=2 y=3 cat=1 \
      columns='cat int, x double precision, y double precision, angle double precision'
</source>
''Warning: intended to be a set of piped commands, it does not handle temporary maps/files. Obvioulsly it is not an optimized solution in terms of calculations (v.out.ascii is run within the loop as many times as the number of processed lines). But it is reasonably fast and leaves no traces when completed.''
It results in a point vector named ''myarrowheads''. Attribute field ''angle'' contains the rotation angle value fitting with to-node last segment direction.
ps.map command allowing to hardcopy arrows would look like this :
<pre>
vlines mylines
width 0.6
color black
end
vpoints myarrowheads
color black
symbol extra/n_arrow1
rotatecolumn angle+90
size 2
end
</pre>
[[Category:Documentation]]
[[Category:Documentation]]

Latest revision as of 08:47, 10 May 2013

Tips and Tricks

Using QGIS as a frontend to GRASS

  • QGIS started as a simple viewer for geodata. And that's really what it still is: a simple-to-use geodata viewer with some editing capabilities. That's what it was designed to be and that's what it can do really well. QGIS does not have built-in capabilities for geodata processing and analysis.
However, a while back, Radim Blazek, who was then a core developer of the GRASS 6 system, decided to write a plugin for QGIS that would make it possible to access GRASS functionality from within the QGIS GUI.
And that's what you get today, when you download a binary version of QGIS for your platform: QGIS + GRASS 6 plus a plugin that makes using GRASS from QGIS simple and fun.


QGIS can run as a frontend to GRASS. There is support for displaying maps, editing maps, and execution of simple GIS functions. The GDAL/OGR library is a requirement for that (but for GRASS anyway):

Here is a nice tutorial for editing vectors using QGIS as a frontend to GRASS: Editing_GRASS_vectors_with_QGIS (where did it go? unported from old wiki site? )

To use GDAL and GRASS together, the GDAL-GRASS plugin must be installed:

Test that the GDAL-GRASS plugin is available with this command:

  gdalinfo --formats

Look for a line like "GRASS (ro): GRASS Database Rasters (5.7+)"

Enable the QGIS GRASS plugin from QGIS:

  GUI: Plugins / Plugin Manager / Check the GRASS checkbox

The GRASS toolbar should now be visible. While not a firm requirement, it is easier to start QGIS from within a GRASS session.

Importing SRTM30plus data

See Global datasets page

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

Interfacing R-Statistics with GRASS

GRASS may be combined with R-Statistics to create a very powerful geostatistical analysis platform.

R-Statistics homepage http://www.r-project.org

Using GRASS with an on-line Web-GIS

see:

(please expand)

Starting and running GRASS from a script

See GRASS and Shell.

Running GRASS remotely on OS X

Tiger (OS 10.4) changed the default configuration of SSH from previous versions of OS X. You can no longer start an ssh session with the -X flag and display the Tcl/Tk components of the GRASS GUI remotely. If you are running grass on OS X (10.4) between hosts on a network (i.e. running it on one machine but displaying it on another), you will need to use the "trusted forwarding" mode of SSH in order for the Tcl/Tk generated graphics, such as d.m or gis.m in order for the GUI graphics to make it through your connection. This can be done using the -Y flag when you start the ssh session:

ssh -Y remotehost

or add this to ~/.ssh/config:

Host hostname
  ForwardX11 yes
  ForwardX11Trusted yes

Using the -X flag, or simply turning on X11Forwarding in the SSH configuration files, is not enough: the symptoms in this case are that a d.mon window will function fine, but none of the Tcl/Tk dialogues will work, failing with an error message complaining either about Wish not behaving as expected, or a "Bad Atom".

Quick tips

Checking categories pertaining to more than one feature

v.build op=cdump map=mymap | gawk -F"|" '{print $1}' | uniq -dc

returns, e.g.
5 35347
(5 features with cat 35347)


Applying v.edit tools on a whole map

v.edit allows many powerful geometrical manipulations. Operations are performed on certain features you must point out with arguments like ids=, cats=, coords=, and so on. When you need to run a tool on the whole map (e.g. every boundary), then it can be annoying to describe them (e.g. provide a cats list). A common way is to use the -r (reverse selection) flag in combination with pointing at feature-ids equal to zero (i.e. empty selection) :

v.edit map=mymap type=boundary tool=merge ids=0 -r


Compensate the lack of line ends symbology in ps.map

ps.map does not allow to specify line-end (from- and to-nodes) symbols oriented in the same direction as the last (resp. first) segment. Typically you want to add arrowheads to a line vector. Here we suggest a one-line gas (grep/awk/sed) solution. The idea is to output a bunch of selected lines ("where" argument), extract concerned couples of vertices, calculate a position and an angle for each tip, then import this set of data in a point vector. This point vector can latter be invoked in a ps.map command file.

The next example illustrates the process for line vector mylines. We want to be able to draw an arrow head at the to-node lines for which attribute code equals 3 or 5 :

for i in `v.out.ascii input=mylines format=standard where="code=3 or code=5" \
  | grep -n 'L  ' | sed s/\:/' '/ | sed s/'  '/' '/ | awk '{print $1+$3-1}'`; do
    v.out.ascii input=mylines format=standard where="code=3 or code=5" \
      | sed -n ${i},$((i+2))p | \
      awk \
        'NR == 2 {x=$1;y=$2} NR == 1 {xi=$1;yi=$2} \
         NR == 3 {cat=$2} END {pi=3.14159;OFS="|"; \
         print cat,x,y,atan2(yi-y,xi-x)/pi*180}';
done \
  | v.in.ascii -n out=myarrowheads x=2 y=3 cat=1 \
       columns='cat int, x double precision, y double precision, angle double precision'

Warning: intended to be a set of piped commands, it does not handle temporary maps/files. Obvioulsly it is not an optimized solution in terms of calculations (v.out.ascii is run within the loop as many times as the number of processed lines). But it is reasonably fast and leaves no traces when completed.

It results in a point vector named myarrowheads. Attribute field angle contains the rotation angle value fitting with to-node last segment direction.

ps.map command allowing to hardcopy arrows would look like this :

vlines mylines
	width 0.6
	color black
	end
vpoints myarrowheads
	color black
	symbol extra/n_arrow1
	rotatecolumn angle+90
	size 2
end