GRASS-Wiki - User contributions [en]

WxPython-based GUI for GRASS

2011-12-30T20:59:01Z

⚠️Reverse22:

Browse also wxGUI related [[:Category:WxGUI|articles or screenshots]].

See also [[GRASS GUI]], and [[GRASS and Python]].

For developer-related issues see [http://trac.osgeo.org/grass/wiki/wxGUIDevelopment Trac wxGUI page].

__TOC__

== Overview ==

* [http://grass.osgeo.org/grass64/manuals/html64_user/wxGUI.html Manual page]
* A nice summary of the progress to date, written by Jachym Cepicky:
** [http://www.les-ejk.cz/english/wxgrass-new-grass-gui-1 Part 1]
** [http://www.les-ejk.cz/english/wxgrass-new-grass-gui-2 Part 2]
* [[User:Landa|Martin Landa]]: [http://gama.fsv.cvut.cz/~landa/publications/2008/gis-ostrava-08/paper/landa-grass-gui-wxpython.pdf New GUI for GRASS GIS based on wxPython] ([http://gis2008.com/indexe.html GIS Ostrava 2008], January 27-30, 2008, Ostrava, Czech Republic)
* [[User:Landa|Martin Landa]], Cristina Moretto, Michele Zanolli, Luca Manganelli and Markus Neteler: [http://gama.fsv.cvut.cz/~landa/publications/2008/gfoss-it-08/paper/grass-gfoss-tn.pdf wxPython-based GUI for GRASS GIS] ([http://gama.fsv.cvut.cz/~landa/publications/2008/gfoss-it-08/prezentazione/perugia-grass-gui-wxpython.pdf presentation]) ([http://www.grassmeeting2008.unipg.it IX Meeting degli Utenti Italiani di GRASS - GFOSS], February 20-22, Perugia, Italy)

=== Requirements ===

* [http://svn.osgeo.org/grass/grass/trunk/gui/wxpython/README README]

=== Development ===

Do you want to help with the development?

* basic Python programming ability required
* GUI programming experience welcomed (especially wxPython)
* GRASS user (or better developer) experience

How to get [http://trac.osgeo.org/grass/wiki/HowToContribute write access] to the GRASS SVN repository.

== Screenshots ==

* [[:Category:WxGUI|Screenshots from GRASSWiki]]
* [http://svn.osgeo.org/grass/grass-addons/screenshots/wxpython SVN]
* [http://grass.osgeo.org/screenshots/gui.php Website screenshot page]
* Various screenshots from [[:Category:WxGUI|GRASS-Wiki]]

=== GNU/Linux ===

<center>
{|
|
[[Image:Wxgui-startup-gnulinux.png|300px|thumb|Start-up screen]]
||
[[Image:Wxgui-vdigit1-gnulinux.png|300px|thumb|Vector digitizer]]
|-
|
[[Image:Wxgui-atm0-gnulinux.png|300px|thumb|Attribute Table Manager]]
||
[[Image:Wxgui-vector-querying-gnulinux.png|300px|thumb|Querying vector map layers (attribute data)]]
|-
|
[[Image:Wxnviz-volumes.png|300px|thumb|center|wxGUI: Displaying raster (surface), 2D vector and 3D raster (volume) in the 3D space]]
||
[[Image:wxgui-spatial-query.png|300px|thumb|center|wxGUI: Spatial query]]
|}
</center>

=== Mac OS ===

=== MS Windows ===

<center>
{|
|
[[Image:Wxgui-startup-windows1.png|300px|thumb|Start-up screen]]
||
[[Image:Wxgui-d-vect-windows.png|300px|thumb|GUI dialog d.vect]]
|-
|
[[Image:Wxgui-atm-windows.png|300px|thumb|Attribute Table Manager]]
||
[[Image:Wxgui-r-buffer-windows.png|300px|thumb|Running command (r.buffer)]]
|-
|
[[Image:Wxgui-vector-querying-windows.png|300px|thumb|Querying vector map layer (editable mode)]]
||
 
|}
</center>

== Video tutorials ==

=== Import vector data ===

* [[Import DXF]]
{{YouTube|eD2B1i9YxxQ|desc=Importing single shapefile}}
{{YouTube|ohbV_MR530Q|desc=Importing multiple shapefiles}}
{{YouTube|lJVBw78zYY0|desc=Importing SpatiaLite layers}}
{{YouTube|JoqIkL2VRVc|desc=Importing PostGIS layers into GRASS}}

=== Import raster data ===

Importing multiple GeoTIFF files:

<center>
{|
|
[[Image:WxGUI bulk raster import1.png|300px|thumb|Bulk import of GeoTIFF via menu]]
||
[[Image:WxGUI bulk raster import2.png|320px|thumb|Bulk import of GeoTIFF via menu (files are auto-selected)]]
|
|}
</center>

=== Link vector data (GRASS 7) ===

{{YouTube|eB3_SmE3E9Q|desc=Link PostGIS layers as GRASS vector maps}}

=== Map display ===

{{YouTube|PY8aytvfQqA|desc=Define legend and export to image}}

=== Georectifier ===

* Manual page of {{cmd|wxGUI.GCP_Manager|desc=GCP Manager}}

=== Graphical modeler ===

''Note:'' GRASS 6.4.2+ required.

See wxGUI [[WxGUI Modeler#Video Tutorials|Modeler]] page.

=== Layer Manager: Searching GRASS module ===

{{YouTube|Z9STgChNWcM|desc=Search for GRASS module (GRASS 6.4.2 required)}}

=== Map Calculator ===

{{YouTube|yMpVVRaVYeA|desc=Calculating NDVI}}

=== wxGUI 3D view mode (wxNviz) ===

See [[WxNviz#Video tutorials|wxNviz]] page.

== Components ==

=== Core components ===

==== Layer Manager ====

'''Status:''' prototype implemented.

The '''GRASS GIS Layer Manager''' provides an interactive graphical interface to GRASS commands. The Layer Manager includes a set of pull-down menus for all GRASS GIS functions (analysis, file I/O, GIS configuration and management), toolbar that manage display map layers in map display windows, layer tree in which map layers to display are organized, command output window and integrated command line prompt.

<center>
<gallery perrow=2 widths=300 heights=200>
Image:wxgrass-gis-manager-layer.png|2007/12
Image:wxgrass-gis-manager-output.png|2007/12
Image:Wxgrass rgb.png|2008/02
Image:wxgui-layer-manager-70.png|2010/08
Image:wxgui-pyshell.png|2011/06 - Embedded interactive Python Shell
</gallery>
</center>

==== Map display window ====

'''Status:''' prototype implemented.

Each '''Map display window''' has a unique set of layers to display and region setting (zoom). The map display window includes main toolbar with basic tools including zooming, panning, data querying, simple analyse functions (measure, profile, histogram, etc.), overlay management, etc. From main toolbar are accessible additional toolbars, currently only Digitization tool is available. Under development is Georectification tool.

<center>
<gallery perrow=2 widths=300 heights=200>
Image:Wxgrass-mapdisplay-0.png
Image:Wxgui-mapdisplay-1.png
</gallery>
</center>

==== GUI dialogs ====

'''Status:''' prototype implemented.

Generated from XML using <tt>--interface-description</tt>.

E.g. <tt>d.rgb --help</tt>
<pre>
Description:
Displays three user-specified raster map layers as red, green, and blue overlays in the active graphics frame.

Keywords:
display

Usage:
d.rgb [-ox] red=name green=name blue=name [--verbose] [--quiet]

Flags:
-o Overlay (non-null values only)
-x Don't add to list of commands in monitor
--v Verbose module output
--q Quiet module output

Parameters:
red Name of raster map to be used for <red>
green Name of raster map to be used for <green>
blue Name of raster map to be used for <blue>
</pre>

becomes with <tt>d.rgb --interface-description</tt>

<source lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE task SYSTEM "[http://trac.osgeo.org/grass/browser/grass/trunk/gui/xml/grass-interface.dtd grass-interface.dtd]">
<task name="d.rgb">
<description>
Displays three user-specified raster map layers as red, green, and blue overlays in the active graphics frame.
</description>
<keywords>
display
</keywords>
<parameter name="red" type="string" required="yes" multiple="no">
<description>
Name of raster map to be used for <red>
</description>
<keydesc>
<item order="1">name</item>
</keydesc>
<gisprompt age="old" element="cell" prompt="raster" />
</parameter>
<parameter name="green" type="string" required="yes" multiple="no">
<description>
Name of raster map to be used for <green>
</description>
<keydesc>
<item order="1">name</item>
</keydesc>
<gisprompt age="old" element="cell" prompt="raster" />
</parameter>
<parameter name="blue" type="string" required="yes" multiple="no">
<description>
Name of raster map to be used for <blue>
</description>
<keydesc>
<item order="1">name</item>
</keydesc>
<gisprompt age="old" element="cell" prompt="raster" />
</parameter>
<flag name="o">
<description>
Overlay (non-null values only)
</description>
</flag>
<flag name="x">
<description>
Don't add to list of commands in monitor
</description>
</flag>
<flag name="verbose">
<description>
Verbose module output
</description>
</flag>
<flag name="quiet">
<description>
Quiet module output
</description>
</flag>
</task>
</source>

which is then used to generate:

[[Image:wxgrass-d-rgb.png|center|600px]]

==== Startup GUI (welcome screen) ====

'''Status:''' prototype implemented.

Start new GRASS session with

grass -wxpython

[[Image:Wxgrass-startup.png|center|400px]]

==== Location wizard ====

'''Status:''' prototype implemented.

Wizard for creating new GRASS project location based on:

* Coordinate system
* EPSG code
* Georeferenced file
* PROJ.4 string
* XY

See also [[GRASS Location Wizard]].

[[Image:Wxgui-location-wizard.png|center|thumb|600px|Location wizard]]

=== Digitizer ===

==== Vector digitizer ====

'''Status:''' prototype implemented.

Manual page - {{cmd|wxGUI.Vector_Digitizer}}

See also [[GRASS Digitizing tool]] and [[wxGUI Vector Digitizer]].

Replacement of <tt>v.digit</tt> module integrated into Map display window ([http://svn.osgeo.org/grass/grass-promo/screenshots/wxpython/digitization Screenshots]).

<center>

<gallery perrow=2 widths=300 heights=200>
Image:WxDigit200804.png|Vector digitizer (2008/04)
Image:Digit-01.png|Vector digitizer (2007/11)
Image:WxGUI-vdigit-fill-area.png|Vector digitizer - fill valid areas (closed boundary + centroid) (2008/07)
Image:WxGUI-vdigit-bg.png|Vector digitizer - background raster maps with different opacity level (2008/07)
Image:WxGUI-vdigit-win0.png|Vector digitizer on MS Windows (2011/01)
Image:Wxgui-vdigit-dupl.png|Vector digitizer - checking for duplicates (2011/02)
</gallery>

</center>

==== Raster digitizer ====

'''Status:''' development not started yet.

* r.digit (merge with v.digit?)
: Probably write a front end for [http://grass.osgeo.org/grass63/manuals/html63_user/r.in.poly.html r.in.poly], that's all the old r.digit is.
* d.rast.edit
: Idea: get cell center coords and new values from GUI interaction, then pass those through r.in.xyz, and r.patch the new values over the top of the old map.

* merge with Georectifier? (i.points, i.vpoints)

===== Category Labels =====

* Write with new r.category import tool
** ''Back-end component complete: r.category module is now updated to handle a rules= file and other goodies like dynamic labels''

* Read with one of r.category, r.describe, r.report, r.stats, ???
** probably need to add a new flag to one of those to print flat <tt>"%d %s", cat, label</tt>
: or read the cats/ file directly, it's already flat ascii.

* how to deal with FP maps & cats?

=== Cartography tools ===

==== GUI for ps.map ====

'''Status:''' under development (Anna Kratochvilova).

More into at '''[[WxGUI Cartographic Composer]]'''.

==== Direct printing ====

'''Status:''' development not started yet.

Implement direct printing of map canvas content using GRASS PS driver or Cairo driver.

* [http://trac.gispython.org/projects/PCL/wiki Python Cartographic Lab]
* [http://wiki.osgeo.org/wiki/OSGeo_Cartographic_Library OSGeo Cartographic Library]
** http://lists.osgeo.org/pipermail/discuss/2008-April/003337.html
** http://www.intevation.de/pipermail/freegis-list/2007-April/003142.html
* [http://wiki.osgeo.org/wiki/OSGeo_map_symbol_set OSGeo Map Symbol Set]
* [http://www.gdal.org/ogr/ogr_feature_style.html OGR - Feature Style Specification]
* [http://trac.osgeo.org/mapguide/wiki/MapGuideRfc14 MapGuide RFC 14 - Cartographic Stylization Engine]

* [http://www.iho.shom.fr/PUBLICATIONS/download.htm#special S-52 standard for nautical chart (ENC) symbology] and cartography from the [http://www.iho.shom.fr/ International Hydrographic Bureau]
** [http://openev.cvs.sourceforge.net/openev/contrib/S52/ GPL library implementing the S-52 standard] (OpenEV)

* [http://www.opengeospatial.org/standards/symbol OpenGIS Symbology Encoding Implementation Specification]

* [http://geosysin.iict.ch/trac/wiki/Index4extJPAL PAL]

=== Georectifier ===

'''Status:''' prototype implemented.

<center>
{|
|-
| [[Image:Wxgui-georectify-0.png|thumb|350px|center]] ||
[[Image:Wxgui-georectify-1.png|thumb|350px|center]]
|-
|}
</center>

See also [[Georeferencing]].

; Tutorials

* [http://gama.fsv.cvut.cz/~landa/grass/swf/georect.html Georectifing raster data]

=== Profile Analysis Tool ===

'''Status:''' prototype implemented.

<center>
{|
|-
| [[Image:Wxgui-profile-0.png|thumb|350px|center]] ||
[[Image:Wxgui-profile-1.png|thumb|350px|center]]
|-
|}
</center>

=== Attribute table manager ===

;'''Status:''' prototype implemented.

[http://grass.osgeo.org/grass64/manuals/html64_user/wxGUI.Attribute_Table_Manager.html Manual page].

[[Image:Grass-atm-example.png|center|thumb|640px|Attributes queries in wxGUI]]
[[Image:Wxgui-attribute-table-manager.png|center|thumb|350px|Attribute Table Manager]]

;Allows:

* To browse attribute data, perform SQL select statements
* Modify attribute data, insert new records to attribute table, delete existing records
* Highlight selected items in Map Display Window
* Extract selected items into new vector map layer
* Modify attribute table - add, drop, rename columns
* Modify vector map layer DB connestion settings - add, remove or modify layers

=== 3D view mode ===

'''Status:''' under development (Google Summer of Code 2008/2010).

See detailed information at [[wxNVIZ]] page and original TCL/TK {{cmd|version=64|nviz}} manual page.

[[Image:Wxnviz-volumes.png|640px|thumb|center|Displaying raster (surface), 2D vector and 3D raster (volume) in the 3D space.]]

=== Imagery tools ===

'''Status:''' (re)development not started in earnest yet. Some behind-the-scenes code has been prepared, but not much.
: ''Volunteers welcome!''

==== Ortho photos ====

'''Status:''' development not started yet.

* To replace {{cmd|i.ortho.photo}} and friends

==== wx.iclass ====

'''Status:''' Under development.

===== First prototype (AddOns) =====

* [http://trac.osgeo.org/grass/browser/grass-addons/gui/wxpython/wx.class wx.class]

<center>
{|
|-
| [[Image:wx.class1.png|350px|thumb|center|wx.class]]
| [[Image:wx.class2.png|350px|thumb|center|wx.class]]
| [[Image:wx.class3.png|350px|thumb|center|wx.class]]
|-
|}
</center>

Current Features:

* Does not require xterm
* works on windows which is not currently available

To be implemented:

* Proper view of histogram using python-matplotlib
* To work on other datset (currently works for nc_spm_08)
* Needs a code cleanup

===== Second prototype (trunk) =====

* [[wxIClass]]

=== Graphical Modeller ===

'''Status:''' under development.

See [[wxGUI Modeler]] page for more information.

=== Extension Manager ===

'''Status:''' under development

* [http://gama.fsv.cvut.cz/~landa/grass/swf/install-addons.html wxGUI Extension Manager]

[[Image:wxgui-em.png|center|thumb|500px|wxGUI Extension Manager]]

=== Map Calculator ===

'''Status:''' prototype implemented

[[Image:wxgui-mapcalc.png|center|thumb|500px|wxGUI Map Calculator]]

=== Data Catalog ===

;'''Status:''' Under development.

* [http://trac.osgeo.org/grass/browser/grass-addons/gui/wxpython/data_catalog Data Catalog]

<center>
{|
|-
| [[Image:Catalog.png|350px|thumb|center|Data Catalog ]]
| [[Image:Aspect.png|350px|thumb|center|Data Catalog]]
|-
|}
</center>

;Current Features:

* copy, delete, rename map layers (raster & vector) in current mapset.
* view raster & vector map layers from any location and any mapset.
* Provides a GUI wrapper for r.info & v.info grass commands while viewing map layers in mapwindow.
* Can connect with OssimPlanet using PlanetSasha
* Add and Remove maps from GRASS GIS to OssimPlanet(Send to OssimPlanet/Remove from OssimPlanet)

;To be implemented:

* copy, move map layers in different mapsets.
* View DBF files as tables.
* Copy, delete, rename DBF files.
* Modify attribute tables.
* Create a properties window to display Coordinate system & projection for each map
* ...

Alternative: http://code.google.com/p/wxgis/

=== r.li.setup GUI ===
;'''Status:''' Under development.

Porting of {{cmd|r.li.setup}} in wxPython.
Some screenshots of developing version

<center>
<gallery perrow=2 widths=300 heights=200>
Image:Rlisetup_first_frame.png | The first windows where you can select existing configuration file or create new one
Image:Rlisetup wizard first page.png | First window of wizard
Image:Rlisetup wizard keybord sampling frame.png | Choose the sampling frame
Image:Rlisetup_wizard_sampling_areas.png ‎| Choose the type of sampling area
</gallery>
</center>

=== Help browser ===

'''Status:''' development not started yet.

For browsing manual pages is currently used web browser, the goal is to design integrated help system.
: HB: ''We used to have one of these for viewing the help pages of Tcl/Tk NVIZ. We dropped it because it was a pain to maintain and generally outside our core mission so a distraction.''

== Known issues ==

* See and report in trac: [http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&component=wxGUI&order=priority List of open issues]

=== Platform specific ===

For the GUI to know what platform it's on, and therefore apply platform specific commands (e.g. append '.exe' to programs) it has to test what platform it is running on. Here we take the experimental approach to learning what's best to use. Please add or generalize this list as you can.

Platform information - start Python from the command line then issue

<source lang="python">
import sys
sys.platform

import os
os.name
os.environ['OS']

import platform
platform.system()
</source>

* Results:

{| border="1" class="wikitable" style="text-align:center"
! Platform
! sys.platform
! os.name
! os.environ['OS']
! platform.system()
|-
| 32bit GNU/Linux
| linux2
| posix
| ''n/a''
| Linux
|-
| 64bit GNU/Linux
| linux2
| posix
| ''n/a''
| Linux
|-
| 32bit Mac OSX (PowerPC G4)
| darwin
| posix
| ''n/a''
| Darwin
|-
| 64bit Mac OSX (Intel)
| [1] see note
| ?
| ?
| ?
|-
| 32bit MS Windows XP
| win32
| nt
| Windows_NT
| Windows
|-
| 64bit MS Windows Vista
| win32
| nt
| Windows_NT
| Windows
|-
| 32bit MS Windows XP (Cygwin)
| win32
| ?
| ?
| ?
|}

[1] On Fri, May 29, 2009 at 10:49 PM, William Kyngesburye wrote:
: ''Right now the GUI only runs 32bit, even if the rest of GRASS is 64bit, because it's not yet possible for wxPython to be 64bit. It comes out the same as PPC 32bit - no distinction between ppc/intel or 32/64 bit, it's all darwin. (yes, I checked, and I have a custom 64bit python executable to verify)''

== General GUI Design ==

=== Layout ===

For some users, the current approach of separate windows (SDI) leads to a windows flooding. Especially on large monitors or dual screen systems catching the wxGUI windows can be tedious when they appear on separate monitors (depends on windows manager, the much used KDE scatters typically the wxGUI windows all over the screen real estate). Almost each task generates a new wxGUI window which is freely floating around on the screen: [http://grass.osgeo.org/grass63/screenshots/images/wxgrass_digit-03.png example 1] and [http://grass.osgeo.org/grass63/screenshots/images/wxgrass_digit-01.png example 2]. On a dual-screen this may sum up to 50cm of distance!

'''Proposed solutions:'''
* implement ''optional'' layout similar to QGIS (with a legend attached to each display) or [http://sourceforge.net/dbimage.php?id=215336 GSDView] etc) (see figure below)
* implement ''optional'' magnetic docking of the layer manager and display windows to keep the windows closer
* do not allow module windows to stay open. That is, get rid of the apply button and force each window to close when OK is pressed (QGIS/ArcGIS approach). This leaves only the display(s) and single legend/layer manager on desktop.
* If you otherwise wish to continue using your current WM, file a bug report with them asking for better multi-head support and get the problem fixed at the source. (there probably already is a bug filed with tips in it)

<center>
{|
|-
| [[Image:Wxgui_current.png|350px|thumb|center|Current wxGUI layout with detached window components]]
| [[Image:Wxgui_proposal.png|350px|thumb|center|'''Proposal''' for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus)]]
|-
|}
</center>

'''New solution: see [[WxGUI#Data_Catalog]] above.'''

====What others do====

'''SDI: (each document opened in application occupies a window on the desktop)'''
* GRASS: display window for each document (i.e., set of maps displayed) opened on desktop; one legend/layer manager window for all display windows; ; each module/function opens a separate window on the desktop
* QGIS: display window for each document (i.e., set of maps displayed) opened on the desktop; legend/layer manager window attached to each display window; each module/function opens a separate window on the desktop (e.g. http://grass.osgeo.org/grass61/screenshots/images/qgis08_grass6_toolbox.png)
* ArcGIS: similar to QGIS with combined legend/display for each document (set of maps displayed); each module/function opens a separate window on the desktop (e.g. http://upload.wikimedia.org/wikipedia/en/9/92/ArcMap.jpg)
* MapInfo (pre Pitney Bowes): each document opens a map display window on the desktop; single legend/toolbox opened on the desktop controls all visible documents (i.e., map displays); each module/function opens a separate window on the desktop (similar to current GRASS layout)

'''MDI: (a single frame is opened for the application on the desktop; all documents opened inside the application frame)'''
* SAGA: single application frame opened on the desktop; all documents (display windows) open inside application frame; one legend/layer manager for all display windows; each module/function opens a separate window inside the frame (http://www.saga-gis.uni-goettingen.de/html/images/bild8.gif and http://sourceforge.net/dbimage.php?id=44455)
* Ossim: single application frame opened on the desktop; all documents (display windows) open inside application frame; one legend/layer manager for all display windows; each module/function opens a separate window inside the frame (http://www.ossim.org/OSSIM/Albums/Pages/ImageLinker.html)
* Idrisi: similar to SAGA and Ossim (http://www.clarklabs.org/products/idrisi-taiga.cfm)
* MapInfo (Pitney Bowes): Seems to be like Saga (http://www.pbinsight.com/support/training/video-tutorials/)

'''''See also'''''
* Solution to the problem: [http://www.wxwidgets.org/manuals/stable/wx_wxlayoutalgorithm.html wxLayoutAlgorithm]
* [http://en.wikipedia.org/wiki/Multiple_document_interface Multiple document interface] (MDI, windows reside under a single parent window)
* [http://en.wikipedia.org/wiki/Single_document_interface Single document interface] (SDI, separate windows, currently used for wxGUI)
* and [http://en.wikipedia.org/wiki/Human_interface_guidelines Human interface guidelines] (HIG)

== Useful links ==

* [http://www.poromenos.org/tutorials/python 10 minutes Python tutorial] for programmers of other languages

== References ==

* [[User:Landa|Martin Landa]]: [http://gama.fsv.cvut.cz/~landa/publications/2008/gis-ostrava-08/paper/landa-grass-gui-wxpython.pdf New GUI for GRASS GIS based on wxPython] ([http://gis2008.com/indexe.html GIS Ostrava 2008], January 27-30, 2008, Ostrava, Czech Republic)
* [[User:Landa|Martin Landa]], Cristina Moretto, Michele Zanolli, Luca Manganelli and Markus Neteler: [http://gama.fsv.cvut.cz/~landa/publications/2008/gfoss-it-08/paper/grass-gfoss-tn.pdf wxPython-based GUI for GRASS GIS] ([http://gama.fsv.cvut.cz/~landa/publications/2008/gfoss-it-08/prezentazione/perugia-grass-gui-wxpython.pdf presentation]) ([http://www.grassmeeting2008.unipg.it IX Meeting degli Utenti Italiani di GRASS - GFOSS], February 20-22, Perugia, Italy)

{{wxGUI}}

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

[http://www.prlog.org/11289974-phone-number-lookup-verizon-phone-number-reverse-lookup-to-get-information-you-need-quickly.html phone number lookup]

WxNviz

2011-12-30T20:58:48Z

⚠️Reverse22:

Back to [[WxPython-based GUI for GRASS|wxGUI]] page.

See also {{cmd|wxGUI.Nviz|version=70|desc=manual page}}.

'''wxNviz''' is a [[wxGUI]] extension which allows users to realistically render multiple surfaces (raster data) in a 3D space, optionally using thematic coloring, draping 2D vector data over the surfaces, displaying 3D vector data in the space, and visualization of volume data (3D raster data).
__TOC__
== Screenshots ==
<center>
<gallery perrow=3 widths=200>
Image:Wxnviz-alpha-0.png|2008-06-27: Display raster map from layer tree in 2.5D (surface)
Image:Wxnviz-alpha-1.png|2008-07-05: Support for vector data (2D lines) added
Image:Wxnviz-alpha-2.png|2008-07-26: Support for vector point data
Image:Wxnviz-alpha-3.png|2008-08-02: 3D vector data support
Image:Wxnviz-alpha-4.png|2008-08-09: Initial support for volumetric data
Image:Wxnviz-lmgr.png|2010-05-31: 3D view tools window integrated into Layer Manager
Image:Wxnviz-light.png|Lighting control panel in Layer Manager (2010-06-17)
Image:Wxnviz-fringe.png|Fringe control panel in Layer Manager (2010-06-23)
Image:Wxnviz-redirect.png|Redirect messages to wxGUI (2010-08-08)
Image:Wxnviz-volumes.png|Displaying raster (surface), 2D vector and 3D raster (volume) in the 3D space (2010-08-16)
Image:WxNviz surface page.png|Surface page of WxNviz modified (2011-06-02)
Image:WxNviz_constant_surface_page.png|Constant surface page added (2011-06-02)
Image:WxNviz_lighting.png|Lighting fixed (2011-05-02)
Image:WxNviz_cutting_planes_1.png|Cutting planes (shading blend) (2011-06-10)
Image:WxNviz_cutting_planes_2.png|Cutting planes (shading top color) (2011-06-10)
Image:WxNviz_view_page.png|View page modified (2011-06-10)
Image:Nviz_cmd_cutting_planes.png‎|Picture of surfaces cut by two planes (generated by nviz_cmd) (2011-06-30)
Image:WxNviz_generate_command.png‎|Command for nviz_cmd generated by wxNviz (2011-07-01)
Image:WxNviz_north_arrow.png‎|North Arrow implemented (2011-07-08)
Image:WxNviz_volumes.png‎|Colored isosurfaces with transparency (2011-07-08)
Image:WxNviz_volume_slices_1.png‎|Partially transparent slice (2011-07-14)
Image:WxNviz_volume_slices_2.png‎|Combination of slices and isosurface (2011-07-14)
Image:WxNviz_overlays.png‎|Raster legend, text label and north arrow (2011-07-22)
Image:WxNviz_thematic_points_colors‎.png|Thematic mapping (colors) for points (2011-08-05)
Image:WxNviz_colorrules_dialog.png|Dialog for {{cmd|v.colors}} opened from 3D view (2011-08-05)
</gallery>
</center>
== Animations ==
{{YouTube|AByFPKHvgu4|desc=Using fly-through mode for creating animation}}

== Video tutorials ==

{{YouTube|ib1-mBbWkv4|desc=Loading data, settings layer properties}}
{{YouTube|ZLDstyumxv0|desc=Visualizing fringes and north arrow}}
{{YouTube|CmK-fEyf2SY|desc=3D raster maps (volumes) in the space (isosurface and slice mode)}}
{{YouTube|13wj5KWEweE|desc=Color thematic mapping}}

=== Older tutorials (2010) ===

{{YouTube|Ej_rBc9sgvE|desc=Loading data, settings layer properties}}
{{YouTube|iWyaBL2Krto|desc=Visualizing fringes}}
{{YouTube|ioE_hHMHqKg|desc=3D raster maps (volumes) in the space}}

== Ideas ==

* Fog support (see [http://gpwiki.org/index.php/OpenGL:Tutorials:Tutorial_Framework:Light_and_Fog], [http://www.swiftless.com/tutorials/opengl/fog.html], [http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=16])
* Vertical labels (take from geonames.org point data): like in http://tev.fbk.eu/marmota/blog/?p=82
* Second interactive light source for isosurface visualization
* Tick marks and coordinate values to x,y,z axis when drawing fringe

<strike></strike>

== Known issues ==

#List of [http://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&order=priority&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone&keywords=~wxNviz open] and [http://trac.osgeo.org/grass/query?status=assigned&status=closed&order=priority&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone&keywords=~wxNviz closed] tickets
#<strike>Adding vector data crashes wxGUI on Mac</strike>
#<strike>Viewing height sometimes sets to 1 after switching to 2D and back to 3D View (or with the simultaneous 2D view - very nice feature) and even after View is reset, it keeps getting back at 1 each time the slider is touched</strike>
#:Fixed in {{rev|46208}}
#Isosurfaces tested with Nags Head time series data (I will provide link) don't seem to be working, after setting 3D region and adding 3D raster nothing gets drawn, when moving the related DEM around only line rectangle shows instead of a box.
#Adding draw, draw current and clear button may be useful
#Thematic mapping is available in GRASS 7 only
#Display region in 3D does not change accordingly to display region in 2D in version <= 6.5
#Appearance:
## I need to click View tab to get the arrow draw, same for the scale bar
##add legend > OK: nothing gets drawn in 3D but the legend shows up when I switch to 2D but when I clicked delete scalebar (which was not drawn), my surface disapeared but the legend showed up along with white and black background (which I assume was supposed to be transparent, because when I moved the legend the surface was under it - we already discussed this, it may be my problem, because it works for Michael).
#General
##<strike>when I go from 3D view to 2D and then back to 3D I lose most of my settings </strike>
##similarly, when I add volume to Map layers I lose my view settings and the 3D view goes back to default
#Volumes:
##change of region by g.region seems to be ignored (or I missed something), I had to restart GRASS with the new region to get the 3D region for volumes right. Given that the default top, botom is 1,0, if GRASS starts with the default 3D region settings volumes do not work because there is just one level.
##isosurfaces work with my terrestrial lidar data but the slices don't, it seems that it is due my resolution being 0.3m, when I change it to 1m I get at least some limited slicing
###this may be in ogsf becuase slices in nviz do not work with this data either
#changing color to constant did not change the color of the isosurface

[[Sv:Main Page/sv|sv:Main Page/sv]]

[[Pl:WxNviz/pl|pl:WxNviz/pl]]

[[Pl:WxNviz/pl|pl:WxNviz/pl]]

[[pl:WxNviz/pl|pl:WxNviz/pl]]

== Google Summer of Code ==

=== [[wxNviz GSoC 2008|2008]] ===

* [http://trac.osgeo.org/grass/wiki/SoCProjects#wxNvizdevelopmentforenhanced34Dvisualizationandanalysis Accepted Google Summer of Code 2008 project]

=== [[wxNviz GSoC 2010|2010]] ===

* [http://trac.osgeo.org/grass/wiki/SoCProjects#wxNvizdevelopmentforenhanced34Dvisualizationandanalysis Accepted Google Summer of Code 2010 project]

=== [[wxNviz GSoC 2011|2011]] ===

* [http://trac.osgeo.org/grass/wiki/SoCProjects#CompletionofwxGUINvizextensionfor3DdatavisualizationinGRASSGIS Accepted Google Summer of Code 2011 project]

== See also ==

* http://lists.osgeo.org/pipermail/grass-dev/2008-February/035792.html

{{WxGUI}}

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

[http://www.prlog.org/11289974-phone-number-lookup-verizon-phone-number-reverse-lookup-to-get-information-you-need-quickly.html phone number lookup]

WinGRASS 6 Current Status

2011-12-30T20:58:34Z

⚠️Reverse22:

__TOC__

See also '''[http://trac.osgeo.org/grass/wiki/BuildingOnWindows http://trac.osgeo.org/grass/wiki/BuildingOnWindows]'''

This page describes the current status of winGRASS development:

* '''[http://grass.osgeo.org/download/index.php#g64x Lastest downloads]'''

* ''Older precompiled winGRASS/Cygwin packages are available for [http://grass.itc.it/grass63/binary/mswindows/cygwin/ GRASS 6.3], ''
* ''Older native winGRASS packages [http://geog-pc40.ulb.ac.be/grass/wingrass/ GRASS 6.3],''

== Current status - Summary ==

The native windows port of GRASS is slowly coming to a stage where it can be considered mature beta status. All main functions seem to work, but much more testing is needed. The port is of the current SVN release branch for GRASS 6.4.0. The only prior native port of an earlier version is 6.3.0.

The general idea is to reach a point where GRASS runs in MS-Windows without any kind of UNIX emulation. Currently this is possible but limits the use to compiled modules, as scripts are all of UNIX-shell type and cannot run within a Windows cmd.exe environment without a series of UNIX tools such as a shell, awk, sed, etc. So in order to run such scripts a collection of UNIX-like tools needs to be installed, such as Msys or Gnuwin32+Shell.

Another major feature not available in the MS-Windows version are the old-style interactive X monitors (i.e. the x0, PNG, PS, Cairo, etc, monitors opened with '<tt>d.mon x0</tt>'). Only direct rendering works currently. Display is thus "limited" to the Tcl/Tk and wxPython GUIs (the latter might still need some cleanup of UNIX-specific code). Modules like i.points and d.zoom will not work due to their interactive monitor requirements (see [[#Known_Issues]]).

== Installing binary snapshots ==

Regular binary snapshots for windows are available from the main GRASS [http://grass.osgeo.org/download/index.php download page].

== Compiling by yourself ==

=== Guide ===

All informations for compiling yourself are in '''''[http://trac.osgeo.org/grass/wiki/CompileOnWindows Compiling GRASS on MS-Windows]'''''

=== Nullsoft installer ===

See http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/mswindows

[[Image:Wingrass63 installer1.jpg|220px|New winGRASS installer 1]]
[[Image:Wingrass63 installer2.jpg|220px|New winGRASS installer 2]]
[[Image:Wingrass63 installer3.jpg|220px|New winGRASS installer 3]]

== Known Issues ==

See also
* [https://trac.osgeo.org/grass/wiki/CompileOnWindows#Errata WinGrass current bug list],
* [http://n2.nabble.com/Grass---Win-f1928820.html winGRASS Mailing list archives],

=== Flagrant ===

* '''wxVdigit''' (vector digitizer) doesn't work. see {{trac|541}}.
: Workaround: Use the old Tcl/Tk {{cmd|v.digit}} module, simply type <tt>v.digit</tt> at the <tt>Cmd></tt> prompt in the Layer Manager GUI.

* '''wxNviz''' (3D visualization) works, but there are some issues. see {{trac|541}}, {{trac|1141}}.
: Please test the new wxNviz on Windows and report any issues. For a workaround: Use the Tcl/Tk {{cmd|nviz}} module, simply type <tt>nviz</tt> at the terminal prompt in shell window.

* '''Spaces in path names'''
** Installation directory: WinGRASS uses the MSys software to run on MS-Windows. Unfortunately MSys isn't very interested in supporting spaces in path names, but WinGrass-development in the last few months tried to get this ready. Currently the default installation directory is c:\Programm Files\Grass-64\
** GIS data directory: It is generally safe to have spaces in your GIS data directory path, but there are few spots where it might still get confused and chop the path off at the first space. If you find one please report it to the bug tracker, the sooner we know about it the sooner we can fix it.
: Workaround: if this is causing problems for you the quick solution is to rename the GIS data directory and replace all spaces with underscores (_).

* The '''{{cmd|r.li}}''' suite and '''{{cmd|d.mon}}''' monitors won't work. These use UNIX pipes and won't work on Windows without a lot of work.

=== Won't fix (at least not immediately) ===

Issues listed here are rather impossible to fix due to the different nature of native Windows. Or, lend us a hand and let's try harder!

* No monitors

This means that you cannot launch any monitor launched with d.mon (x0, PNG, PS, etc). The only way you can render is directly to a file. But you cannot directly display to screen from the command line. This will be solved in GRASS 7 with a new rendering system and possibly via the new wxgrass GUI. So no work will probably be put into this until then.

The absence of monitors also makes impossible the use of interactive modules based on these monitors, such as:

** i.class. However, See http://trac.osgeo.org/grass/browser/grass-addons/gui/wxpython/wx.class for a start
** i.ortho.photo/photo.2image
** i.ortho.photo/photo.2target
** i.points
** i.vpoints

i.points and i.vpoints have already been replaced by the gis.m georectifier module (File -> Georectify). In replacement of i.class you can digitize training areas with v.digit. This will not however, give you all the information i.class provides, such as the histogram of the region, the statistics and the display of matches. These modules will have to be rewritten to clearly separate display and backend parts, so that the backend can be run on the command line or from any GUI frontend. '''Volunteers needed.'''

Another module affected is d.vect.thematic which uses monitors. This will hopefully be replaced by a C-version in a not too far future.

* Scripts need *nix-like shell

All current GRASS 6.4 scripts are written in shell language. This means they need a shell, and several related tools (awk, sed, etc), to function. The actual WinGrass 6.4-installer includes Msys, so all shell-scripts should work.

In 7.0, these scripts have been rewritten in Python, thus totally eliminating the need for any shell.

=== Platform specific issues ===

==== XP/2000 ====

If the GRASS GUI startup fails with "[Error 14001]" in the MSys terminal on a relatively fresh install of XP, the solution is to install some missing DLL files from Microsoft which apparently don't come standard.
If these library files are missing, [http://www.qgis.org Quantum GIS] and other software from the [http://osgeo4w.osgeo.org OSGeo4W] stack will likely encounter the same trouble as well.

You'll need to install two files: (in order)

* MS's Windows Installer 3.1 Redistributable (v2)
: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=25

* MS's .net framework 3.5 downloader
: http://www.microsoft.com/download/en/details.aspx?id=21

It is recommended to run Windows updates after installing these.

==== Vista ====

* <strike>sometimes {{cmd|r.patch}} fails: {{trac|118}} [ticket closed]</strike>

==== Windows7 ====

* Missing MSVCR71.dll on startup
: Try installing Microsoft's .net frameworks as described above in the XP section. If that doesn't solve it, try these instructions found in a web search: http://i.justrealized.com/2009/how-to-fix-missing-msvcr71dll-problem-in-windows/

=== ToDo ===

==== Installer ====

* <strike>change the Uninstall icon</strike>
* <strike>fix the language errors in the StartMenu link's descriptions</strike>
* <strike>change the name of the South-Dakota sample database to Spearfish60</strike>
* <strike>add a GRASS Command Line link (cmd.exe) into the GRASS StartMenu group</strike>
* create a GRASS Addons installer or integrate the GRASS Addons in the current installer as downloadable options.
: See {{cmd|g.extension|version=65}} in GRASS 6.5+

==== Dependencies ====

===== GRASS Dependencies =====

* <strike>add the Indipendent JPEG support to GRASS *</strike>
* add the FFMPEG support in GRASS (reports an error in building OGSF library; probably needs to specify -lavutil in gcc command) ***
* add the NLS support in GRASS (needs gettext)
* add the wxWidgets support in GRASS (for the wxPython GUI v.digit replacement)

===== GDAL Dependencies =====

* add the ECW support in GDAL */**
* add the JPEG2000 support in GDAL (through Jasper or Kadaku *) **
* add the OGDI support in GDAL *
* add the MrSID support in GDAL */**

===== GRASS and GDAL Dependencies =====

* add the Xerces support in both GDAL and GRASS *
* add the ODBC support in both GDAL and GRASS */**
* add the MySQL support in both GDAL and GRASS */**

===== Miscellaneus Dependencies =====

* add the OpenSSL support in both PostgreSQL and SQLite *
* <strike>add the AVCE00 tools (build from source in minGW)</strike>
* <strike>add the E00compr tools (build from source in minGW)</strike>
* <strike>add the GPSBabel tool (use prebuilt binaries from GPSBabel Web Site)</strike>

<br>
<nowiki>*</nowiki> needs to build related libraries from source in MinGW
<br>
<nowiki>**</nowiki> needs to check the licences first
<br>
<nowiki>***</nowiki> FFMPEG has been already succesfully built on MinGW

==== Internal Libraries ====

* parser: find out why launching a module from the command line without parameters does not call module GUI

==== Vector modules ====

* v.in.ascii crashes on files with irregular line length (see [http://lists.osgeo.org/pipermail/grass-dev/2008-February/035268.html this thread])

==== Raster modules ====
* <strike>r.terraflow does not compile</strike> fix backported 27/3/2008
: This seems to be due to the use of the function getrusage() which is not supported under MinGW. Check this octave patch [http://osdir.com/ml/gnu.octave.maintainers/2006-03/msg00083.html email thread].

==== Other modules ====
* r.li moduels do not compile (they require UNIX sockets, much the same situation as the display monitors)
: Use the older r.le modules instead.

==== GRASS Addons ====
* compile the GRASS Addons

==== TclTk issues ====

* var=val style argument is not valid for batch files: equal sign is a separator like a space. http://support.microsoft.com/?kbid=71247 http://www.gatago.com/alt/msdos/batch/17358926.html
** Could you give an example of where this is a problem ?
* file command returns bad code (catch is needed): http://sources.redhat.com/ml/insight/2003-q1/msg00079.html
** catch {file copy}
** catch {file delete}
** catch {file rename -force} does not work. Delete old file first: catch {file delete}; catch {file rename}
** exec a batch file doing redirection (>&2, 2>&1)
* no -permissions file attributes
** catch {file attributes -permissions}

==== Miscellaneous ====

* metacharacter escape in "sh -c '$cmd'"
* modules not working: <strike>v.neighbors, v.kernel, r.cost</strike>
* <strike>Cannot open Help pages.</strike>
* Have to type "exit" in the console to save ~/.grassrc file. Then, close gis.m to finish the session.
* A previous installation of grass under cygwin is likely to cause problems with WinGrass. Follow the directions to remove cygwin at http://cygwin.com/faq/faq-nochunks.html#faq.setup.uninstall-all

The following items cannot be fixed in the near future:
** can't read "_data(.gronsole.gronsole,4,donecmd)": no such element in array error
*** Could you be more precise about this error ? When does it occur ?

== Dealing with shell scripts or .bat files ==

Bourne shell scripts require MSys (or some other Bourne shell), but you don't need to start GRASS from MSys.

The main issue with scripts is that Windows doesn't understand the "#!" notation used to specify the interpreter.

All of the supplied scripts in $GISBASE/scripts have a corresponding .bat file in $GISBASE/bin which invokes script via %GRASS_SH%. This allows you to run those scripts from the Windows command prompt.

If you write scripts of your own, you need to either add a corresponding .bat file, or give the script a .sh extension and associate that with the shell, e.g. via the ftype and assoc commands. You can use the PATHEXT variable to eliminate the need to type the extension.

== Other libraries ==

GDAL
* lib/gis/OBJ.*/fmode.o is needed for any GRASS related modules.
* modified ltmain.sh to install binary files from wrapper scripts.
* see also [http://trac.osgeo.org/gdal/wiki/BuildingWithMinGW GDAL Building With MinGW]

== Related efforts ==

* http://trac.osgeo.org/osgeo4w/wiki/pkg-grass

[[Category: Development]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

[http://www.prlog.org/11289974-phone-number-lookup-verizon-phone-number-reverse-lookup-to-get-information-you-need-quickly.html phone number lookup]

Vector Database Management

2011-12-30T20:58:23Z

⚠️Reverse22:

''This page is a work in progress.<BR>Please contribute if you have experience with anything that is still poorly documented.''

==Vector data processing==

* See the GRASS {{cmd|vectorintro}} vector data processing help page.
* See also the GRASS {{cmd|databaseintro}} Database management help page.

* See also the [[Openoffice.org with SQL Databases]] wiki page

===Database Support===

==== AsciiText (.csv, etc.) ====

The GRASS 6 vector engine supports the following databases:
* {{cmd|v.in.ascii}} module help page
* {{cmd|v.out.ascii}} module help page

==== DBF ====
In GRASS 6, DBF is the default (local) DB used for GRASS vector attributes. It is easy to use but with the simplicity comes limited features. Such limits are 10 chars per column name and no support for SQL calculations in SELECT statements.

* GRASS {{cmd|grass-dbf}} DBF driver help page

==== SQLite ====

SQLite is another local database format, but much more featureful than DBF. It basically combines the power of real SQL databases with the advantage of local data storage (no server needed). A nice tool to directly work in the SQLite database is [http://sqlitebrowser.sourceforge.net/ SQLite Database Browser].
In GRASS 7, SQLite is the default (local) DB used for GRASS vector attributes.

* GRASS {{cmd|grass-sqlite}} SQLite driver help page
* [http://www.sqlite.org SQLite Homepage]

==== MySQL ====
* GRASS {{cmd|grass-mysql}} MySQL driver page
* GRASS {{cmd|grass-mesql}} MSQL embedded driver page
* [http://www.mysql.com MySQL Homepage]

==== PostgreSQL ====
* GRASS {{cmd|grass-pg}} PostgreSQL driver page
* [http://www.postgresql.org PostgreSQL Homepage]

==== FileMaker Pro ====

''William Kyngesburye wrote on the grass-user mailing list:''

I think the key to access FileMaker DBs from GRASS is that the FileMaker ODBC connector is for OSX's iODBC, not UnixODBC.

GRASS 6 has an iODBC configure option. It's the same --with- odbc-* options, it just tries iodbc if it can't find unixodbc.

==== Oracle ====

This has been reported to work. Try ODBC and search the mailing list archive.
The connection is done via OGR.

==== ODBC ====
* External DB support via ODBC (e.g. FileMaker Pro)
* unixODBC is required to make it work
* to configure you could use the graphical frontend '''ODBCConfig''' to configure your ODBC connection.

Example-entry in '''~/.odbc.ini''' for usage of ODBC with PostgreSQL
[dbname]
Description = PostgreSQL database for my project
Driver = postgres
Trace = No
TraceFile =
Database = mydb
Servername = myserver
UserName = myusername
Password = mysecretpasswd
Port = 5432
Protocol = 9.0.3
ReadOnly = No
RowVersioning = No
ShowSystemTables = No
ShowOidColumn = No
FakeOidIndex = No
ConnSettings =

Additionall you need to define the libraries to use for the different drivers in '''/etc/odbcinst.ini'''.
[postgres]
Description = ODBC for postgres
Driver = /usr/lib/unixODBC/libodbcpsql.so
Setup = /usr/lib/unixODBC/libodbcpsqlS.so
FileUsage = 1

* GRASS {{cmd|grass-odbc}} ODBC driver page

=== Concepts and jargon ===

* [[GRASS 6 Terminology]]
* [http://en.wikipedia.org/wiki/Table_%28database%29 Table]
** Table column
** Table row
** Vector map layer
** Each vector file has a special data field named "cat" (derived originally from "category"), filled with integers, that serves to identify each vector object. The 'cat' field also serves as a "key field" that can link each vector object with a corresponding record in an attributes table of a database (NB: 'cat' values do NOT have to be unique for vector objects, but DO have to be unique in an attributes table, permitting both one-to-one and many-to-one relationships). The attributes table must contain a key field, filled with integers (only integers are permitted to serve as key fields in GRASS), that matches the values in the vector 'cat' field.
** A vector can be linked with more than one attribute table, using LAYERS. By default, every vector file has a '''LAYER 1''' with a 'cat' field, filled with integers to identify each vector object. Additional *LAYERS*, along with their associated 'cat' fields, can be created using v.category. Each '''LAYER''' has its own independent 'cat' field that can be used to link with a separate attributes table.
** For example, a vector file of cities can have *LAYER 1* whose 'cat' field links the vector points with an attributes table of demographic data; it can also have a '''LAYER 2''', with an associated 'cat' field (independent of the 'cat' field of '''LAYER 1'''), linked to a different attributes table of economic data. Values in the 'cat' fields of different LAYERS can be the same or different. The 'cat' values and linked attributes table can be queried independently for each '''LAYER'''. In the example, one can query the cities by population from the demographics attributes table linked with the 'cat' field of '''LAYER 1''', or query the cities by household income from the economic attributes table linked with the same vector points through the 'cat' field of '''LAYER 2'''. _MichaelBarton - 12 Nov 2005_

===Common tasks===

Background info find in {{cmd|vectorintro}} Vector data processing in GRASS GIS.

* Connect a DB ({{cmd|db.connect}}, {{cmd|v.db.connect}})
* Copy a table ({{cmd|db.copy}})
* Copy selected columns from a table
* Create a new table ({{cmd|v.db.addtable}})
* Create a new column ({{cmd|v.db.addcol}})
* Extract data via SQL query ({{cmd|v.extract}}, {{cmd|db.select}})
* Low level access to DB
* The {{cmd|db.execute}} module
* Populate a DB ({{cmd|v.db.update}} etc.)
** The {{cmd|v.to.db}} module

===More Help===

* {{cmd|database}} module help pages
* {{cmd|vector}} module help pages
* GRASS {{cmd|sql}} query help page
* [http://grass.osgeo.org/grass57/tutorial/links.html SQL reference links]
* [http://dev.mysql.com/doc/mysqld-version-reference/en/mysqld-version-reference-reservedwords-5-0.html MySQL reserved words list]

[[Category:Documentation]]
[[Category:Vector]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

[http://www.prlog.org/11289974-phone-number-lookup-verizon-phone-number-reverse-lookup-to-get-information-you-need-quickly.html phone number lookup]

Vector Data

2011-12-30T20:58:12Z

⚠️Reverse22:

= Vector Data Structures =

[http://en.wikipedia.org/wiki/Caveat_emptor Caveat emptor!] Different terminology (eg. vertex, node, point or edge, line, line segment, link) due to different vocabulary in the underlying theories (e.g. linear algebra, graph theory, network theory) of vector data can already lead to great confusion.

The confusion is greatly enhanced by very different concepts and implementations of vector data.

Hence a discussion of the currently most widely vector data structures and formats in the geoiformatics field is surely not bad, IMO. Naturally the focus is GRASS and FOSS4G centric, maybe almost too formal form a user's point of view, and yet certainly way too informal from a programmers point of view.

The reader is assumed to be familiar with the section {{cmd|vectorintro}} (Vector data processing in GRASS GIS) in the GRASS GIS Reference Manual, the Wiki topics [[Vector FAQ GRASS6]] and [[Help with 3D#Vector_3D_point_data]].
Also reading [http://mapserver.gis.umn.edu/docs/reference/vector_data Vector Data Access] from the Mapserver Documentation does not hurt.

== GRASS 6 Vector Architecture ==

[[Image:Grass_vector_line.png]]
[[Image:Grass_vector_area.png]]

The GRASS vector data model includes the description of topology, where besides the coordinates describing the location of the primitives (points, lines, boundaries and centroids), their spatial relations are also stored. In general, topological GIS require a data structure where the common boundary between two adjacent areas is stored as a single line, simplifying the map maintenance.

The following vector objects are defined:

* point
* line: directed sequence of connected vertices with 2 endpoints called nodes

* boundary: the border line to describe an area
* centroid: a point within a closed boundary (missing centroids can be created with '''v.centroids''')
* area: the topological composition of centroid and boundary

* face: a 3D area;

Further following vector objects are defined, but not yet fully implemented/used:
* kernel: a 3D centroid in a volume (exists, but currently mostly unused)
* volume: a 3D corpus, the topological composition of faces and kernel (not yet implemented)

'''Note:''' all lines and boundaries can be polylines (with nodes/vertices in between). {{cmd|v.build.polylines}} creates these.

=== Data Structure ===

a vector map '''<some_vector>''' is stored in the directory '''$MAPSET/vector/<some_vector>'''.
This directory normally contains the files listed below.

* /[http://download.osgeo.org/grass/grass6_progman/Vector_Library.html#head_file_format head]: ASCII file with header information; this is more or less the stuff that '''v.info''' displays.

* /[http://download.osgeo.org/grass/grass6_progman/Vector_Library.html#vlib_attributes dbln]: ASCII file that link(s) to attribute table(s)

* /hist: ASCII file with vector map change history. '''v.info -h''' can be used to display this file.

* /[http://download.osgeo.org/grass/grass6_progman/Vector_Library.html#coor_file_format_specification coor]: binary file for storing the coordinates

* /[http://download.osgeo.org/grass/grass6_progman/Vector_Library.html#topo_file_format topo]: binary file for topology

* /[http://download.osgeo.org/grass/grass6_progman/Vector_Library.html#vlib_cidx cidx]: binary category index

'''Note:''' The creation of certain files can be disabled. The '''-t''' flag supported by v.in.ogr and v.in.ascii disables the creation of an attribute table. The '''-b''' flag supported by {{cmd|r.to.vect}} and {{cmd|v.in.ascii}} disables the creation of a topology file. This is [http://www.intevation.de/rt/webrt?display=History&serial_num=3877 needed] and useful e.g. for very large datasets (> 3 million points). The user is expected to understand what s/he is doing.

=== Linear Reference System (LRS) ===

/*TODO*/

* GRASS GIS Manual: {{cmd|lrs}} - Linear Reference System Tutorial
* R. Blazek: [http://www.j-geoinfo.net/Content/fulmar05/IJG_095-100.pdf Introducing the Linear Reference System in GRASS] (March 2005, Int'l Journal of Geoinformatics, Vol. 1(3), pp. 95-100)
* R. Blazek: [http://gisws.media.osaka-cu.ac.jp/grass04/viewpaper.php?id=50 Introducing the Linear Reference System in GRASS] (Sept 2004, Conference Paper)
* http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/vector/v.lrs/MAIL
* PostGIS Reference, Chapter 6 [http://postgis.refractions.net/docs/ch06.html#id2646260 PostGIS Extensions: 6.2.7. Linear Referencing]


=== Specs ===
* http://download.osgeo.org/grass/grass6_progman/Vector_Library.html#background ([http://download.osgeo.org/grass/grass6_progman_pdf/ PDF version])
* R. Blazek, M. Neteler, R. Micarelli: [http://www.ing.unitn.it/~grass/conferences/GRASS2002/proceedings/proceedings/pdfs/Blazek_Radim.pdf The new GRASS 5.1 vector architecture] (Sept 2002, Conference-Paper)
* R. Blazek: [http://trac.osgeo.org/grass/browser/grass/trunk/doc/vector/TODO GRASS 6 vector TODO] (May 2006) (see also [http://www.intevation.de/rt/webrt?display=History&serial_num=3877 RT#3877])
* OGR documentation: [http://www.gdal.org/ogr/drv_grass.html GRASS driver]

=== GRASS ===

* http://www.gdf-hannover.de/lit_html/grass60_v1.2_en/node46.html
* J. Čepický, M. Landa: [http://gislab.dirap.unipa.it/grass_meeting/articoli/grass-digit.pdf GRASS GIS Digitization Tools] (Feb. 2007, Conference Paper) focuses on v.digit, v.edit and QGIS/GRASS

== ESRI Shapefile ==

A [http://en.wikipedia.org/wiki/Shapefile shapefile] stores non-topological geometry and attribute information for the spatial features in a data set. The geometry for a feature is stored as a shape comprising a set of
vector coordinates.

The following vector objects are defined:

* Point
* MultiPoint: a set of points

* PolyLine: A PolyLine is an ordered set of vertices that consists of one or more parts. A part is a connected sequence of 2 or more points. Parts may or may not be connected to one another. Parts may or may not intersect one another.

* Polygon: A polygon consists of 1 or more rings. A ring is a connected sequence of 4 or more points that form a closed, non-self-intersecting loop.

* PointM: Point plus support for a Measure (cf. [http://lists.maptools.org/pipermail/gdal-dev/2002-December/000047.html Measure in shape file])
* PolyLineM: Point plus support for a Measure
* PolygonM: Point plus support for a Measure
* MultiPointM: MultiPoint plus support for a Measure

* PointZ: 3D capable version of PointM
* PolyLineZ: 3D capable version of PolyLineM
* PolygonZ: 3D capable version of PolygonM
* MultiPointZ: 3D capable version of MultiPointM

* MultiPatch: consists of a number of surface patches, each patch describes a surface. [http://en.wikipedia.org/wiki/Triangulated_irregular_network TIN]-like.

'''Note:''' the "measure" or the z-coord may always be omitted, by specifying the null element. e.g. a PolyLineZ(x,y,0,0) is the same as a PolyLineM(x,y,0) which is the same as PolyLine(x,y)

'''Note:''' Unlike [http://shapelib.maptools.org/shp_api.html Shapelib] OGR does [http://www.gdal.org/ogr/drv_shapefile.html not support] MultiPatch, PointM, PolyLineM, PolygonM, MultiPointM are [http://www.gdal.org/ogr/drv_shapefile.html not supported] by OGR. Hence GRASS also does not support them. Postgres has an almost complete support (with some limitations, and lacking documentation)

=== Data Structure ===

a shapefile '''<some_vector>''' is actually a set of files:
* '''<some_vector>.shp''' vector features
* '''<some_vector>.shx''' feature index data pointing to the vector features
* '''<some_vector>.dbf''' attributes in [http://www.clicketyclick.dk/databases/xbase/format/index.html dBase DB] format
* '''<some_vector>.prj''' ASCII file with projection info in [http://en.wikipedia.org/wiki/Well-known_text WKT] format

* '''<some_vector>.sbn''' optional spatial index file

This set of files is often packed into a zip-compressed archive '''<some_vector>.zip''' or placed into a unique directory '''../<some_vector>/'''

=== Specs ===
* ESRI: [http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf Shapefile Technical Description] (July 1998, Whitepaper) ([http://shapelib.maptools.org/dl/shapefile.pdf mirrored copy])
* ESRI: [http://www.esri.com/library/whitepapers/pdfs/lrds_arcgis.pdf Linear Referencing and Dynamic Segmentation in ArcGIS 8.1] (May 2001, Whitepaper) (has a section called "Routes and Measures", that explains measures in shapefiles)

* OGR documentation: [http://www.gdal.org/ogr/drv_shapefile.html Shapefile Driver]
* http://shapelib.maptools.org/
* http://mapserver.gis.umn.edu/docs/reference/vector_data/shapefiles

== OpenGIS Simple Features ==

[http://en.wikipedia.org/wiki/Simple_Features Simple Features] is a widely implemented non-topological standard. The internal data representation of OGR is closely modeled after it, [http://postgis.refractions.net/ PostGIS] is a PostgreSQL implementation and the [http://dev.mysql.com/doc/refman/5.1/en/spatial-extensions.html Spatial Extensions] of MySQL implement it too, etc.

The following vector objects are defined:

* Point
* LineString
* Polygon
* Multipoint
* Multipolygon
* GeomCollection

=== Specs ===
* OpenGIS: [http://www.opengis.org/docs/99-049.pdf Simple Features Specifications For SQL]
* Adam Gawne-Cain: [http://home.gdal.org/projects/opengis/twohalfdsf.html 2.5 D Simple Features Proposal (OGC 99-402r2)]
* http://www.opengeospatial.org/standards

=== GRASS ===
* {{cmd|v.external}}
* {{cmd|v.in.ogr}}
* {{cmd|v.out.ogr}}

== SVG ==

is a non-topological, non-spatial W3C vector format standard. The following vector objects are defined:

* [http://www.w3.org/TR/SVG/paths.html path]: represents the outline of a shape
* [http://www.w3.org/TR/SVG/shapes.html#LineElement line]: a (directed?) line segment that starts at one point and ends at another.
* [http://www.w3.org/TR/SVG/shapes.html#PolylineElement polyline]: a set of connected straight line segments. typically, it defines open shapes.
* [http://www.w3.org/TR/SVG/shapes.html#PolygonElement polygon]: a closed shape consisting of a set of connected straight line segments.
* rect: defines a rectangle shape
* circle
* ellipse

=== Specs ===
[http://www.w3.org/TR/SVG/ Scalable Vector Graphics (SVG) 1.1 Specification]

=== GRASS ===
* {{cmd|v.out.svg}}
* [[GRASS vector export to Inkscape]]

== GPS receiver vector data ==

* '''waypoint''' (WP): point given by its geographic coordinates (usually, user-defined)
* '''route''' (RT) a sequence of waypoints (usually, user-defined)
* '''track point''' (TP) a point given by its geographic coordinates with a time-stamp
* '''track''' (TR) (Lowrance calls it: '''trail''') is a sequence of '''track points''' recorded by the GPS receiver during a certain time-interval

=== Specs ===
* [http://www.gpsbabel.org/ GpsBabel] Documentation: [http://www.gpsbabel.org/htmldoc-1.3.4/Route_And_Track_Modes.html Route and Track Modes]
: GpsBabel performs GPS format and receiver interchange
* http://www.ncc.up.pt/gpsman/gpsmanhtml/manual/html/GPSMandoc_15.html

=== GRASS ===

* {{cmd|v.in.garmin}}
* {{cmd|v.in.gpsbabel}}
* {{cmd|v.out.gpsbabel}} (in development)

: ''v.in|out.gpsbabel will be renamed/replaced with v.in|out.gps in GRASS 7.''

[[Category: Documentation]]
[[Category: FAQ]]
[[Category: Vector]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

[http://www.prlog.org/11289974-phone-number-lookup-verizon-phone-number-reverse-lookup-to-get-information-you-need-quickly.html phone number lookup]

Vector aggregate values

2011-12-30T20:57:53Z

⚠️Reverse22:

== Introduction ==

GIS users often wish to aggregate the values of one polygon layer into another. Although this is not integrated as a standard tool in GRASS, it is definitely possible. This article introduces two methods to do just that: A simple, quick operation will be described that can take place entirely in GRASS GIS and produces raster maps or, if desired, polygons with aggregated values from two maps and a second, more complex method that uses external editors and creates text files as outputs.

=== Method 1 ===

''written by Daniel Lee''

In this example we assume that we have a vector map of catchment areas and a raster map of precipitation. We want to find out what the sum total of precipitation per catchment area is. This method would also work if the precipitation data were also stored as vector data, but the vector precipitation data would have to be turned into a raster map, just as the catchment areas are converted to rasters in the following steps. Remember to set the region, etc. in GRASS properly.

''' Step 1: Convert catchment area polygons to rasters '''

The polygons are converted to rasters using v.to.rast. The primary key for the polygons should be used as the values for the new rasters. If the polygons were imported from a shapefile, for example, the field FID could be used.

v.to.rast input=CatchmentAreas output=CatchmentAreas_Raster column=FID

''' Step 2: Convert precipitation raster to integer values '''

The tool that we will be using later, r.statistics, requires integer values. Because the precipitation raster is composed of floating point values, we have to convert it to an integer map first. In order to avoid rounding areas in the final results, we also multiply the raster by 100. This way we can divide it by 100 later in order to the original float values back.
If the raster that you want to aggregate into your vectors is already made of integer values or if rounding errors aren't a problem, this step can be changed or left out.

r.mapcalc 'Precipitation_Integer = round (Precipitation * 100)

''' Step 3: Aggregate the precipitation values by summing them in the catchment areas they fall in '''

Now we have two rasters that can be combined. In order to find the sum of the pixels of the precipitation map we use r.statistics.

r.statistics base=CatchmentAreas_Raster cover=Precipitation_Integer method=sum output=Precipitation_by_CatchmentArea

''' Step 4: Extract sums from the new map '''

Now the precipitation sums are aggregated by catchment area, but only as attributes and not as categories in the resulting raster. We now extract the aggregated sums, overwriting the previous raster, by using the "@" function in r.mapcalc. Additionally, the map is divided by 100 to scale the values back, reversing the change we made when we turned the original precipitation map into an integer map.
Don't forget to not divide by 100 if you didn't multiply by 100 in step 2.

r.mapcalc 'Precipitation_by_CatchmentArea = @Precipitation_by_CatchmentArea / 100'

''' Step 5: Convert the aggregated precipitation raster to a vector map. '''

This procedure should already be familiar for those who work with vector maps. If vectors are not needed, it can be skipped.

r.to.vect input=Precipitation_by_CatchmentArea output=Precipitation_by_CatchmentArea_Vectors feature=area

=== Method 2 ===

''written by Michael O'Donovan''

GIS users accustomed to proprietary vector-based products (MapInfo, MapMaker, Atlas and some other ESRI) are often disappointed when the try migrating to OpenSource software. Many of the key functions that make vector-based systems so useful are unavailable in OpenSource software like QGIS, Thuban and GRASS. One such function is the ability to aggregate values from one polygon layer to another.

A typical example would be one of aggregating the population of census tracts (or municipalities) to derive the population of a suburb (or province). The aggregation is simply one of adding the tracts together only when the outer edge of some combination of polygons coincide. This happens when tracts are defined in such a way that they coincide with suburb perimeters. However when the boundaries do not coincide the situation usually calls for a vector-based system that will allocate populations according to the location of the tract centroid or the proportion of a tract falling into a particular suburb. The absence of this aggregation feature discourages potential users from adopting OpenSource software like GRASS. The section that follows shows how, with a little bit of preparation, aggregations can be easily performed by GRASS raster functions. It follows a hypothetical example inspired by the proposed redrawing of South Africa's nine provinces which currently dissect many of the 280+ municipalities. It shows how municipal populations can be re-combined to derive the provincial population by converting the vector features to rasters.

For simplicity it is assumed that the user has two shape files "Municipalities" and "Province". The "Municipalities" file is linked to a file "Municipalities.dbf" which contains numerous variables including "pop" (its population) and "SHP_FID" (a unique number which identifies each polygon). Both files can be easily imported into GRASS (using v.in.ogr) and displayed along with their variables. Before the vector files can be converted to rasters an unusual preparatory step is required. This entails converting the variables of interest from a value per vector to a value per raster cell. To make this conversion it is necessary to place into the appropriate .dbf file a count of the number of raster cells that will represent that vector. In this example this will enable the user to represent the population not as a number per municipality but as a number per cell. All subsequent aggregations need to be based on these cell values and thus on the cell counts.

The first step in preparation is to calculate the number of cells in each municipality. To do this convert the municipality vector into a raster file. Remember that, unlike vectors which can be linked to a large number of other variables, raster cells take on a single value only. For this step this value must be a number that uniquely identifies each municipality. If the municipality vector was obtained from an ESRI shapefile the field "SHP_FID" doesthe job. From the command line type:

v.to.rast input=Municipalities output=municipalities use=attr col=SHP_FID

This creates a raster file called "municipalities". As vectors and raster are of different types there is little prospect of their names being confused. (Nevertheless vectors are indicated by a starting capital while rasters are kept as lowercase words.) the new raster can be seen by typing...

d.rast municipalities.

If is looks funny change the color scheme using something like...

r.colors map=municipalities color=random
and d.rast it again.

The next step requires extracting a count of the number of raster cells in each municipality. Once again this is a simple procedure. To save do this and save the output to a file called "munic_count" type...

r.stats input=municipalities output=munic_count -c

This will produce a text file with the SHP_FID and a cell count seperated by a space. The final preparatory step is to place the count corresponding to each municipality into the Municipalities.dbf file and to calculate the variables of interest as an amount per cell.

<hr>
This is how you would link the files in OpenOffice if you have not yet set up your data sources and do not know how to use VLOOKUP etc.

# Open the file "munic_count" - it will default to a text page containing the SHP_FID, an open space and the cell count.
# Convert the open spaces to tabs using "Edit", "Find and Replace". Place a space in the "search for" box and \t in the "replace with" boxes. Activate "Regular expressions" and click on "Replace all".
# Select all of the data (Ctrl A) and copy it to a clipboard (Ctrl C)

You now have all the data ordered by SHP_FID ready to be pasted into the Municpalities.dbf file. So open the Municipalities.dbf file - it will default to a spreadsheet.

# Make sure that the spreadsheet data is in ascending ordered of SHP_FID. (Select all data other than the headers then go to "Data", "Sort" and select the appropriate column).
# Click on to cell at the top of the first unused column and click on "Edit", "Paste special" and "unformatted text". The cells values and SHP_FID data should now be placed in the corresponding rows. Check that this has been done.

=== Variables of interest ===

If you are interested in, say, aggregating populations then calculate the population per cell for every municipality. (If your data starts in row 1, population is in column C and the cell count in column K type "=C1/K1". Copy and then paste the formula into all other rows.) Give the new column an appropraite name, say, "cell_value" and save the file under its original name (i.e. as a .dbf). You may well return at a latter stage and calculate new variables of interest using the cell counts.

<hr>

You can now proceed with the aggregations.

First convert the Municipalities vector into a raster (again). This time use the cell_value as the attribute of interest. At the command prompt type...

v.to.rast input=Municipalities output=municipalities use=attr col=cell_value

Note that I gave the output raster the same name as earlier. This will overwrite the original raster thereby minimizing clutter.

Now also convert the Provinces vector to a raster file

v.to.rast input=Provinces output=provinces use=attr col=SHP_FID

The relationship between the two raster files can now be explored using a number of statistics commands most of which are found under r.statistics. Perhapsthe most important statistics are r.sum and r.average.

The command
r.sum municpalities

will give the total of all the cell values in the municipalities raster. This equals the total population of the region. However what is actually required in the sum of the population for each province. To get this we use r.statistics. Unfortunately this script does not work for floating point rasters (which is what you are most likely to have). To overcome this problem create a new raster reflecting the integer value of each cell. To create a file useable for r.statistics use..

r.mapcalc
(then enter line-by-line)
int_municpal=round(municipalities)
end

If rounding of the cell values to an integer results in a notable decline in accuracy then create a new raster file in which the values are multiplied by ten or a hundred and only then rounded. In latter analysis recall that the units have been dramatically (but precisely) inflated. To do this try "int_munic=round(100*municipalities)".

To finally aggregate the municipal population to provinces type...

r.statistics base=provinces cover=int_municipal method=sum output=prov_pop

This creates a new raster "prov_pop" which can be explored using

d.what.vect
(click on each region of interest)

You will see that the values for each province now equals the sum of all the cells that fall into that province. If you want to list the values so that you can put them into Provinces.dbf (i.e. the vector) use..

r.stats input=RSA_STATS -l

The output can then be placed into the corresponding data file using a method similar to that above.

r.statistics comes with a range of other functions other than "sum". These substantially improve the functionality of the method. Statistics include distribution, average, mode, median, average deviation, standard deviation, variance, skewness, kurtosis, minimum and maximum. For assistance type "man r.statistics" from the command prompt. Additional functionality is gained by r.mapcalc's ability to perform functions on multiple raster files. This, in itself, makes the move to raster-based mapping most promising.

Sometimes the above procedure results in a notable loss in accuracy. There are two main sources for this:

The rounding of cell values (to use r.statistics) may be problematic for areas with very small values. If this is the case consider inflating cell values by one of several orders of magnitude.

When the region was set up a resolution (E-W and N-S) was specified. If this resolution is not fine enough there may be some loss of accuracy through aggregation. Consider increasing the resolution.

[[Category:FAQ]]
[[Category:Vector]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

[http://www.prlog.org/11289974-phone-number-lookup-verizon-phone-number-reverse-lookup-to-get-information-you-need-quickly.html phone number lookup]

Tips for Arc users

2011-12-30T20:57:42Z

⚠️Reverse22:

== Working with your ArcGIS data ==

'''Importing ArcGIS Data'''

Grass provides convertors for importing ESRI shapefiles, e00 files, and many other GIS formats as well. The key Grass programs for importing vector formats are {{cmd|v.in.ogr}} (for ESRI shapefiles, MapInfo files, SDTS, TIGER, etc.) and {{cmd|v.in.e00}} for e00 format.

'''Coordinate Reference Systems'''

The GRASS data structure requires that each data layer have its CRS exactly defined. This is done by maintaining data layers within a "[[Location and Mapsets|Location]]". Each Location has a strictly defined projection, and datum, and all the data layers (raster and vector) within that location should already be either created in or projected to that CRS. GRASS does '''not''' do "on-the-fly" reprojection due to the problems often encountered in other GIS software with datum mismatches. So data layers in one location are not visible from other locations. However GRASS does supply a collection of [[Common_Tasks#GIS_Tasks|tools]] for projecting vector and raster layers from one location to another. Use of these tools is explained in the [[http://grass.osgeo.org/grass64/manuals/html64_user/projectionintro.html manual]].

=== Vector import/export commands ===

* {{cmd|v.in.ogr}} - Convert [http://www.gdal.org/ogr OGR] supported vector formats to GRASS vector format.

* {{cmd|v.out.ogr}} - Convert from the GRASS vector format to one of the supported OGR vector formats.

* {{cmd|v.in.e00}} - Import a E00 coverage into a GRASS vector map.

==== Import of Shapefiles into Grass ====

specify the directory
v.in.ogr dsn=/home/data/navigation_files output=Tracklines layer=Ship_Tracklines

: or just the .shp file name directly
v.in.ogr dsn=Ship_Tracklines.shp output=Tracklines

This is the syntax for {{cmd|v.in.ogr}} in its most basic form. The ''dsn'' parameter corresponds to the directory path of the vector you are trying to import. You can enter a full or relative path. The ''output'' paramter, aptly enough, is the name of your output Grass vector. The ''layer'' parameter is the name of the input vector, be it shapefile, MapInfo file, or what have you.

==== Export of Shapefiles from GRASS ====


Shapefiles can only hold one type of data (point, line, polygon) per shapefile.
You can't export a GRASS vector map with both points and areas to a single
shapefile. You'll have to do it in two passes to two different files with
{{cmd|v.out.ogr}} and different "type=" parameters.

Export lines from GRASS vector map to Shapefile format (generates /tmp/testogr.shp and related files):

v.out.ogr input=multi type=line dsn=/tmp olayer=testogr

Export areas from GRASS vector map to Shapefile format (generates /tmp/testogr.shp and related files):

v.out.ogr input=multi type=area dsn=/tmp olayer=testogr

Export 3D lines from GRASS vector map to Shapefile format:

v.out.ogr input=lines_3d type=line dsn=/tmp olayer=testogr lco="SHPT=ARCZ"

==== Various vector commands ====
* Editing differences
: Tips for [[Digitizing_Area_Features|Digitizing area features with attributes]]

=== Raster import/export commands ===

* {{cmd|r.in.arc}} - Convert an ESRI ARC/INFO ascii raster file (GRID) into a GRASS (binary) raster map layer.

* {{cmd|r.out.arc}} - Converts a GRASS raster map layer into an ESRI ARCGRID file.
** [http://listserver.mbari.org/sympa/arc/mbsystem/2009-03/msg00031.html Some tips and tricks for imporing Arc ASCII grids from external software]

* {{cmd|r.in.gdal}} - Import [http://www.gdal.org GDAL] supported raster file into a binary raster map layer.
** Import a binary ArcInfo raster grid into GRASS:
*** See the [http://www.gdal.org/frmt_various.html#AIG GDAL help page for AIC]
*** Often the biggest .adf file is the right one to import -- check your data values after importing even if they visually look correct!
r.in.gdal input=/path/to/map/hdr.adf output=map

* {{cmd|r.out.gdal}} - Exports GRASS raster data into various formats.
** Export a raster as a GeoTIFF for use with ArcView 3.1:
r.out.gdal input=map output=map.tif type=Byte createopt="INTERLEAVE=PIXEL,COMPRESS=PACKBITS"

==== Import ArcASCII raster grid and connect to database ====

The trick is to convert the raster coverage to vector
areas to take advantage of GRASS's rich vector attribute/database tie-ins. You can use either {{cmd|r.in.arc}} or {{cmd|r.in.gdal}} for the import.
If using r.in.arc be careful to set the map type to CELL for categorical maps.

# import ArcASCII grid to UTM55S location
r.in.gdal input=aas_z55.asc output=aas_z55
r.colors aas_z55.gdal color=random
r.info aas_z55

# convert to vector areas, using raster value for category
g.region rast=aas_z55
r.to.vect -v in=aas_z55.gdal out=aas_z55 feature=area

# get rid of empty DBF table created by r.to.vect
v.db.droptable aas_z55

# copy real DBF file into $MAPSET/dbf/ directory
eval `g.gisenv`
cp /tmp/au/aas_z55.DBF "$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/aas_z55.dbf"

# connect full DBF database to vector map, use "VALUE" as the key column
v.db.connect map=aas_z55 driver=dbf table=aas_z55 key=value

done!

==== Import E00 raster grids ====

The {{cmd|v.in.e00}} module only handles vector data. You will have to convert raster E00 data into an Arc ASCII grid before importing into GRASS with {{cmd|r.in.arc}} or {{cmd|r.in.gdal}}.

* [http://lists.osgeo.org/pipermail/grass-user/2009-October/052758.html See instructions in this mailing list post] about the
"ArcExplorer Import Utility"

=== Various hydrology and terrain analysis commands ===

* Watershed modeling differences:
** ArcInfo wants a depressionless, filled, hydrologically correct DEM.
** {{cmd|r.watershed}} does explicitly not want such a DEM, it just wants a raw DEM with depressions, not filled, and not hydrologically correct (hence, no preparations needed).
* How to [[Creating_watersheds|Create watersheds for specific drainage points]] like the Arc Hydro extension
* See also [[Hydrological Sciences]] for a list of available hydrological GRASS tools

== See also ==
[[GRASS migration hints]]

[[Category:Documentation]]
[[Category:FAQ]]
[[Category: Hydrology]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

[http://www.prlog.org/11289974-phone-number-lookup-verizon-phone-number-reverse-lookup-to-get-information-you-need-quickly.html phone number lookup]

Sqlite Drop Column

2011-12-30T20:57:29Z

⚠️Reverse22:

'''Q:''' How can I drop a column in sqlite-databases?

New '''A:''' GRASS 6.3.cvs contains v.db.dropcol which supports it.

Old '''A:''' It is not possible to drop columns within sqlite using the syntax ALTER TABLE DROP COLUMN [1]. However, there is a workaround for this issue [2]:

<pre>
BEGIN TRANSACTION;
CREATE TEMPORARY TABLE t1_backup(a,b);
INSERT INTO t1_backup SELECT a,b FROM t1;
DROP TABLE t1;
CREATE TABLE t1(a,b);
INSERT INTO t1 SELECT a,b FROM t1_backup;
DROP TABLE t1_backup;
COMMIT;
</pre>

It's obvious that this is a little bit complex. But if you use sqlitebrowser [3] this can be done with a few mouse-clicks (look under -->modify table for a button "remove field". See also the Firefox SQLite Manager add-on [4], which is similar to SqliteBrowser.

Alternatively, you could try this approach, which is slightly fewer steps:

<pre>
BEGIN TRANSACTION;
CREATE TABLE t1_new (
foo TEXT PRIMARY KEY,
bar TEXT,
baz INTEGER
);

INSERT INTO t1_new SELECT foo, bar, baz FROM t1;
DROP TABLE t1;
ALTER TABLE t1_new RENAME TO t1;
COMMIT;
</pre>

* [1] http://www.sqlite.org/omitted.html
* [2] http://www.sqlite.org/faq.html#q11
* [3] http://sqlitebrowser.sourceforge.net/
* [4] https://addons.mozilla.org/en-US/firefox/addon/5817

[[Category:FAQ]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

[http://www.prlog.org/11289974-phone-number-lookup-verizon-phone-number-reverse-lookup-to-get-information-you-need-quickly.html phone number lookup]

SQL rename columns

2011-12-30T20:57:25Z

⚠️Reverse22:

''Q: I have imported successfully a large dataset to GRASS. After the import, the attribute columns are named like this: dbl_1 dbl_2...... I would like to change these names to something more friendly. I've tried some dbf editors but they allow only to change values but not the database structure.''

'''A:''' You can change column names with [http://openoffice.org Openoffice.org] (Version 2). But take care to use 'oobase' (or: File -> New -> Database) to avoid problems with the number of rows. So, use 'oobase' to connect to your dbf file using the dbase driver (in the launch dialog chose "connect to existing database"). Then you don't have any problems with row number limits.

Notes:
* In PostgreSQL there is an ALTER TABLE/RENAME COLUMN command.
* For SQLite, use the [http://sqlitebrowser.sourceforge.net/ SQLiteBrowser] program or the [https://addons.mozilla.org/en-US/firefox/addon/5817 Firefox SQLite Manager plugin].

Alternative: in GRASS >=6.3 there is drop column support: so you can add a new column, update it to the one to be renamed, drop the old column.
* {{cmd|v.db.renamecol}}
* {{cmd|v.db.dropcol}}
* {{cmd|v.db.addcol}}

=== See also ===
* [[Openoffice.org with SQL Databases]]

[[Category:FAQ]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

[http://www.prlog.org/11289974-phone-number-lookup-verizon-phone-number-reverse-lookup-to-get-information-you-need-quickly.html phone number lookup]

Search and Rescue

2011-12-30T20:57:17Z

⚠️Reverse22:

Along with GIS's role in natural hazard mitigation planning, such as preparing proactive earthquake, landslide, or tsunami risk maps, SAR is one of the truly rewarding applications of the software. The majority of the work on GRASS (and Open Source software in general) is done on a volunteer basis, indoors on a terminal screen with little feedback. Hearing about some little program that you created helping folks in dire need really makes our day and keeps us motivated to continue working on the software.

* The following thread appeared on the GRASS users' mailing list in early Feb 2008: "[http://thread.gmane.org/gmane.comp.gis.grass.user/22261 Search and Rescue Volunteer Groups]"

=== In the news ===

The speed with which open source software can be modified and component tools grafted together to create new custom application software lends itself to use in dynamic situations where speed of deployment is key.

* [http://thread.gmane.org/gmane.comp.gis.gdal.devel/5243 GDAL's use in Hurricane Katrina rescue efforts]

=== Case Studies ===

GIS operations are a natural fit in search and rescue planning. This application shows how a GIS could have been deployed to analyze information known to search management during a difficult search, had the tool been available to planners at the time.

* [http://www.swcp.com/~russo/080103/ GRASS potential impact to SAR planning]

=== Agent Modeling ===
Agent modeling could be an interesting mix of modeling in a GIS environment especially in use by Search and Rescue (SAR). Interesting area tho think about.

* [http://gisagents.blogspot.com/2007/10/open-source-simulation-modelling.html GIS and Agent Based Modeling] Blog

* [http://repast.sourceforge.net/ REPAST] Repast Simphony is a free and open source agent-based modeling toolkit that offers users a rich variety of features. Java and Python. Integrates with Geotools, java topology suite, R-Stats and OpenMap

* [http://www.ucl.ac.uk/~tcrnmar/ MAGICAL] The MAGICAL software comprises a suite of three programs that provide a multi-agent simulation extension for the GRASS GIS software.

*[http://lists.osgeo.org/mailman/listinfo/grass-abm GRASS-ABM mailing list]: Integration of GRASS with JAVA based agent based modeling (ABM)

=== References ===

* Ciolli M., Vitti A., Mengon L., Zatelli P., Zottele F., "''A GIS-based decision support system for the management of SAR operations in mountain areas''". Geomatics workbooks, 2006, v. 6.
: URL: http://geomatica.como.polimi.it/workbooks/n6/articoli/sar_geomatics.pdf

* Ciolli M., Mengon L., Vitti A., Zatelli P., Zottele F., "''A GIS-based FOSS decision support system for the management of SAR operations in mountain areas''". Contributo a "FOSS4G2006 - Free And Open Source Software for Geoinformatics", Losanna, Svizzera, 11-15 Settembre 2006.
: URL: http://www.foss4g2006.org/contributionDisplay.py?contribId=137&sessionId=49&confId=1

=== Links ===

* [http://www.xastir.org Xastir] - X Amateur Tracking and Information System

* [http://e-gads.sourceforge.net E-GADS!] - Electronic Ground Search and Rescue Administrative Database System

* [http://gpsd.berlios.de GPSd] - gpsd is a service daemon that monitors one or more GPSes attached to a host computer through serial or USB ports, making all data on the location/course/velocity of the sensors available to be queried on TCP port 2947 of the host computer.

* [http://www.gpsdrive.de GpsDrive] - Real time navigation software for Linux & Mac
: see also the ''d.out.gpsdrive'' GRASS module

* [http://pywps.wald.intevation.org/ PyWPS] and more generally [http://grass.osgeo.org/screenshots/web.php GRASS web interface] applications

* [http://sahana.lk/ Sahana] is a Free and Open Source Disaster Management system. It is a web based collaboration tool that addresses the common coordination problems during a disaster from finding missing people, managing aid, managing volunteers, tracking camps effectively between Government groups, the civil society (NGOs) and the victims themselves.

=== Contacts ===

* -[[User:Dsampson|Dsampson]] Dave Sampson ([http://grass.itc.it/ GRASS], [http://qgis.org/ QGIS], [http://wiki.osgeo.org/index.php?title=Ottawa_Chapter OSGEO Ottawa], [http://www.sarglobal1.ca/index.htm SAR Global1], G3 Geomatics)
* -

[[Category:Applications]]
[[Category:Documentation]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

[http://www.prlog.org/11289974-phone-number-lookup-verizon-phone-number-reverse-lookup-to-get-information-you-need-quickly.html phone number lookup]

Scripting

2011-12-30T20:57:13Z

⚠️Reverse22:

== Scripting ==

=== General ===

* See the [http://grass.ibiblio.org/grass63/manuals/html63_user/g.parser.html g.parser] module help page. It's an easy way to make your script look and act like a GRASS module, including creating a GUI and help page template for it automatically.

* There are a number of [http://grass.ibiblio.org/grass63/manuals/html63_user/general.html other] g.* modules which are specifically useful for scripting use.

==== Verbosity level ====

Use the "--quiet" (alias --q) and "--verbose" (alias --v) command line arguments to make the script produce more or less messages and info like percent done. This works for almost all modules. The big exception to that is r.mapcalc which doesn't use the standard parser.

For r.mapcalc, or if you want to set a blanket --quiet directive for the whole script, you can set the GRASS_VERBOSE environmental variable. Python's os module has a putenv() function to do that.

These are the levels you can use:
(from lib/gis/verbose.c)
0 - module should print nothing but errors and warnings (G_fatal_error,
G_warning) Triggered by "--q" or "--quiet".
1 - module will print progress information (G_percent)
2 - module will print all messages (G_message) [default level]
3 - module will be very verbose. Triggered by "--v" or "--verbose".

"--quiet" will set the level to 0.

shell script example
# for everything that follows
GRASS_VERBOSE=1
export GRASS_VEBOSE

# override for just one module
GRASS_VERBOSE=0 \
r.mapcalc "only_set = for_this_process"

Another nice thing about using the enviro variable method is that it is
silently ignored for earlier versions of GRASS. For earlier versions of GRASS
an error happens when "--quiet" isn't recognized as a valid command line
option. (the new 6.2.3 knows to ignore it)

see "Verbosity levels" on the [[Development_Specs]] page.

The advantage of these methods versus sending all stderr to /dev/null is that
warning and error messages are not lost, making prototyping and debugging a
whole lot easier.

=== Bash ===

See the [http://grass.itc.it/grass63/source/snapshot/SUBMITTING_SCRIPTS SUBMITTING_SCRIPTS] file for some tips.

See the existing GRASS scripts in the scripts/ directory for examples of using tempfiles, etc.

Newer versions of Ubuntu use Dash as the default /bin/sh, so don't assume that sh will handle Bashisms.

* [[GRASS_and_Shell|Running GRASS as a batch job]]

=== Tcl/Tk ===

See the [http://grass.itc.it/grass63/source/snapshot/SUBMITTING_TCLTK SUBMITTING_TCLTK] file for some tips.

=== Python ===

* See the [[GRASS and Python]] page

{{Python}}

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

[http://www.prlog.org/11289974-phone-number-lookup-verizon-phone-number-reverse-lookup-to-get-information-you-need-quickly.html phone number lookup]

Screenshot suggestions

2011-12-30T20:57:09Z

⚠️Reverse22:

Please put suggestions for screenshots to go onto the main website on this page. You can post URLs or [[Special:Upload|upload images]] directly to the wiki or upload them to the [http://svn.osgeo.org/grass/grass-addons/screenshots/ SVN addons repository].

Here is the new work-in-progress screenshots page:
* http://grass.osgeo.org/screenshots/

'''Note that all screenshots are to be licensed under the [http://creativecommons.org/ Creative Commons] [http://creativecommons.org/licenses/by-sa/2.5/ Attribution ShareAlike 2.5] License.''' Please leave your name as well so we can attribute correct credit.

* See [http://en.wikipedia.org/wiki/Wikipedia:Extended_image_syntax here] for help making an image on this page an instant thumbnail.<BR>(The syntax is '''<nowiki>[[Image:{name}|{width}px]]</nowiki>''')

* PNG images are lossless but can be very large for satellite images & photographs. Best format to use for things like menus with a lot of solid colors and where crispness counts.
** To help save bandwidth, save your PNGs with compression setting of 9. Often you can reduce the file size significantly by reducing the pallet size to be big enough to hold just the colors used.
** Running a program like [http://pmt.sourceforge.net/pngcrush/ pngcrush] can compress it further.
pngcrush -brute image.png image_crushed.png

* JPG images are lossy but can be much smaller for things like satellite images & photographs.
** For quality save nearer to 85%, for size save nearer to 75%.

-----

'''Still to do'''

* Enhance the web services page

* Clean up & add to RS/imagery pages, clarify meanings of the two categories

* Nicer raster/'''vector''' page images?
: Create a Spearfish/NC map showing vector maps rendered with the new Cairo display driver

* Create modeling page (R stats, Dylan's spearfish clustering fig, ..?)
: Idea for modeling page is non-map figures and graphs

-----

Stuff still to merge & places to draw from:
* Old screenshots from the website [grass6?/screenshots/]
** http://freegis.org/cgi-bin/viewcvs.cgi/web/grass60/screenshots/
** http://freegis.org/cgi-bin/viewcvs.cgi/web/grass61/screenshots/
** http://freegis.org/cgi-bin/viewcvs.cgi/web/grass63/screenshots/
* stuff in the main website images/ dir (mostly GRASS 5 shots)
** http://freegis.org/cgi-bin/viewcvs.cgi/web/images/
* Screenshots from http://www.osgeo.org/grass/
* The wiki [[Special:Imagelist|Imagelist]]
* Old GRASSNews and OSGeo journal articles
* Scans of old GRASS-Clippings articles? -> helena + old GRASS 4 3D globes?

-----

Subcategories are:
== User Interface ==

=== Startup screen ===

* Mapset picker
* Define new location by EPSG & custom params
* Markus has some on the [[FOSS4G2007 IntegrationShowcase]] wiki page

=== TclTk GUI ===

* GUI and tools in action

=== wxPython interface ===

* GIS manager
* module window

=== GRASS and QGIS ===

* see Trento QGIS

== Platforms ==

=== Linux ===
=== Mac ===
=== Windows ===
=== Handhelds ===

== Raster map operations ==

[[Image:D_rast_arrow_magnitude.png|right|100px]]
* ''d.rast.arrow'' example (HB) - '''''added to raster page'''''

[[Image:Spearfish_catchements.png|right|100px]]
* ''r.watershed'' help page example (HB) - '''''added to raster page'''''

[[Image:Zurich.png|right|100px]]
* ''r.mapcalc'' and LANDSAT imaging/processing

* <tt>r.param.scale param=feature</tt>

* Some more [http://www.grassbook.org/gallery/ch3getstarted/images.html raster maps]
* And even more [http://www.grassbook.org/gallery/extra/osgeo_nc_example1.png raster maps]

== Vector map operations ==

* Network ops.
* 3D visualization
** DXF ant (HB): [http://bambi.otago.ac.nz/hamish/grass/bugs/insects01_nviz_dxf.png] (combine with [http://grass.ibiblio.org/grass63/screenshots/vector.php Möbius strip])
** NYC-3D (HB): [http://bambi.otago.ac.nz/hamish/grass/screenshots/nyc3d_nviz3_midtown.png]

* USA 3D bargraph by state [http://grass.fbk.eu/grass60/screenshots/viz.php here] - v.extrude [http://grass.fbk.eu/grass61/screenshots/vector.php here], NVIZ

* vector map (roads, railway, fields, points, etc) rendered using the Cairo driver

== Imagery ==

''We still need to better define where to make the split between Image Processing and Remote Sensing''

* i.fusion.brovey example [http://mpa.itc.it/markus/grass61/demos/ here]
* i.vpoints example showing back-transformed vector overlay check
* I remember a picture of a house and dock rendered in 3D from key GCPs in some sort of stereo photogrammetry project. Maybe from an abstract of talk from the GRASS conf. that took place in EU before the Thailand one (??)

== Remote Sensing and LIDAR ==

=== Satellite Data ===
MODIS, Quickbird, etc, I thought to put some sites/vector points stuff here too. Maybe split that out into its own category?

* clustering, segmentation [http://gama.fsv.cvut.cz/wiki/index.php/Zpracov%C3%A1n%C3%AD_obrazov%C3%BDch_dat_-_cvi%C4%8Den%C3%AD_%C4%8D.11 many examples from Martin]
: - '''''very nice!'''''
* sat img edge detection (Markus posted one recently)
* i.landsat.rgb trials [http://bambi.otago.ac.nz/hamish/grass/landsat/]
: '''''- added to RS page'''''
: also [http://mpa.itc.it/markus/grass61/demos/ Markus's example] is nice

* [http://mpa.itc.it/rs/modis_reflectance/modis_reflectance500m.png MODIS/Terra Surface Reflectance Daily L2G Global 500m] - ''8 Aug 2002 - true color image composite. Part of Europe as seen from MODIS/TERRA at 500m resolution (R1 G4 B3). New snow arrived in the Alps, floods in Austria, Czech Republic and Germany due to heavy rain (up to 300mm/24h in Eastern Europe)''. (screenshot Markus Neteler)
* [http://mpa.itc.it/rs/modis_ndvi_evi/index.html MODIS NDVI/EVI] images
* [http://mpa.itc.it/rs/aster/index.html ASTER high resolution remote sensing] - ships on the North Sea near Germany
: '''''- added to the RS page '''''

* [http://en.wikipedia.org/wiki/SRTM SRTM void filling with spline interpolation in GRASS GIS] (screenshot Markus Neteler)
: '''''- already on the raster screenshot page'''''. ''add to the RS page too?''

* [http://mpa.itc.it/rs/landsat7/index.html LANDSAT TM7 visualizations of Venice, Trento] (screenshots Markus Neteler)
* ? more ideas please ?

=== LIDAR and Sonar Data ===
* [http://www.grassbook.org/gallery/extra/osgeo_nc_example2.png Lidar with NC OSGeo data set]
* [http://skagit.meas.ncsu.edu/~drake/drake/jockey/jockeys_ridge.html Jockey's Ridge] '''''- added'''''
* gdalwarping of sidescan sonar track? - yes!
: http://bambi.otago.ac.nz/hamish/grass/gdal/sidescan_warp.html

=== Sites (point) data ===
* where to put this?
- eg NVIZ 3D histograms (example?)

== 3D Visualization ==

* see [[Help with 3D]]

* NVIZ, r3.out.vtk, ... [http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/ paraview] from Sören
* MARS MOLA data ([http://bambi.otago.ac.nz/hamish/olympus_mons.html]) '''''added to viz page'''''

[[Category:Visualization]]

== 3D Rendering ==

* [http://mpa.itc.it/markus/povray/ Povray rendering] (Markus Neteler)
: '''''- added to viz page'''''
* [http://casoilresource.lawr.ucdavis.edu/drupal/node/80 Povray rendering] (Dylan Beaudette)
: '''''- link added to viz page'''''

* see also the GRASS [[POV-Ray]] wiki page

== Map reprojection ==

* [http://grass.fbk.eu/grass60/screenshots/raster.php Lambert Equal Area projection of ETOPO2]
: - ''currently on the raster page''

* i.vpoints preview vector map backwards projection overlay

== Cartography ==
''Aim for publication quality''

* ps.map, nice PS,PNG driver renders
** I do not know, if it suits, but this I got some time ago with pure ps.map [[http://wwwold.fle.czu.cz/~jachym/img/grass/krkonose_prehledka.jpg]]

* example of rotated symbols in ps.map: (H Bowman)
: --''HB:'' does this demo count as cartography? I'm not quite sure how to classify it.
: http://mpa.itc.it/markus/grass63/demos/psmap_rotcol.png

* [http://grass.itc.it/images/spearfish_drg_nviz.jpg US DRG draped over DEM (NVIZ)] (Markus Neteler)
: - '''''already added as first image on viz page''''', ''add to the cartography page as well as an example of what can be done with a printed topo map??'' (HB: sure, if you like)

[[File:Ps.output.png|thumb|right|200px]]
* example of map using {{AddonCmd|ps.output}} addon
: - '''''added'''''

* screenshot of a map created with GRASS and viewed within from QGIS (using aspect data to rotate and area data to adjust the size of arrow-symbols corresponding to forest gaps).
: - Does this fit here? Names and text can be removed as well as a high quality version can be created if required[[File:Forestgaps_Moseltal_Germany.png|thumb|right|200px]]

== Web Services ==

* Markus's PHP earthquake map: http://grass.itc.it/spearfish/php_grass_earthquakes.php
* Jachym's contributions
** PyWPS
** The new one
** There is a lot of the stuff
*** http://www.bnhelp.cz/mapserv/pokusy/OpenLayers/jachym/openlayers/examples/wps.html
*** http://pywps.ominiverdi.org - more stuff
*** http://pywps.wald.intevation.org
*** http://www.bnhelp.cz/mapserv/pokusy/openlayers/bonifacio
* r.in.wms, v.in.wfs
* CSISS/GMU contributions: GRASS_based geospatial web services
** A lot of web services are developed based on GRASS functions for imagery/raster and vector map processing
*** http://geobrain.laits.gmu.edu:81/grassweb/manuals/
** They are standard web services, which allow anyone to invoke with their own client applications
** All these web services also could be invoked through our GeOnAS interface
*** http://geobrain.laits.gmu.edu:81/OnAS/
*** http://geobrain.laits.gmu.edu:81/OnAS/User_Guide.htm
* OSU IPPC GRASSLinks:
: http://pnwpest.org/glinks/

== Modeling and Statistics ==
''this sections needs a better title''

* Dylan's Spearfish bugsites cluster plot: http://casoilresource.lawr.ucdavis.edu/drupal/node/340
* Some R variograms etc

== Animations ==

* see [[Movies]]

=== 2D MPEGs ===
(r.out.mpeg et al)

* old MPEG-1 canyon fly through
: - '''''added'''''
* Bob Covill had some ETOPO5 world bathymetry fly throughs
: - '''''added'''''
: Still need to add new movies from Bob

* Maris' r.lakes Latvia animations at http://mpa.itc.it/markus/grass61/demos/rlake/
: (don't use the bad Trento figures there)

=== 3.5 and 4D ===

* moving NVIZ cutting planes
: example South America movie from Bob '''''- added'''''
* Paraview

== More sections? ==

Feel free to suggest something.

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

[http://www.prlog.org/11289974-phone-number-lookup-verizon-phone-number-reverse-lookup-to-get-information-you-need-quickly.html phone number lookup]

S-57 data

2011-12-30T20:57:03Z

⚠️Reverse22:

'''''More to come'''''

== Basics ==

* Import with v.in.ogr
* '''There is some more info and links on the [[Export for GpsDrive]] wiki page'''
: (see the mailing list posts linked at the end of that page):
:: http://thread.gmane.org/gmane.comp.linux.gps/3920/focus=3937
:: http://thread.gmane.org/gmane.comp.linux.gps/3920/focus=3934

== Obtaining data ==

=== Worldwide ===

* Often this is problematic, which is a real shame because lives depend - in a very real way - on universal access to good chart data. My frustrated take (rant?) on the matter:
: ''The hydrographic offices of many countries, and their associates, earn significant revenue from selling nautical chart data back to the tax payers who funded them in the first place, and they are as a whole loathe to give that up. This follows on from a tradition of selling paper charts, which did have substantial printing and distribution costs. But for electronic charts the primary cost of production is shifted the maintenance of the bathymetric survey and light lists, which must be borne as a fixed cost anyway. There are some justified worries about outdated or invalid data being used for navigational purposes, but in this sailor's opinion an out of date chart is worlds better than no chart at all; money spent on fragile fail-dangerous software is money not spent of the upkeep of the boat; we all know full well what "Not for navigational purposes" means (and that is mostly irrelevant for GIS work anyway); and cryptographically signed data packages (e.g. MD5 checksums) have been around and in wide use for more than a decade, ensuring that the end-user's data has not been corrupted or altered, without requiring a closed system. If you live in a country so effected, probably the best you can do is have your local OSGeo chapter &/or institution complain en masse to your national geospatial information office, citing the United States's NOAA as an example which can not be ignored. Even if they will sell you the data it will typically be encrypted in a form which will require one of their proprietary vendor-partners' software, OS, and typically a hardware dongle which can not be repaired or replaced at sea. These "DRM" tactics are fundamentally incompatible with almost all Free and Open Source software licenses (and goals) so there is little hope of a FOSS solution without action from higher up in the government. [http://www.gdal.org/ogr OGR]'s S-57 reader can not decrypt this data even if you own it; the IHO's technical committees are dominated (and often lead) by representatives of the established commercial vendors which have a vested interest in keeping the barrier to entry high.''

=== Cananda ===

* ...

=== USA ===

* Free ENC vector data for the USA from NOAA
: http://nauticalcharts.noaa.gov/mcd/enc/download.htm

* Nice previews / chart picker:
: http://www.oceangrafix.com/o.g/search-nautical-charts.html

== Import ==

* Use a Lat/lon WGS84 location
:Select "create new location from georeferenced file", using the ENC *.000 file. It's just lat/lon WGS84, so you could create a new location by EPSG code (4326) or by custom entry too. Another automatic way (from within grass) is to use v.in.ogr's location= option.

* Unzip dataset
unzip NOAA_ENCs440569.zip

* test dataset with ogrinfo
ogrinfo --formats | grep S57
ogrinfo ENC_ROOT/US3NY01M/US3NY01M.000

* Try to load and view it with a nice viewer like [http://openev.sf.net OpenEV] or libS52's s52glx test app

* Import S-57 data into GRASS GIS (grass.osgeo.org) with v.in.ogr
# change default database from DBF to SQLite as it is less lossy
db.connect driver=sqlite \
database='$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db'

# import data (ignore the many string warnings)
v.in.ogr dsn=ENC_ROOT/US3NY01M/US3NY01M.000 out=noaa_12300

# have a look
v.info noaa_12300
g.region vect=noaa_12300
# render all features from all layers
d.mon x0; d.vect noaa_12300

# view DB columns available for layer 20:
v.info -c noaa_12300 layer=20

# browse attribute database
v.db.connect -p noaa_12326 | head -n1
sqlitebrowser $MAPSET/sqlite.db

SQLiteBrowser from http://sqlitebrowser.sourceforge.net/
: (alternative: [https://addons.mozilla.org/en-US/firefox/addon/5817 Firefox SQLite Manager addon])

# e.g. land Layer: LNDARE
ogrinfo -ro ENC_ROOT/US3NY01M/US3NY01M.000 | grep LNDARE
20: LNDARE
d.vect noaa_12300 layer=20 type=area disp=shape,attr attrcol=objnam \
llayer=20 fcolor=255:200:80
# e.g. soundings Layer: SOUNDG (automated layer by name)
LAYER=SOUNDG
LAYER_ID=`ogrinfo -ro ENC_ROOT/US3NY01M/US3NY01M.000 | \
grep "$LAYER" | cut -f1 -d':'`
38: SOUNDG (Multi Point)
d.vect noaa_12300 layer=$LAYER_ID type=point icon=basic/diamond \
fcolor=yellow size=6

# e.g. buoys Layer: BOYSPP
ogrinfo -ro ENC_ROOT/US3NY01M/US3NY01M.000 | grep BOY
7: BOYLAT (Point)
8: BOYSAW (Point)
9: BOYSPP (Point)
d.vect noaa_12300 layer=7 type=point icon=basic/circle \
fcolor=orange size=8
d.vect noaa_12300 layer=8 type=point icon=basic/circle \
fcolor=magenta size=8
d.vect noaa_12300 layer=9 type=point icon=basic/circle \
fcolor=blue size=8

* Set zoom, display layers, colors, line widths, labels, etc. in GRASS
: (this will take some work)

# show everything
NUMLAYERS=`v.db.connect -g noaa_12326 | wc -l`
for layer in `seq 1 $NUMLAYERS` ; do
echo "layer=$layer"
d.vect noaa_12326 layer=$layer \
color=$((layer*4)):$((layer*4)):$((layer*4)) \
fcolor=$((layer*4)):$((layer*4)):$((layer*4))
done

* Color and symbology standards: see libS52 from OpenEV contrib/ CVS
: http://www.iho.shom.fr/ECDIS/s52intro.htm
: http://www.iho.shom.fr/publicat/free/files/PresLib_3.3_Addendum_2007.pdf

e.g. fill color for land is 255:200:80
d.vect noaa_12326 attrcol=objnam llayer=24 disp=attr \
layer=24 fcolor=255:200:80

?? For more colors see openev/contrib/S52/doc/C1.lup_collision.txt

== Accessing S-52 symbology ==

S-57 is the data format. The S-52 standard contains the standardized coloring and symbology for electronic navigation charts. We want to view the S-57 data through the lens of the S-52 rules. Some ideas for that:

* GRASS interface: (wishlist prototype) display imported S-57 data (v.in.ogr or v.external) using S-52's coloring and layer-order info. Some environment will be information like lighting level and hull depth (start at 0) will be needed

* View with the OpenEV plugin (functional)
* Create the dataviewer as a QGIS plugin (wishlist user app)

=== libS52 ===

* GPL library
* housed in [http://openev.sourceforge.net/ OpenEV] CVS as [http://openev.cvs.sourceforge.net/openev/contrib/S52/ contrib/S52/]

Example rendering a few base layers:

: [[Image:Noaa_12300_simpleglx.png|500px]]

==== How to build ====

* [http://sourceforge.net/cvs/?group_id=6087 Get source code from CVS]

* Install build dependencies
: Install OpenGL and X11 -dev packages (X11/Xlib.h and GL/gl.h)
: PROJ.4 for proj_api.h?

* Build it:
make # for s52glx simple test program
make default # for libS52

==== Run simple s52glx test program ====

* [[Export_for_GpsDrive#Nautical_data_2|Get ENC data]]
* Edit s52test.conf with the full path to your ENC chart datafile (*.000 file)
* Run it with ./s52glx and you should see a new window with all layers rendered
* [http://bambi.otago.ac.nz/hamish/grass/s52/ Screenshots]

==== OpenEV S52 plugin ====

* Copy <tt>libS52.so</tt> to GDAL's lib directory
: putting the lib in /usr/local/lib seems to work.
: ''run ldconfig'' ?

* Configure OpenEV with render plugin support:
CFLAGS='-I/usr/include/gdal' CPPFLAGS='-I/usr/include/gdal' \
./configure --with-double-geocoord --with-render-plugin

make

===== Test S52 plugin with OpenEV =====

* Set environment variables
export S57_CSV=/usr/share/gdal
export OGR_S57_OPTIONS="LNAM_REFS:ON,UPDATES:ON,\
SPLIT_MULTIPOINT:ON,PRESERVE_EMPTY_NUMBERS:ON,\
RETURN_LINKAGES:ON"

* Using gvtest:
./openev/gvtest -ogr=/path/to/ENC_ROOT/US3NY01M/US3NY01M.000

* Using s52test:
: (s52test.conf will need ENC path adjusted)
./openev/contrib/S52/s52test

* [??] Using pymod/openev.py:
: (Open .000 file, load all layers)
export PYTHONPATH="/usr/lib/python2.4/site-packages/gtk-1.2"
python2.4 ./openev/pymod/openev.py

=== GRASS S-52 interface for rendering S-57 data ===

* TODO
* build little command line app to output coloring and layer order info which can be fed to d.vect et al?

: Colors:
: (S-52 bright mode, click to enlarge)

[[Image:S52_colors_bright.png|800px]]

Specific color RGB-equivalent values can be found in the OpenEV contrib libS52 docs:
: http://openev.cvs.sourceforge.net/openev/contrib/S52/doc/C1.lup_collision.txt
: scroll down to "S52_dummy.BRIGHT" section of the file (not quite right?? above is based on that)

The above is just the "bright" color mode. There are also reverse background, low light, and nightime (red/black) color modes. Look in the libS52 code to convert those from CIE luminance into RGB colorspace. (S52GL.c?)

Color abbreviation key may be found in the IHO PDF document
: [http://www.iho.shom.fr/PUBLICATIONS/download.htm#special S-52 Appendix 2 - Colour and Symbols Specifications for ECDIS, Edition 4.3, January 2008]
: Table 3: "Alphabetical list of colour tokens" (page 49)

for example:
DEPVS = 131:184:224 = Depth (very shallow)
DEPMS = 166:198:227 = Depth (medium shallow)
LANDA = 211:187:121 = Land (not built up)
CSTLN = 140:144:138 = Coastline

=== QGIS S-52 plugin for viewing S-57 data ===

* Status: '''''TODO'''''
* QGIS reads S-57 data via GDAL's OGR driver, but it aborts because it doesn't know what to do with all the layers. I suspect getting this working at a basic level only requires a minimal amount of work from an interested programmer.

* Integrate libS52 as a plugin.
: ''QGIS plugins can be written as C++ or Python. For python use SWIG to access libS52?''

* please add ideas here ...

== See also ==

* [[BSB_data|Using rasterized navigation charts (RNC) with GRASS]]
: importing and working with BSB charts

[[Category: Geodata]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

[http://www.prlog.org/11289974-phone-number-lookup-verizon-phone-number-reverse-lookup-to-get-information-you-need-quickly.html phone number lookup]

Ps.map scripts

2011-12-30T20:56:59Z

⚠️Reverse22:

== Reference manual ==

You will want to have the ps.map reference manual handy as you will refer to it often. Within the document click on the instruction list links to quickly jump to the section of interest.

* The [http://grass.ibiblio.org/grass63/manuals/html63_user/ps.map.html ps.map help page].

It is suggested to start simply, test the result, and then add more decorations one at a time. The command interface may appear daunting at first but you should get used to it before too long. Manual placement of decorations is a bit of a pain and time-consuming, but it is hoped that there will soon be a new [[WxPython-based_GUI_for_GRASS#Cartography_tools|wxGUI map-composer wizard]] which will act as a front-end to the program, greatly speeding up this part of the task.

== Script examples ==

* [[psmap_simple_example|Simple ps.map examples]] ([http://grass.ibiblio.org/download/data6.php Spearfish dataset])

* Example showing all standard vareas [[psmap_fill_patterns|fill pattern hatches]]. (Spearfish dataset)


* ps.map example demonstrating a [[Psmap_flooding_example|scripted flood risk map]]

* [http://geog-pc40.ulb.ac.be/grass/psmap/ Thematic maps] of Belgium

* Create [[ps.map_graph_paper|graph paper]] ready for printing.

== Tips ==

=== Map Creation ===
==== Multiple raster images ====

While any number of vector maps can be drawn, ps.map will only let you draw one raster image or RGB image set per map.
* If you want to show two or more overlapping raster maps you need to combine them with the r.patch module or r.mapcalc's '#' color operator.
: (see also the r.his and r.composite modules)

* If you want to show a number of raster maps side by side in a paneled figure you will have to do it in a two step process. The first step is to create each panel as an EPS file, the second step is to include these EPS files in the ps.map command file. [[psmap_multi_pane_example|Here is an example script demonstrating this]].

==== Placing text below the map box ====

Use the '''text''' instruction with a y coordinate less than 0%. In the same way text can be placed above the map box by using a coordinate greater than 100%. To right justify the text set the x coordinate to 100% and the '''ref'''erence to right.

ps.map out=test.ps << EOF
raster elevation.dem
text 0% -6% Figure 1.1: Elevation map of Spearfish, SD
fontsize 12
ref left
end
end
EOF

==== Creating a custom info box ====

The scalebar position and divisions will still have to be set manually, but that just takes a minute if you get the box center coordinate from the ''gv'' mouse cursor (see points->inch conversion tip below). For a more simple to use version see the ps.map ''mapinfo'' instruction.
The same method can be used with the ps.map ''point'' and ''text'' instructions to create a custom legend.

#...
scale 1:100000
scalebar s
where 2.4 5.8
length 4000
segment 4
end
text 13.5% 16.5% meters
background white
end
text 13.5% 27% SCALE: 1:100,000
background white
end
rectangle 3.4% 14% 24% 31%
fcolor white
width 0.5
end
#...

See example in image below.

==== Creating a fancy North Arrow ====

You can make a fancy north arrow by combining several ps.map instructions.

In this example we also rotate the north arrow to match true-north instead of the projection's north. This is useful when used with a geo-grid overlay where the grid and the north arrow are right next to each other but don't point in the same direction.

[[Image:Narrow1.png|center|404px|thumb|Example of fancy north arrow and custom info box]]

The deviation between true north and the map projection's local +y direction can be obtained from the <tt>proj</tt> program from [http://trac.osgeo.org/proj/ PROJ.4]. Look for the ''Convergence'' angle. It can be obtained in newer versions of GRASS with "<tt>g.region -n</tt>"

# Spearfish sample dataset

# Set the region to match the map to be plotted
g.region rast=elevation.dem

# find the region's projection information
g.proj -pj
# find the region's center coordinates in lat/lon
g.region -l

# Pass this information to the "proj" program
echo "103d44'58.937352\"W 44d26'14.761572\"N" | \
proj -V +proj=utm +zone=13 +ellps=clrk66
...
Convergence : 0d52'31.587" [ 0.87544073 ]

We then use this angle with the point (mark symbol) and text instructions' rotate option.

ps.map out=test.ps << EOF
raster elevation.dem

# 4 arc-minute geo-grid
geogrid 4 m
color grey
width 0.25
numbers 1
end

# Fancy N arrow
point 84.4% 83%
symbol extra/n_arrow1
rotate 0.875
fcolor black
size 15
end
text 84.2% 90% N
rotate 0.875
end
point 84.4% 83%
symbol basic/circle
fcolor none
size 35
end
end
EOF

It is also possible to estimate this angle by reprojecting two points within the map with the same longitude, and then using trigonometry on the resulting coordinates. For example:
g.region -b
...
center latitude: 103:45:00.965601W
center longitude: 44:26:09.69961N

echo -e "103d45'W 44d26N\n 103d45'W 44d27N" | m.proj -i
...
599526.26 4920549.57 0.00
599497.97 4922400.85 0.00

# reverse normal atan2(y,x) as we use CW from north as 0 degrees, not CCW from east for theta
# thus atan2(x2-x1, y2-y1) gives angle in radians
echo "599526.26 599497.97 4920549.57 4922400.85" | \
awk '{print atan2($2-$1,$4-$3) * (180/3.14159265) * -1}'
0.875487

Which is reasonably close to the more trusted value given by the ''proj'' software, and good enough for our purposes.

==== Centering a map of fixed scale ====

By default ''ps.map'' centers the image at the top of the page and adjusts the map scale to suit. If you set a fixed map scale it will then place the map box at the top-left margins. Note that if the scale does not fit on the page it will be adjusted so it does, so keep an eye on it.

A method to recenter a map box with fixed scale follows. It involves the 'gv' program and a hand calculator. It is hoped in future this can be set automatically ... a pain, but you only have to do it once per map.
Example uses the Spearfish dataset.

: 1. Run the ps.map process with no scale.
ps.map out=test.ps << EOF
raster elevation.dem
end
EOF

Scale set to 1 : 102867.
Reading raster map <elevation.dem in PERMANENT> ...
PostScript file [test.ps] successfully written.

If you view the resulting PS file you will see it nicely centered, i.e. extending to the left and right margins.

: 2. Change the scale shown by the program up to some nice round number and run ps.map again.
ps.map out=test.ps << EOF
raster elevation.dem
scale 1:125000
end
EOF

Scale set to 1 : 125000.
Reading raster map <elevation.dem in PERMANENT> ...
PostScript file [test.ps] successfully written.

Note the scale is set to what we asked it to be, and the map box is now smaller and justified to the top-left margins.

: 3. Open the map in gv,
gv test.ps
and note a few numbers: the coordinate of the right edge of the paper (596 for A4), the right-hand border of the map box (466 for the above example), and the left edge of the map box (36 in the above example). tip: use the middle mouse button to draw a temporary zoom box in gv.

:{| border=1
|''These numbers are measured in "points", which are 1/72". So the left edge of the map box is at 36pt, or 1/2", the default left margin.''
* You can use this to convert the cursor coordinate in ''gv'' to inches for use with the various ps.map decorations which require placement in inches measured from the top-left corner of the page.
* In the same way a font of size 10 is 10/72" tall, a 72pt font is exactly 1" tall on the printed page.
|}

You can then calculate the map location to use to center the map box by finding the average of the current margins (in points):
avg_margin = ( (page_right - box_right) + box_left ) / 2

And then converting points to inches:
avg_margin / 72.0

So for this example the map should be centered if 1.146" left and right margins are used. Use the <tt>maploc</tt> instruction to place the map.
ps.map out=test.ps << EOF
raster elevation.dem
scale 1:125000
maploc 1.146 1.0
end
EOF

Voilà!

=== Format Conversions ===
==== Converting SVG to EPS ====

The ps.map '''eps''' and '''vpoints''' instructions can display an EPS symbol at points on the map. For instructions on how to convert SVG images to EPS using [http://www.inkscape.org/ Inkscape], see the [[IconSymbols#Other_contributions|symbols]] help page.

==== PostScript files are simply plain text files! ====

To fix typos, insert special characters, etc., you can open the PostScript file in your favorite industrial-strength text editor, search for the text string, make the edit and resave. Much easier then regenerating the graph for something as simple as a spelling mistake or a figure number change.

==== Converting PostScript to PDF ====

[http://pages.cs.wisc.edu/~ghost/doc/AFPL/6.50/Ps2pdf.htm ps2pdf] is a GhostScript wrapper for converting PostScript files to PDF. The default is to create PDF with rasters sampled at 72dpi for viewing on a computer screen. To render at 1200dpi with defaults set for high quality printing, you can add some gs options to the operation:

ps2pdf -dPDFSETTINGS=/prepress -r1200 filename.ps

* See also: [http://www.grassbook.org/neteler/highres_pdf.html Creating High Resolution PDF files for book production with Open Source tools] by Markus Neteler.
: [http://lists.osgeo.org/pipermail/grass-user/2010-January/053946.html some tips from Vincent Bain]

==== PDF files are simply containerized PostScript files! ====

Well, perhaps it is better to say they are an evolution. If you uncompress the PDF file you can edit it just as in the PostScript editing example above, and then recompress when you are done. A nice tool to compress/decompress PDF is [http://www.accesspdf.com/pdftk/ pdftk].
The pdftk program also lets you do nice things like concatenate a series of PDF pages into a single PDF document, and split a multi-page document into a series of single page PDFs. Very handy for splicing figures into a bigger document.

==== Converting PostScript to PNG ====

The <tt>pstoimg</tt> program from [http://www.latex2html.org/ latex2html] does a fine job of this (it's a Ghostscript front-end).

Example:
# convert to PNG
pstoimg -antialias -aaliastext -out flood_warning.png -scale 1.3 \
-crop tb flood_warning.ps

=== Integration with other software ===

You can use 3rd party software to fine-tune and annotate your maps.
: '''''Please populate with tips!'''''

* Translate to many different vector formats for further editing with [http://www.pstoedit.net/pstoedit pstoedit]

* [http://www.inkscape.org/ Inkscape]
: -

* [http://www.scribus.net/ Scribus]
: -

* Illustrator
: -

* R Statistics
: You can save small graphs as EPS, then display them at point/centroid positions on the map using the '''eps''' or '''vpoints''' instructions. (see Belgium "ages" example script above)
# plot some North Carolina data (imported with readVECT6() of spgrass6 class)
plot(nc_state, axes=TRUE)
plot(precip30n, add=TRUE, lwd=2, col="brown")
# generate EPS:
dev.copy2eps()
# convert with ps2pdf to PDF

[[Category:Documentation]]
[[Category:FAQ]]
[[Category:ps.map]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

[http://www.prlog.org/11289974-phone-number-lookup-verizon-phone-number-reverse-lookup-to-get-information-you-need-quickly.html phone number lookup]

PostGIS

2011-12-30T20:56:55Z

⚠️Reverse22:

See also [[Working with external data in GRASS 7|working with external data in GRASS 7]].
__TOC__
== Help pages ==

* {{cmd|databaseintro|desc=Database management in GRASS GIS}} help page
* {{cmd|sql|desc=SQL support in GRASS GIS}} help page

* {{cmd|grass-pg|desc=PostgreSQL driver in GRASS}} help page
* {{cmd|grass-odbc|desc=ODBC driver in GRASS}} help page

== Link to external dataset ==

* input maps: {{cmd|v.external|version=70}}
*::(in GRASS 6 links are read only, for GRASS 7 see [[Working with external data in GRASS 7#Vector data|working with external data in GRASS 7]])
* output maps: {{cmd|v.external.out|version=70}} (GRASS 7 only)

== Import into GRASS ==

# {{cmd|v.in.ogr}} (import only geometry column from postgresql/postgis)
# {{cmd|v.clean}}

There is a fundamental difference between the PostGIS format which is
non-topological (OGC simple feature-based) and the internal GRASS format which is topological and
which, thus, does not really allow for overlapping polygons. You can
digitize them, but they are not really useful...

{{YouTube|JoqIkL2VRVc|desc=Importing PostGIS layers into GRASS}}

== Link to GRASS ==

You can register a PostGIS layer into GRASS using {{cmd|v.external}}, eg. PostGIS layer 'lakes' from database 'pgis_nc'

v.external dsn=PG:dbname=pgis_nc layer=lakes

It will create in the current mapset new vector map 'lakes', the module also builds pseudo-topology for this map,

To link a PostGIS layer from non-public schema

v.external dsn=PG:<connection sting> layer=<schema>.<layer> output=<layer>

''Important note:'' In GRASS 6 this link is read-only, in GRASS 7 it's possible to modify linked layers directly via OGR library, see [[Working with external data in GRASS 7#Vector data|working with external data in GRASS 7]].

You can also link a GRASS layer to a PostgreSQL attribute table, though {{cmd|v.db.connect}}.

{{YouTube|eB3_SmE3E9Q|desc=Link PostGIS layers as GRASS vector maps}}

== Export to PostGIS ==

To export GRASS vector map layer to PostGIS layer use {{cmd|v.out.ogr}}, eg.

v.out.ogr in=lakes@PERMANENT dsn=PG:dbname=pgis_nc format=PostgreSQL type=area

Note that exporting data can be quite time-consuming task, especially when input vector map attributes are stored in DBF format. It's recommended to store attribute data in {{cmd|grass-sqlite|desc=SQLite format}} rather then in old-fashioned {{cmd|grass-dbf|desc=DBF format}}. For example when exporting vector map 'lakes' from [http://grass.osgeo.org/download/data.php North Carolina] sample dataset.

* Attributes in DBF format

real 1m15.072s
user 1m6.160s
sys 0m3.824s

* Attributes in SQLite format

real 0m11.796s
user 0m5.564s
sys 0m4.148s

{{YouTube|DTMmmcVpJKk|desc=Creating model which exports all GRASS vector maps from given mapset to PostGIS database}}
{{YouTube|uStN3F6ZZoc|desc=Creating model which exports all GRASS vector maps from given mapset to PostGIS database (including schema)

1) create schema with name of input mapset

2) copy vector maps from selected mapset to the current and stores their attributes in SQLite database

3) exports GRASS vector maps to the selected PostGIS database
}}

See also [[wxGUI Modeler]].

== Direct access to PostGIS data ==

''Important note:'' Direct read/write access is implemented only in GRASS 7.

=== Direct read access ===

GRASS 7 enables the users to access PostGIS layers directly via virtual mapset 'OGR' and modules parameters <code>map=OGR_datasource@OGR</code> and <code>layer=OGR_layer</code>, eg. to access PostGIS layer 'lakes' from database 'pgis_nc'

v.info map=PG:dbname=pgis_nc@OGR layer=lakes

The direct read access avoids need of creating a link via {{cmd|v.external|version=70}} and accessing PostGIS data directly without creating any data elements in the current mapset. The main drawback of direct read access is that the pseudo-topology is built each time when accessing the data.

=== Direct write access ===

''Note:'' direct write access via OGR library is currently under development (GRASS 7 only).

GRASS 7 allows to write output vector map directly via OGR library. For defining output vector data format is designed {{cmd|v.external.out|version=70}} module. For example

v.external.out dsn=PG:dbname=pgis_nc format=PostgreSQL

causes that every newly created vector map will be stored as PostGIS layer in database 'pgis_nc' without any data elements created in the current mapset. Such PostGIS layer can be linked afterwards via {{cmd|v.external|version=70}} or accessed directly as described in the section above. For example

v.extract input=lakes out=reservoir where="FTYPE = 'RESERVOIR'"
v.info map=PG:dbname=pgis_nc@OGR layer=reservoir

To switch back to GRASS native format enter

v.external.out -r

== See also ==

* [http://www.surfaces.co.il/?p=645 Tutorial by Micha Silver]
* [http://gdal.org/ogr OGR library]

[[Category: FAQ]]
[[Category: Vector]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

[http://www.prlog.org/11289974-phone-number-lookup-verizon-phone-number-reverse-lookup-to-get-information-you-need-quickly.html phone number lookup]

How to participate in IRC communication

2011-12-30T20:53:33Z

⚠️Reverse22:

==Background==

[http://en.wikipedia.org/wiki/Internet_Relay_Chat Internet Relay Chat] (IRC) is an online system of communication. It is a form of instant communication over the Internet. It is mainly designed for group (many-to-many) communication in discussion forums called channels, but also allows one-to-one communication. The basic means of communication in an established IRC session is a channel. Users can join to channels (using the command /join #channelname) and then send messages to it, which are then relayed to all other users in the same channel. Users access IRC networks by connecting a client to a server. There are many client and server implementations. Most IRC servers do not require users to log in, but a user will have to set a nickname before being connected.

The GRASS community uses the dedicated channel ([irc://irc.freenode.net/grass #grass] on irc.freenode.net), feel free to join. There are many other geo related channels such as [irc://irc.freenode.net/gdal #gdal], [irc://irc.freenode.net/qgis #qgis], [irc://irc.freenode.net/mapserver #mapserver], [irc://irc.freenode.net/osgeo #osgeo], [irc://irc.freenode.net/proj #proj] etc. The German speaking FOSSGIS (former GAV) community uses the channel [irc://irc.freenode.net/fossgis #fossgis].

People interested in being involved in the [http://pkg-grass.alioth.debian.org/ Debian GIS project] can join a dedicated channel ([irc://irc.oftc.net/debian-gis #debian-gis] on irc.oftc.net). A [irc://irc.oftc.net/geo #geo] channel is also available on the same network.

==Logs of communication==

Thanks to Gary Sherman (QGIS project) and his friendly 'sigq' IRC bot, the communication is archived:

* GRASS (#grass) - http://logs.qgis.org/grass/
* OSGeo Foundation (#osgeo) - http://logs.qgis.org/osgeo/
* QGIS (#qgis) - http://logs.qgis.org/slogs

==How to do it the first time==

#Get a IRC client software (see [http://en.wikipedia.org/wiki/List_of_IRC_clients software list]). We like the [https://addons.mozilla.org/extensions/moreinfo.php?id=16 Chatzilla extension for Firefox], [http://gaim.sourceforge.net/ gaim], [http://xchat.org/ xchat] and on MacOSX the [http://colloquy.info/ Colloquy] software.
#Connect to IRC, for "our" channels to a freenode.net server ([http://freenode.net/irc_servers.shtml list of servers]).
#Define some settings: Here some useful commands which you will enter into the field to also enter the communication (be aware to not start such commands with a space!). Anything started with /command will not be visible to the others:

Web based alternatives to join a channel (don't forget to select a reasonable nick name):
* Use the [http://irc.telascience.org/ OSGeo Web interface to IRC/#grass]
* Use the [http://webchat.freenode.net/ Web interface to IRC]
* Use the [http://irc.netsplit.de/webchat/?net=freenode&room=%23grass Netsplit JAVA interface to IRC/#grass]

<pre>
# select nick name
/nick yournickname

## better don't show your email address:
/ns set hide email on

### register (only one time needed) - PW is in clear text!!
/msg NickServ register [password] [email]

### identify yourself to the IRC server (always needed) (xxxx == pw)
/msg NickServ IDENTIFY xxxx
</pre>

====Join a channel====

<pre>
/join #grass
</pre>

Now you will see (depends on your client) the list of people lurking in the channel. You may convey your greetings and go ahead for conversation...
See below how to automate the identification process.

http://grass.osgeo.org/images/irc_chatzilla.png

<p>

The communication is logged (see [http://logs.qgis.org/grass/ #grass archives]).

==Some useful hints==

With chatzilla and other clients you can set your nickname in the preferences. You can also open several channels at time. It's convenient to automate the identification.

===Chatzilla auto-identification===

You can put the next command as "autoscript" into chatzilla's settings
for each channel, see Edit -> Preferences -> Global Settings -> Startup tab
-> Auto-url [someone please verify this, probably it's sufficient to type
below one time into chatzilla]:
<pre>
# auto-identify yourself to the IRC server (xxxx == pw)
/network-pref autoperform msg nickserv identify xxxx
</pre>

To quickly open the GRASS channel in Chatzilla, simply click here:
irc://freenode/grass

Try to find the [http://freenode.net/irc_servers.shtml next freenode server] to have speedy connection (e.g., Italy: irc://calvino.freenode.net/grass).

===TAB extension===

A nice feature is to use TAB key for type completion of nick names
in the channel - just try it!

===IRC Ghosts===

If your communication crashed, it can happen that your nick is still online, a so-called "ghost". When you login again, an underscore will be added to your nick name. To takeover your own nick name, you have to kill the "ghost" by entering next command with your password (takes some seconds):

<pre>
# kill ghost after crash (xxxx == pw)
/msg NickServ ghost yournickname xxxx
</pre>

The nick server will then remove the "ghost" and give you your nick name back.

==Further reading==

* [http://en.wikipedia.org/wiki/Internet_Relay_Chat Wikipedia article]
* [http://freenode.net/faq.shtml#contents-userregistration FAQ freenode on user registration and more]

[[Category:Community]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

Help with 3D

2011-12-30T20:53:11Z

⚠️Reverse22:

== Raster 2.5D Surfaces ==

This is the "typical" case, and most {{cmd|raster}} (GRASS r.* modules) work in this mode. The GIS layer is defined by north,south,east,west and the raster map's cell values represent the elevation.

* {{cmd|rasterintro}}: An introduction to raster processing in GRASS GIS

Snippet from the [http://en.wikipedia.org/wiki/2.5D Wikipedia definition] for 2.5D: "The idea is that the program's canvas represents a normal 2D painting surface, but that the data structure that holds the pixel information is also able to store information regarding z-index (depth) as well as other information such as material settings, specularity, etc. With this data it is thus possible to simulate lighting, shadows, and so on."

Horizontal (2D) region settings are handled by the ''g.region'' module. The third dimension is unbound.

2.5D rasters may be visualized in 3D with GRASS's [[NVIZ]] program, or as a shaded relief in 2D space with the {{cmd|r.shaded.relief}} module.

==== Screenshots ====

:[[Image:srtmV2_trento_small.jpg]]
* [http://grass.osgeo.org/grass61/screenshots/raster.php GRASS 6.1 elevation screenshots]

:[[Image:olympus_mons-medium.jpg]]
* [http://bambi.otago.ac.nz/hamish/olympus_mons.html Olympus Mons (Mars) topography] viewed with NVIZ

==== Example ====

([http://grass.osgeo.org/download/data6.php spearfish dataset])
g.region rast=elevation.10m
nviz elev=elevation.10m

== Raster 3D Volumes (voxels) ==

Support for 3D rasters (voxels) is relatively new in GRASS and is primarily handled by the {{cmd|raster3D|desc=r3.* modules}}.
A 3D raster can be thought of as a stack of 2D raster maps forming a 3D cube of data cells.

* {{cmd|raster3dintro|desc=An introduction to 3D raster processing in GRASS GIS}}

The third dimension need not be limited to "z" elevation! It can just as well represent the time dimension in a time series of 2.5D raster surfaces. It is possible to make a '''4D''' visualization using the [[NVIZ]] software's animation panels and movie making facility.

==== Screenshots ====

:[[Image:nviz_isosurf3d_small.jpg]]

* NVIZ [http://grass.osgeo.org/grass60/screenshots/images/nviz_isosurf3d.jpg Precipitation isosurfaces above Slovakia]

-----

: [[Image:chal3d_i.gif]] [[Image:chal4d_i.gif]]

* [http://skagit.meas.ncsu.edu/~helena/gmslab/viz/ches.html Chesapeake Bay Nitrogen Levels (4D)] from NCSU GMS Lab (''Mitasova et al.'')

-----
[[Image:r.to.rast3.png]]
* {{cmd|r.to.rast3}}

-----

[[Image:r3.to.rast.png]]
* {{cmd|r3.to.rast}}

-----

[[Image:r.to.rast3elev.png|400px]]
* {{cmd|r.to.rast3elev}}

-----

[[Image:r3.cross.rast.png|400px]]
* {{cmd|r3.cross.rast}}

-----

==== Region settings ====
Region settings are handled by the {{cmd|g.region}} module.
Special 3D raster controls for ''g.region'' include:
-3 flag: Prints 3D settings
rast3d Set region to match this 3D raster map (both 2D and 3D values)
t Value for the top edge
b Value for the bottom edge
res3 3D grid resolution (north-south, east-west and top-bottom)
tbres Top-bottom grid resolution 3D


==== Tips ====

* From the mailing list: [http://thread.gmane.org/gmane.comp.gis.grass.user/12869/focus=12873 Raster 3D from DEMs (drillhole data)]


==== Examples ====

* [http://mpa.itc.it/grasstutor/data_menu2nd.phtml Slovakia 3D precipitation]

* Custom volume creation. Here is a small ''[http://www.gnu.org/software/octave/ Octave]'' (''Matlab'') script to create a text file suitable for loading as a 3D raster with {{cmd|r3.in.ascii}}. Here is the file that this script creates: [http://bambi.otago.ac.nz/hamish/grass/vox_data50.txt.gz vox_data50.txt.gz]

% f(x,y,z) = x + (y^2 /2) + z^2
x= y= z= 50;

cd ~/grass/
fp = fopen('vox_data50.txt', 'wt')

fprintf(fp, 'north: %d\n', y);
fprintf(fp, 'south: 0\n');
fprintf(fp, 'east: %d\n', x);
fprintf(fp, 'west: 0\n');
fprintf(fp, 'top: %d\n', z);
fprintf(fp, 'bottom: 0\n');
fprintf(fp, 'rows: %d\n', y);
fprintf(fp, 'cols: %d\n', x);
fprintf(fp, 'levels: %d\n', z);

for dep = 1:z
for row = 1:y
for col = 1:x
fprintf(fp, '%.4f', col + (row^2 /2) + dep^2 );
if(col < 50)
fprintf(fp, ' ');
end
end
fprintf(fp, '\n');
end
disp(['dep ' num2str(dep)])
fflush(stdout);
end
fclose(fp)

Load the data with:
r3.in.ascii in=vox_data50.txt out=vox50

display isosurfaces with:
g.region rast3d=vox50
nviz -q
Panel->Raster volumes
[New] vox50
Isosurface [Add] [New Constant] 500 [Accept]
(repeat for 1000,2000,3000)
Change main view height to 125.00 (manual entry)

extract a slice to a 2D raster map with:
g.region t=26.0 b=25.0
r3.to.rast in=vox50 out=vox50x

== Vector 3D point data ==

''Historical note: known as "site data" in GRASS GIS 5''

In the "typical" case, "z" data is stored as a non-spatial attribute in a vector point map. In GRASS 6 it is possible to create 3D vector files, i.e. points exist in 3D space.

* {{cmd|vectorintro}} - An introduction to vector processing in GRASS GIS

==== Import ====

* Import x,y,z,... data as 3D with the {{cmd|v.in.ascii}} "-z" flag and "z=" column parameter:
v.in.ascii -z format=point cat=1 x=2 y=3 z=4

* You can convert a 2D vector into a 3D vector with {{cmd|v.extrude}} (take elevation values from vector attribute column) or {{cmd|v.drape}} (interpolate elevation values from a raster DEM map).

* It may be more convenient to import massive datasets (millions and millions of points) with {{cmd|r.in.xyz}} to create a 2.5D raster map.

==== Conversion to 3D raster volume ====

* Use the {{cmd|v.vol.rst}} module to interpolate 3D vector points into a 3D raster volume.

==== Screenshot ====

3D points defining the hull of a ship, visualized using [[NVIZ]]

[[Image:Ship.png|center]]

==== Example ====

TODO: ''import star guide and display using NVIZ, using magnitude column in database table for dynamic sizing. Requires a "Free" dataset, if you have any leads, please add links to this wiki page. Thanks.''

== Vector 3D lines ==

The GRASS vector engine is fully 3D aware, so 3D lines such as highways which cross at a bridge, but do not touch, can be modelled.

* 3D line objects can be displayed with [[NVIZ]]
:(place above a 2D raster isosurface)

== Vector 3D polygons ==

In the "typical" case, "z" data is stored as a non-spatial attribute in a vector point map. In GRASS 6 it is possible to create 3D vector files,
i.e. lines and polygons exist in 3D space. The topological nature of GRASS 6's vector engine means that roads can cross via a bridge without topologically meeting.

* 3D feature types
** ''face'': The 3D equivalent of a boundary. These combine to form a volume surface (e.g. a teapot)
** ''kernel'': The 3D equivalent of a centroid (''infrastructure for kernels is in place, but they are currently mostly unused'')
** ''volume'': An enclosed 3D space. The 3D equivalent to GRASS's ''area'' vector feature, meaning an alias to a "face(s)+kernel" set.  (''some infrastructure and place-holders exist, but not much in the way of practical applications has been coded yet'')

* {{cmd|vectorintro}}: An introduction to vector processing in GRASS GIS

* The [http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass6/doc/vector/vector.html#ascii GRASS ASCII format specification]

* The ''v.in.ascii'' '''-z''' flag must be used to create a 3D file

* The {{cmd|v.in.dxf}} or ''v.in.dwg'' modules can import 3D vector surfaces. DXF files are usually imported without georeference. To move into the geo-space of the rest of your data they must be projected with ''v.proj'' or translated with ''v.transform''. If working with them alone, it is recommended to use a simple XY location.

* Visualization with NVIZ: must be placed on a raster surface or constant surface. It may be useful to set the transparency attribute of the raster surface to something unobtrusive.

==== Getting data and data conversion ====

There are many free 3D mesh files available for research purposes from [http://www-rocq1.inria.fr/gamma/download/download.php INRIA.fr's GAMMA project]. These can be converted from e.g. 3D Studio (.3ds) format into DXF files with a converter program like [http://ftp.carnet.hr/pub/misc/VRML/utilities/converters/ wcvt2pov.exe] (runs well in Linux under wine). Then use v.in.dxf.
Also [http://www.blender.org/ Blender] does a nice job for exporting to 3D DXF.

''' wcvt2pov.exe supported file formats '''
* load: AOFF (*.geo), AutoCAD DXF (*.dxf), 3D Studio (*.3ds), Neutral File Format (*.nff), RAW (*.raw), TPOLY (*.tpo), True Type Font (*.ttf), Wavefront (*.obj), World Toolkit (*.nff)

* save: AutoCAD DXF (*.dxf), 3D Studio (*.asc), Neutral File Format (*.nff), Povray V2.2 (*.pov), Povray V2.2 Include (*.inc), RAW (*.raw), TPOLY (*.tpo), True Space (*.cob), VRML V1.0 (*.wrl), Wavefront (*.obj), World Toolkit (*.nff)

==== Screenshots ====

* [http://grass.osgeo.org/grass61/screenshots/vector.php GRASS 6 screenshots]
:[[Image:object_nviz_from_dxf_mesh_small.jpg]]

* ''3D DXF Mesh object, created in [http://www.blender.org Blender] and imported into GRASS (screenshot: A. Bezzi, M. Neteler)''

:[[Image:trento3d_small.jpg|450px]]

* '' GRASS: building footprints extruded to 3D blocks (screenshot: M. Neteler)
:(data courtesy City of Trento, Italy - see "Mostra Strumenti Dati" for geodata download)''


:[[Image:Nviz watertower.jpg]]
* Watertower imported with ''v.in.dwg'' (or use v.in.dxf) displayed over a 2.5D raster surface with color orthophoto raster providing ground coloration.

==== Example ====
pyramid: the following is an example of 3D vector surfaces in GRASS's standard ascii format. load with v.in.ascii.

# 3D Pyramid in GRASS: (kernel type still unused in GRASS 6)
# v.in.ascii in=pyramid.vasc out=pyramid_3d format=standard -nz
# g.region n=150 s=-50 w=-50 e=150 res=10
# r.mapcalc one=1
# nviz elev=one vect=pyramid_3d
#
# tip: in nviz try setting the raster surface transparency to 50%
#
F 5
0 0 10
0 100 10
100 100 10
100 0 10
0 0 10
F 4
0 0 10
50 50 80
100 0 10
0 0 10
F 4
0 100 10
50 50 80
0 0 10
0 100 10
F 4
100 100 10
50 50 80
0 100 10
100 100 10
F 4
100 0 10
50 50 80
100 100 10
100 0 10
K 1 1
40 50 40
1 1

== Visualization Tools ==

* [[NVIZ]]: GRASS's own ''n''-dimensional visualization suite
** [http://grass.osgeo.org/screenshots/viz.php Screenshots]

* [[wxNviz]]: wxGUI 3D view mode extension

* output to VTK & Paraview ({{cmd|r.out.vtk}}, {{cmd|r3.out.vtk}}, {{cmd|v.out.vtk}})
** [[GRASS and Paraview]]
** [http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/ Screenshots] (seek Para* there)

* output to [[POV-Ray]] ({{cmd|r.out.pov}}, {{cmd|v.out.pov}})
** [http://mpa.itc.it/markus/povray/ Screenshots]

* output to Vis5D ({{cmd|r3.out.v5d}})

* output to VRML (3D virtual reality) ({{cmd|r.out.vrml}})

* output to KML (Google Earth) ({{cmd|v.out.ogr}}, {{AddonCmd|r.out.kml}}, {{AddonCmd|v.out.kml}})

* output to DXF (Blender, AutoCAD, ...) ({{cmd|v.out.dxf}})

[[Category:Documentation]]
[[Category: Visualization]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

Help

2011-12-30T20:52:56Z

⚠️Reverse22:

<center>
'''For experiments use [[Sandbox]]...'''
</center>
__TOC__
== What's a Wiki ==

A wiki is software that allows registered users or anyone to collaboratively create, edit, link, and organize the content of a website, usually for reference material. Wikis are often used to create collaborative websites and to power community websites. These wiki websites are often also referred to as wikis; for example, [http://wikipedia.org Wikipedia] is one of the best known wikis. Wikis are used in businesses to provide affordable and effective intranets and for Knowledge Management. Ward Cunningham, developer of the first wiki, WikiWikiWeb, originally described it as "the simplest online database that could possibly work"
<div align="right"> From [http://en.wikipedia.org/wiki/Wiki Wikipedia], the free encyclopedia</div>

We use [http://www.mediawiki.org MediaWiki] platform for the GRASS-Wiki.

== Editing pages ==

* http://www.mediawiki.org/wiki/Help:Editing_pages
* http://en.wikipedia.org/wiki/Help:Editing
* http://en.wikipedia.org/wiki/Help:Table
* http://www.ascii.cl/htmlcodes.htm (if you search for a certain character)

=== Some examples ===

<pre>
* It's easy to create a list:
** Start every line with a star.
*** More stars means deeper levels.
**** A newline in a list marks the end of a list item.

* An empty line starts a new list.

# Numbered lists are also good
## very organized
## easy to follow
### easier still

; Definition list : list of definitions
; item : the item's definition
; another item
: the other item's definition
</pre>

* It's easy to create a list:
** Start every line with a star.
*** More stars means deeper levels.
**** A newline in a list marks the end of a list item.

* An empty line starts a new list.

# Numbered lists are also good
## very organized
## easy to follow
### easier still

; Definition list : list of definitions
; item : the item's definition
; another item
: the other item's definition

== Importing content ==

Here are some HTML to MediaWiki syntax converters:

* http://www.jtidy.de/
* http://diberri.dyndns.org/wikipedia/html2wiki/index.html

== Language policy ==

* [[GRASS-Wiki:Language policy|Language policy]]

== Templates ==

* [[:Category:Templates|List of templates]]

== Categories ==

* [[Special:Categories|List of categories]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

GRIB

2011-12-30T20:52:47Z

⚠️Reverse22:

* ''see also the [[Meteorology]] wiki page''

== GRIB data ==

Meteorological data from the [http://www.wmo.int WMO] is supplied in GRIB format. See the [http://www.gdal.org/frmt_grib.html GDAL GRIB format page].

* Some data available here:
** http://www.globalmarinenet.net/grib.htm
** http://www.raymarine.com/default.aspx?site=1&section=3&page=149
** http://www.navcenter.com/newdwnld.ccml

* GRIB data viewer:
** zyGRIB (GPL3)
: http://www.zygrib.org (French; translate with [http://babelfish.yahoo.com/ Babelfish])

Newer versions of [http://www.gdal.org GDAL] can read this data (i.e. newer than the 1.5 branch; SVN trunk is best), and it can be imported with {{cmd|r.in.gdal}}.

It often contains a small number of cells but many many bands (layers).

View band metadata with <tt>gdalinfo</tt>.

=== Processing ===

A mini-tutorial follows.

The data is in Lat/Lon on a Sphere. It is not quite correct to import into a Lat/Lon WGS84 location, but the resolution is so crude that you might be able to hold your nose and do so anyway.

* ''There is a cell-registration bug in GDAL: (grid vs cell-center convention) cells are all offset to the east and south by half a cell. You can fix this by hand with the {{cmd|r.region}} module. See:''
: https://trac.osgeo.org/gdal/ticket/2550
: https://trac.osgeo.org/gdal/ticket/2637
: GRASS's [[Grid registration]] wiki page for a general discussion

==== GDAL bug workaround ====
<source lang="bash">
g.region rast=mapname
eval `g.region -pg`
HALF_NSRES=`echo "$nsres" | awk '{printf("%.15g", $1 / 2.)}'`
HALF_EWRES=`echo "$ewres" | awk '{printf("%.15g", $1 / 2.)}'`
NEW_N=`echo "$n" "$HALF_NSRES" | awk '{printf("%.15g", $1 + $2)}'`
NEW_S=`echo "$s" "$HALF_NSRES" | awk '{printf("%.15g", $1 + $2)}'`
NEW_E=`echo "$e" "$HALF_EWRES" | awk '{printf("%.15g", $1 - $2)}'`
NEW_W=`echo "$w" "$HALF_EWRES" | awk '{printf("%.15g", $1 - $2)}'`

r.region mapname n=$NEW_N s=$NEW_S e=$NEW_E w=$NEW_W
</source>

* ''Currently band metadata is not automatically copied with the import. Add it in manually with'' "<tt>r.support history=</tt>".

Convert latest u,v components of wind to GeoTiff (not really needed, but easier to debug) and import into GRASS. Use <tt>gdalinfo</tt> to view the list of available bands and determine the needed band number(s).

No-data (NULL) values are flagged as "9999" in this file.

$ gdal_translate -b 1 -a_nodata 9999 TasmanSea.wind.grb TasmanSea.wind.u_wind_latest.tif
$ gdal_translate -b 2 -a_nodata 9999 TasmanSea.wind.grb TasmanSea.wind.v_wind_latest.tif

r.in.gdal -o in=TasmanSea.wind.u_wind_latest.tif out=TasmanSea.wind.u_wind_latest
r.in.gdal -o in=TasmanSea.wind.v_wind_latest.tif out=TasmanSea.wind.v_wind_latest

or import into GRASS directly:

r.in.gdal in=TasmanSea.wind.grb band=1 out=TasmanSea.wind.u_wind_latest
r.in.gdal in=TasmanSea.wind.grb band=2 out=TasmanSea.wind.v_wind_latest
r.null TasmanSea.wind.u_wind_latest setnull=9999
r.null TasmanSea.wind.v_wind_latest setnull=9999

Convert U,V velocity component maps into magnitide,direction maps for use with d.rast.arrow:
g.copy TasmanSea.wind.u_wind_latest,U_map
g.copy TasmanSea.wind.v_wind_latest,V_map

g.region rast=TasmanSea.wind.u_wind_latest -p
r.mapcalc 'magnitude = sqrt(U_map^2 + V_map^2)'
r.colors magnitude col=bcyr
r.support magnitude units="m/s"
r.mapcalc 'direction = atan(U_map, V_map)'

Convert m/s to knots:
r.mapcalc 'magnitude_kts = magnitude * 3600/1852.0'
r.support magnitude_kts units="knots"
r.colors magnitude_kts col=bcyr

Display:
d.mon x0
d.rast magnitude
d.vect admin98 type=area fcol=225:225:255 color=none

d.rast.arrow map=direction type=grass magnitude_map=magnitude grid=none arrow=black

d.legend map="magnitude" at=90.3,94.7,1.8,26.5
echo "wind (m/s)" | d.text color=black at=13.8,80.6 size=3 align=lc

Export to a PNG image using the Cairo driver:
d.out.file -c TasmanSea_winds_latest

Resulting image:
: [[Image:TasmanSea winds latest.jpg]]

==== Create contours ====

Create smooth contour lines at 5 knot intervals. First resample to a higher raster resolution with {{cmd|r.resamp.interp}} so the lines come out smooth.

g.region res=0:15 -p
r.resamp.interp in=magnitude_kts out=magnitude_kts.resamp.cube method=bicubic
r.contour in=magnitude_kts.resamp.cube out=latest_wind_5kt step=5

Alternatively the {{cmd|v.generalize}} module may be used to smooth the contours. The ''Snakes'' spline method is used here as it smooths by minimization of the "energy" in the line, which mimics the wind's natural tendency to strive for geostrophic balance.

g.region rast=magnitude_kts
r.contour in=magnitude_kts out=latest_wind_5kt_raw step=5
v.generalize in=latest_wind_5kt_raw out=latest_wind_5kt_Snakes method=snakes alpha=0.25 beta=0.25

To remove any tiny rings and slivers you can add a length column in the contours map with {{cmd|v.db.addcol}}, populate the column with line length using the {{cmd|v.to.db}} module, and finally extract only lines with a length greater than some threshold with a SQL query to {{cmd|v.extract}}.

=== Automation ===

You can automate the generation of a weather map with a little GRASS scripting (e.g. as a {{wikipedia|cron_job}}). After downloading the latest forecast with <tt>wget</tt> and extracting timestamp info with <tt>gdalinfo</tt>, with a <tt>GRASS_BATCH_JOB</tt> you can import the data into a lat/lon location with {{cmd|r.in.gdal}} and then in a following batch job from the master script use {{cmd|r.proj}} to reproject the data into another location/projection (if you choose) and run the appropriate d.* rendering commands. See the [[GRASS_and_Shell#GRASS_Batch_jobs]] wiki page and the main GRASS man page for more details.

=== TODO ===

* d.barb module: ''work in progress by Hamish'' (partially done; low on the priority list currently; still plan to finish it)

[[Category:Documentation]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

GRASS Help

2011-12-30T20:52:20Z

⚠️Reverse22:

== Getting Started ==

''Most tutorials and examples will use the [[GRASS_Help#Sample_Dataset | Spearfish County, SD]] sample dataset.'' New examples are also based on the rich [http://www.grassbook.org/data_menu3rd.php OSGeo Educational Dataset] (North Carolina, USA)

=== Installation ===

* Covered in the [[Installation Guide]]

=== Frequently Asked Questions ===

* [[Faq|FAQ]]
* You can contact GRASS users in [[How to participate in IRC communication|IRC]]
* [[How the Open Source software development model works]]

=== First Day Documentation ===

* [[GRASS 6 Terminology]]

* [[Gis Concepts|Basic GIS concepts]] and how GRASS implements them

* [http://grass.bologna.enea.it/tutorial/ Five minute program launch tutorial] by Lorenzo Moretti
: First few slides are geared for Mac OSX, the rest is generic.

* [http://grass.osgeo.org/grass64/manuals/html64_user/helptext.html GRASS Quickstart] help page

* [[Importing data]]: how to get your data into GRASS

* [http://grass.osgeo.org/grass64/manuals/html64_user/index.html GRASS help pages] including basic introductions

==== Short tutorials ====

* [[Quick_wx_tutorial|A quick introduction to the 6.4 wxGUI and raster maps]]

* Course material of [http://geostat-course.org/Topic_NetelerMetz_2011 Introduction to GRASS GIS], Geostat 2011, Landau, Germany, by M. Neteler and M. Metz

* [http://trac.osgeo.org/grass/wiki/HowToTestGrass6 How-To Test GRASS6] - easy to replicate steps with GRASS 6.3+ and QGIS

* The [[GRASS 6 Tutorial]] (a work in progress; seeking for volunteers)

* [http://www.grassbook.org/neteler/osg05/ GRASS 6 in a nutshell] by M. Neteler (2005, short tutorial, also translated to Spanish and French)

* [http://www.gdf-hannover.de/lit_html/grass60_v1.2_en/index.html An introduction to the practical use of the Free Geographical Information System GRASS 6.0] by GDF Hannover - [http://www.gdf-hannover.de/media.php?id=0&lg=en More tutorials] from GDF Hannover

==== Textbook ====

* [http://www.grassbook.org Open Source GIS: A GRASS GIS Approach. 3rd ed. 2008] by M. Neteler and H. Mitasova (Springer book; focus is on GRASS 6.3)

==== Individual modules ====

* Synopsis of GRASS modules, including menu positions ({{website|gdp/grassmanuals/grass64_module_list.pdf|PDF, 100k}}) ({{website|gdp/grassmanuals/grass64_module_list.html|HTML version}})
: ''Create current list with'' "<tt>make html2pdfdoc</tt>" or "<tt>cd tools; ./module_synopsis.sh</tt>" ''in GRASS 6.3+''

* Individual GRASS module [http://grass.osgeo.org/grass64/manuals/html64_user/index.html reference manuals]

* All GRASS module reference manuals (PDF Book)
: ''Create current set with'' "<tt>make html2pdfdoccomplete</tt>" ''in GRASS 6.3+''

=== Sample Datasets ===

* [http://www.grassbook.org/data_menu3rd.php North Carolina, USA (OSGeo Edu dataset)] - rich data set prepared in 2007/2008
* [http://grass.osgeo.org/download/data6.php Spearfish County, SD, USA] (not so far from Mount Rushmore) with [http://mpa.itc.it/markus/osg05/ extra data]
** Mount Rushmore: [43°53' N, 103°28' W]

* [[Global datasets]]

* [http://grass.osgeo.org/download/data.php More sample data]

== Further Reading ==

* [[Documents|Full GRASS Documentation]]

* [[GRASS_Education_%28Free_GIS_education%29#Teaching_Materials | Teaching materials]] contributed by the community.<BR>(Tutorials, courseware, training videos, etc.)

* More GRASS documentation and tutorials from the old [http://grass.osgeo.org/gdp/index.php GRASS Documentation Project].<BR>[''content is slowly being merged into this Wiki'']

* [[GRASS and its siblings%3B a guide for the novice]]

== Migration from other GIS Software ==

* [[GRASS_migration_hints|GRASS migration hints]]
* [[GIS to GRASS command translation|GIS Software to GRASS command translation table and discussion]]
* [[Tips for Arc users]]

== Interfacing with external software ==

* [[Tips_and_Tricks#Using_QGIS_as_a_frontend_to_GRASS| QGIS]] frontend

* [[GRASS_and_Rstat|R statistics]] interface

* [[GRASS_and_GMT|GMT mapping]] cartography

* [[GRASS_and_MapServer| MapServer]] web server

* External databases ({{cmd|db.connect}})
* External raster data ({{cmd|r.external}})
* External vector data ({{cmd|v.external}})
* [[GRASS and Paraview|Paraview]] 3D visualization ({{cmd|r.out.vtk}}, {{cmd|r3.out.vtk}}, {{cmd|v.out.vtk}})
* [[POV-Ray|POVray]] 3D visualization ({{cmd|r.out.pov}}, {{cmd|v.out.pov}})
* [[OpenSceneGraph]] 3D visualization
* [[GRASS vector export to Inkscape]]

== Misc. Help ==

* [[:Category:FAQ|GRASS FAQ]] (see also: [[GRASS 6 Tutorial]])
* [[Tips and Tricks]]
* [[Compile and install GRASS and QGIS with GDAL/OGR Plugin]]
* [[How to interpolate point value using kriging method with R and GRASS 6]]

--------
* Wiki [[Help]] (how to edit pages after registration)

[[Category: Documentation]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

GRASS Citation Repository

2011-12-30T20:52:09Z

⚠️Reverse22:

== How to cite GRASS GIS ==

Please cite GRASS when using the software in your work. Here are some choices depending on the version used:

=== GRASS GIS Manual citations ===
* GRASS Development Team, 2011. Geographic Resources Analysis Support System (GRASS) Software. Open Source Geospatial Foundation Project. http://grass.osgeo.org
* GRASS Development Team, 2011. Geographic Resources Analysis Support System (GRASS) Programmer's Manual. Open Source Geospatial Foundation Project. Electronic document: http://grass.osgeo.org/devel/index.php
* GRASS Development Team, 2011. GRASS 6.4 Users Manual. Open Source Geospatial Foundation, USA. Electronic document: http://grass.osgeo.org/grass64/manuals/html64_user/
* GRASS Development Team, 2007. GRASS 6.2 Users Manual. ITC-irst, Trento, Italy. Electronic document: http://grass.osgeo.org/grass62/manuals/html62_user/
* GRASS Development Team, 2002. GRASS 5.0 Users Manual. ITC-irst, Trento, Italy. Electronic document: http://grass.osgeo.org/gdp/html_grass5/
* U.S. Army CERL, 1993. GRASS 4.1 Reference Manual. U.S. Army Corps of Engineers, Construction Engineering Research Laboratories, Champaign, Illinois, 1-425.

Related BibTeX entry:
<pre>
@Manual{GRASS_GIS_software,
title = {Geographic Resources Analysis Support System (GRASS GIS) Software},
author = {{GRASS Development Team}},
organization = {Open Source Geospatial Foundation},
year = {2011},
url = {http://grass.osgeo.org},
}
</pre>

=== Peer reviewed general GRASS GIS articles ===
* Neteler, M., Bowman, M.H., Landa, M., Metz, M. (2012) "GRASS GIS: A multi-purpose open source GIS." Environmental Modelling & Software ([http://dx.doi.org/10.1016/j.envsoft.2011.11.014 DOI] | [http://gis.cri.fmach.it/uploads/neteler2012_grass_gis_proof.pdf PDF])

=== Books ===
* M. Neteler and H. Mitasova, 2008, Open Source GIS: A GRASS GIS Approach. 3rd Ed. 406 pp, 80 illus., Springer, New York. Online Supplement: http://www.grassbook.org/

=== Topic oriented citations ===
* see [[Citations for specific modules]]
* Citations of [[GRASS in the wild]] (add your publications here)

* Newsletter citations
** [[Newsletter citations Vol1]]
** [[Newsletter citations Vol2]]
** [[Newsletter citations Vol3]]
** [[Newsletter citations Vol4]]

* [[Historical citations]]

* Master file of all citations for download ''(todo once we have collected enough)''

== Helpful tools and GRASS related bibliographic searches ==
* [http://scholar.google.com Google Scholar] - [http://scholar.google.com/scholar?q=GRASS+GIS Search for "GRASS GIS"] (activate BibTex export in "Scholar preferences")
* [http://www.citeulike.org CiteULike] - [http://www.citeulike.org/tag/grass Search for "GRASS"]
* [http://www.scripps.edu/~cdputnam/software/bibutils/ Bibutils] bibliography conversion utilities
* [http://gbib.seul.org Gbib BibTeX editor] for GTK+Gnome
* [http://jabref.sourceforge.net/ JabRef] Multi-platform, multi-format bibliography tool
* [http://www.zotero.org/groups/gis Zotero citation manager GIS group] - with all known GRASS references

[[Category:Documentation]]
[[Category:FAQ]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

GRASS and Sextante

2011-12-30T20:51:57Z

⚠️Reverse22:

GRASS has been integrated into [http://www.sextantegis.com Sextante] as extension. Sextante itself is commonly used within gvSIG. Through this integration, gvSIG users have access to the wealth of well tested algorithms provided by GRASS.

Note: the GDAL-GRASS plugin must be installed.

== Installation ==
=== How to install the improved gvSIG OADE version ===

From version gvSIG OA Digital Edition 2010 (1.0) onwards, Sextante 0.6 with integrated GRASS GIS support is included.

You can download and install OADE gvSIG binaries from [http://oadigital.net/software/gvsigoade/ here].

'''Note 1''': If you are on a 64bit system, add this to your settings file, e.g. $HOME/.bashrc:
# 32bit fix
export LD_LIBRARY_PATH=$HOME/gvsig-oade-2010-1.0.0/grass/lib/

'''Note 2''': If you want to use latest GRASS 6.4 rather than the bundled version, you have two options:
* you can install or use an already installed version by pointing to the right path in the Sextante setup (see below);
* you can replace the included grass/ version in the gvsig-oade-2010-1.0.0/ directory. For example, get latest Linux 32bit GRASS binaries [http://grass.osgeo.org/grass64/binary/linux/snapshot/ here]. Likewise, for MacOSX (or Windows).

=== Alternative: How to install the original gvSIG version ===

From gvSIG 1.10 onwards, Sextante with integrated GRASS GIS support is included (which yet fails):

# download gvSIG binaries from [http://www.gvsig.org/web/home/gvsig-en/view?set_language=en here] (download the '''All-included version''')
# run the installer
# start gvSIG

== Activating GRASS GIS in Sextante ==

''(modified after grass_sextante.html)''

Configuring Sextante to use GRASS takes just a few easy steps. Once you have configured the system, you will be able to execute GRASS algorithms from any Sextante component like the toolbox or the graphical modeller, just like you do with any other Sextante geo-algorithm.

Only two parameters must be set, namely:
* The path to the GRASS installation folder. It is needed by Sextante to execute GRASS commands.
* The path to a GRASS mapset. Sextante is able to use a temporary mapset.

So we do the simple setup:
* Open the '''Sextante Toolbox icon'''
* Go to Sextante settings (open icon -> right of the "Search" bar at bottom of the window)
* Go to "GRASS". Set therein
** GRASS folder: /path/to/grass-binary-installation/ (e.g., /usr/local/grass-6.4.0/ )
** Activate "Create temporary mapset"
* Click on "Setup GRASS" to register the raster and vector commands
* Now click on the "Help" button to know that it is there and what it contains
* Finally click "OK" to leave the dialog. Now 5xx Sextante/GRASS commands should be available

== How to use ==

Note that GRASS is used in an internal temporary session (so you cannot open GRASS data but work on GeoTIFF, SHAPE files using GRASS through gvSIG/Sextante).

=== Getting sample data ===

A sample dataset (based on free [http://www.grassbook.org/data_menu3rd.php North Carolina dataset], packaged by B. Ducke) is coming with the gvSIG-OADE installer. Otherwise, if you prefer, you can also download and unpack it manually from [ftp://88.208.250.116/gvsig-ref-data-nc.zip here].

This data set contains several raster and vector map files. The projection is ([http://spatialreference.org/ref/epsg/32119/ EPSG code 32119]).

=== Sample session ===
# Start a new project: "File" -> "New Project" -> Click on the new name -> "Open" button
# Set the projection of the View: "View" -> "Properties" -> "Current projection" -> "Type:" select "EPSG" -> Enter code: "32119" -> Click on "Search" -> Click on "OK" -> Accept Properties with "OK"

==== Vector points map interpolation ====
# Add a vector points map with the "Add layer" icon (top menu): File -> "Add" -> Select file "geodetic_pts.shp" -> "OK"
# Zoom to a portion of the map
# Open Sextante dialog
# Go to "GRASS", expand "Vector (v.*)"
# Select "v.surf.idw" (double click)
## The SHAPE file "geodetic_pts.shp" should be preselected. Enter as column name "elevation".
## Go to the region tab and select "Use extent from view".
## Enter "Cell size": 1000 (this is in map units, here: meters)
## Click "OK" to run the computation
# The resulting IDW interpolated raster map should appear in the view.

[[Image:GvSIG OADE sextante vsurfidw.png|thumb|center|400px|gvSIG-Sextante-GRASS GIS: IDW interpolated geodetic points, North Carolina, USA]]

==== Raster map analysis: Create topographic index map from elevation map ====
# Add a raster elevation map with the "Add layer" icon (top menu): File -> "Add" -> Select File Type "Raster" -> Select file "north_carolina/wake/wake_elevation.tif" -> "OK", "Accept" projection.
# "Zoom to layer" with right mouse button in the legend
# Open Sextante dialog
# Go to "GRASS", expand "Raster (r.*)"
# Go to "r.topidx"
## Start (double click) r.topidx, the map "wake_elevation.tif" should be predefined, as output write "wake_topidx.tif" (it will go into your current directory; check with browse button),
## Go to the region tab and select "Use extent from view".
## Enter "Cell size": 10 (this is in map units, here: meters)
## Click "OK" to run the computation
# It should have generated a new map which should appear in the view.

[[Image:GvSIG OADE sextante rtopidx.png|thumb|center|400px|gvSIG-Sextante-GRASS GIS: Topographic index map from elevation map, North Carolina, USA]]

== See also ==

* Victor Olaya's [http://sextantegis.blogspot.com/2009/07/nantes-ogrs-2009.html blog announcement] of the integration
* V. Olaya, JC Giménez, 2010: [http://2010.foss4g.org/presentations_show.php?id=3382 Integrating Sextante and GRASS]. FOSS4G 2010, Barcelona
* M. Neteler, 2011: GRASS GIS e Sextante. [http://www.gvsig.org/web/community/events/giornate-italia/2011/Programa Quarte Giornate Italiane di gvSIG], 19-21 Apr 2011, Udine, Italy ([http://gvsig-desktop.forge.osor.eu/downloads/pub/events/giornate-triestine/2011/Presentazioni/GRASS_GIS_and_Sextante.pdf PDF])

[[Category: Documentation]]
[[Category: FAQ]]
[[Category: Linking to other languages]]
[[Category: Tutorial]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

GRASS and Python

2011-12-30T20:51:41Z

⚠️Reverse22:

''(for discussions on the new GRASS GUI, see [[GRASS GUI|here]])''

==Python SIGs==
Python Special Interest Groups are focused collaborative efforts to develop, improve, or maintain specific Python resources. Each SIG has a charter, a coordinator, a mailing list, and a directory on the Python website. SIG membership is informal, defined by subscription to the SIG's mailing list. Anyone can join a SIG, and participate in the development discussions via the SIG's mailing list. Below is the list of currently active Python SIGs, with links to their resources.

See more at http://www.python.org/community/sigs/

==Writing Python scripts in GRASS==

Python is a programming language which is more powerful than shell scripting but easier and more forgiving than C.
The Python script can contain simple module description definitions which will be processed with {{cmd|g.parser}}, as shown in the example below. In this way with no extra coding a GUI can be built, inputs checked, and a skeleton help page can be generated automatically. In addition it adds links to the GRASS message translation system.
For code which needs access to the power of C, you can access the GRASS C library functions via the Python "ctypes" interface.

;GRASS Python Scripting Library
* http://grass.osgeo.org/programming6/pythonlib.html (GRASS 6)
* http://grass.osgeo.org/programming7/pythonlib.html (GRASS 7)

Code style: Have a look at [http://trac.osgeo.org/grass/browser/grass/trunk/SUBMITTING_PYTHON SUBMITTING_PYTHON].

=== Creating Python scripts that call GRASS functionality from outside ===

In order to use GRASS from outside, some environment variables have to be set.

==== MS-Windows ====

GISBASE= C:\GRASS-64
GISRC= C:\Documents and Settings\user\.grassrc6
LD_LIBRARY_PATH= C:\GRASS-64\lib
PATH= C:\GRASS-64\etc;C:\GRASS-64\etc\python;C:\GRASS-64\lib;C:\GRASS-64\bin;C:\GRASS-64\extralib;C:\GRASS-64\msys\bin;C:\Python26;
PYTHONLIB= C:\Python26
PYTHONPATH= C:\GRASS-64\etc\python
GRASS_SH= C:\GRASS-64\msys\bin\sh.exe

Some hints:

# The Python interpreter (python.exe) needs to be in the PATH
# Python needs to be associated with the .py extension
# PATHEXT needs to include .py if you want to be able to omit the extension
# PYTHONPATH needs to be set to %WINGISBASE%\etc\python

1-3 should be taken care of by the Python installer. 4 needs to be done by the startup (currently, this doesn't appear to be the case on MS-Windows).

Note:

Currently (as of 22 Feb 2011) if you want to use Python for scripting GRASS on Windows, the best solution is to delete the bundled version of Python 2.5 from the GRASS installation, install Python and the required add-ons (wxPython, NumPy, PyWin32) from their official installers,
then edit the GRASS start-up script to remove any references to the bundled version.

==== Linux ====

The variables are set like this:

export GISBASE="/usr/local/grass-6.4.svn/"
export PATH="$PATH:$GISBASE/bin:$GISBASE/scripts"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$GISBASE/lib"
# for parallel session management, we use process ID (PID) as lock file number:
export GIS_LOCK=$$
# path to GRASS settings file
export GISRC="$HOME/.grassrc6"

=== Running external commands from Python ===
For information on running external commands from Python, see:
http://docs.python.org/lib/module-subprocess.html

Avoid using the older os.* functions. Section 17.1.3 lists equivalents
using the Popen() interface, which is more robust (particularly on
Windows).

=== Using the GRASS Python Scripting Library ===

The code in lib/python/ provides 'grass.script' in order to support GRASS scripts written in Python. The scripts/ directory of GRASS 7 contains a series of examples actually provided to the end users (while the script in GRASS 6 are shell scripts).

Python Scripting Library code details:
* [http://grass.osgeo.org/programming6/pythonlib.html for GRASS 6]: core.py, db.py, raster.py, vector.py, setup.py, array.py
* [http://grass.osgeo.org/programming7/pythonlib.html for GRASS 7]: core.py, db.py, raster.py, vector.py, setup.py, array.py

=== Examples ===

==== Display example ====
Example of Python script, which is processed by g.parser:

<source lang="python">
#!/usr/bin/env python
#
############################################################################
#
# MODULE: d.shadedmap
# AUTHOR(S): Unknown; updated to GRASS 5.7 by Michael Barton
# Converted to Python by Glynn Clements
# PURPOSE: Uses d.his to drape a color raster over a shaded relief map
# COPYRIGHT: (C) 2004,2008,2009 by the GRASS Development Team
#
# This program is free software under the GNU General Public
# License (>=v2). Read the file COPYING that comes with GRASS
# for details.
#
#############################################################################

#%Module
#% description: Drapes a color raster over a shaded relief map using d.his
#%End
#%option
#% key: reliefmap
#% type: string
#% gisprompt: old,cell,raster
#% description: Name of shaded relief or aspect map
#% required : yes
#%end
#%option
#% key: drapemap
#% type: string
#% gisprompt: old,cell,raster
#% description: Name of raster to drape over relief map
#% required : yes
#%end
#%option
#% key: brighten
#% type: integer
#% description: Percent to brighten
#% options: -99-99
#% answer: 0
#%end

import sys
from grass.script import core as grass

def main():
drape_map = options['drapemap']
relief_map = options['reliefmap']
brighten = options['brighten']
ret = grass.run_command("d.his", h_map = drape_map, i_map = relief_map, brighten = brighten)
sys.exit(ret)

if __name__ == "__main__":
options, flags = grass.parser()
main()

</source>

==== Parsing the options and flags ====

grass.parser() is an interface to g.parser, and allows to parse the options and flags passed to your script on the command line. It is to be called at the top-level:

<source lang="python">
if __name__ == "__main__":
options, flags = grass.parser()
main()
</source>

Global variables "options" and "flags" are Python dictionaries containing the options/flags values, keyed by lower-case option/flag names. The values in "options" are strings, those in "flags" are Python booleans. All those variables have to be previously declared in the header of your script.

<source lang="python">
>>> options, flags = grass.parser()
>>> options
{'input': 'my_map', 'output': 'map_out', 'option1': '21.472', 'option2': ''}
>>> flags
{'c': True, 'm': False}
</source>

==== Example for embedding r.mapcalc (map algebra) ====

grass.mapcalc() accepts a template string followed by keyword
arguments for the substitutions, e.g. (code snippets):

<source lang="python">
grass.mapcalc("${out} = ${rast1} + ${rast2}",
out = options['output'],
rast1 = options['raster1'],
rast2 = options['raster2'])
</source>

''Best practice'': first copy all of the options[] into separate variables at the beginning of main(), i.e.:

<source lang="python">
def main():
output = options['output']
raster1 = options['raster1']
raster2 = options['raster2']

...

grass.mapcalc("${out} = ${rast1} + ${rast2}",
out = output,
rast1 = raster1,
rast2 = raster2)
</source>

==== Example for parsing raster category labels ====

How to obtain the text labels
<source lang="python">
# dump cats to file to avoid "too many argument" problem:
p = grass.pipe_command('r.category', map = rastertmp, fs = ';', quiet = True)
cats = []
for line in p.stdout:
cats.append(line.rstrip('\r\n').split(';')[0])
p.wait()

number = len(cats)
if number < 1:
grass.fatal(_("No categories found in raster map"))
</source>

==== Example for parsing category numbers ====

Q: How to obtain the number of cells of a certain category?

A: It is recommended to use pipe_command() and parse the output, e.g.:

<source lang="python">
p = grass.pipe_command('r.stats',flags='c',input='map')
result = {}
for line in p.stdout:
val,count = line.strip().split()
result[int(val)] = int(count)
p.wait()
</source>

==== Example for getting the region's number of rows and columns ====

Q: How to obtain the number of rows and columns of the current region?

A: It is recommended to use the "grass.region()" function which will create a dictionary with values for extents and resolution, e.g.:

<source lang="python">
#!/usr/bin/env python
#-*- coding:utf-8 -*-
#
############################################################################
#
# MODULE: g.region.resolution
# AUTHOR(S): based on a post at GRASS-USER mailing list [1]
# PURPOSE: Parses "g.region -g", prints out number of rows, cols
# COPYLEFT: ;-)
# COMMENT: ...a lot of comments to be easy-to-read for/by beginners
#
#############################################################################
#
#%Module
#% description: Print number of rows, cols of current geographic region
#% keywords: region
#%end

# importing required modules
import sys # the sys module [2]
from grass.script import core as grass # the core module [3]

# information about imported modules can be obtained using the dir() function
# e.g.: dir(sys)

# define the "main" function: get number of rows, cols of region
def main():

# #######################################################################
# the following commented code works but is kept only for learning purposes

## assigning the output of the command "g.region -g" in a string called "return_rows_x_cols"
# return_rows_x_cols = grass.read_command('g.region', flags = 'g')

## parsing arguments of interest (rows, cols) in a dictionary named "rows_x_cols"
# rows_x_cols = grass.parse_key_val(return_rows_x_cols)

## selectively print rows, cols from the dictionary "rows_x_cols"
# print 'rows=%d \ncols=%d' % (int(rows_x_cols['rows']), int(rows_x_cols['cols']))

# #######################################################################

# faster/ easier way: use of the "grass.region()" function
gregion = grass.region()
rows = gregion['rows']
cols = gregion['cols']

# print rows, cols properly formated
print 'rows=%d \ncols=%d' % (rows, cols)

# this "if" condition instructs execution of code contained in this script, *only* if the script is being executed directly
if __name__ == "__main__": # this allows the script to be used as a module in other scripts or as a standalone script
options, flags = grass.parser() #
sys.exit(main()) #

# Links
# [1] http://n2.nabble.com/Getting-rows-cols-of-a-region-in-a-script-tp2787474p2787509.html
# [2] http://www.python.org/doc/2.5.2/lib/module-sys.html
# [3] http://download.osgeo.org/grass/grass6_progman/pythonlib.html#pythonCore
</source>

==== Managing mapsets ====

To check if a certain mapset exists in the active location, use:

<source lang="python">
grass.script.mapsets(False)
</source>

... returns a list of mapsets in the current location.

==== r.mapcalc example ====

Example of Python script, which is processed by {{cmd|g.parser}}:

The shell script line:

<source lang="bash">
r.mapcalc "MASK = if(($cloudResampName < 0.01000),1,null())"
</source>

would be written like this:

<source lang="python">
import grass.script as grass

...

grass.mapcalc("MASK=if(($cloudResampName < 0.01000),1,null())",
cloudResampName = cloudResampName)
</source>

The first argument to the mapcalc function is a template (see the Python library documentation for [http://docs.python.org/library/string.html string.Template]). Any keyword arguments (other than quiet, verbose or overwrite) specify substitutions.

==== Using output from GRASS modules in the script ====

Sometimes you need to use the output of a module for the next step. There are dedicated functions to obtain the result of, for example, a statistical analysis.

Example: get the range of a raster map and use it in {{cmd|r.mapcalc}}. Here you can use <code>grass.script.raster_info()</code>, e.g.:

<source lang="python">
import grass.script as grass

max = grass.raster_info(inmap)['max']
grass.mapcalc("$outmap = $inmap / $max",
inmap = inmap, outmap = outmap, max = max)
</source>

==== Calling a GRASS module in Python ====

Imagine, you wanted to execute this command in Python:
<source lang="bash">
r.profile -g input=mymap output=newfile profile=12244.256,-295112.597,12128.012,-295293.77
</source>

All arguments except the first (which is a flag) are keyword arguments, i.e. <tt>arg = val</tt>. For the flag, use <tt>flags = 'g'</tt> (note that "-g" would be the negative of a Python variable named "g"!). So:

<source lang="python">
grass.run_command(
'r.profile',
input = input_map,
output = output_file,
profile = [12244.256,-295112.597,12128.012,-295293.77]
</source>
or:
<source lang="python">
profile = [(12244.256,-295112.597),(12128.012,-295293.77)]
</source>

i.e. you need to provide the keyword, and the argument must be a valid Python expression. Function <code>run_command()</code> etc accept lists and tuples.

'''Differences between ''run_command()'' and ''read_command()'':'''

* run_command() executes the command and waits for it to terminate; it doesn't redirect any of the standard streams.
* read_command() executes the command with stdout redirected to a pipe, and reads everything written to it. Once the command terminates, it returns the data written to stdout as a string.

'''How to retrieve error messages from ''read_command()'':'''

None of the existing *_command functions redirect stderr. You can do so with e.g.:

<source lang="python">
def read2_command(*args, **kwargs):
kwargs['stdout'] = grass.PIPE
kwargs['stderr'] = grass.PIPE
ps = grass.start_command(*args, **kwargs)
return ps.communicate()
</source>

This behaves like read_command() except that it returns a tuple of (stdout,stderr) rather than just stdout.

==== Percentage output for progress of computation ====

A) Within a Python script, the grass.script.core.percent() module method wraps the <tt>g.message -p</tt> command.

B) If you call a GRASS command within the Python code, you have to parse the output by setting <tt>GRASS_MESSAGE_FORMAT=gui</tt> in the environment when running the command and read from the command's stderr; e.g.

<source lang="python">
import grass.script as grass
env = os.environ.copy()
env['GRASS_MESSAGE_FORMAT'] = 'gui'
p = grass.start_command(..., stderr = grass.PIPE, env = env)
# read from p.stderr
p.wait()
</source>

If you need to capture both stdout and stderr, you need to use threads, select, or non-blocking I/O to consume data from both streams as it is generated in order to avoid deadlock.

ALTERNATIVE:

Redirect both stdout and stderr to the same pipe (and hope that the normal output doesn't include anything which will be mistaken for progress/error/etc messages):

<source lang="python">
p = grass.start_command(..., stdout = grass.PIPE, stderr = grass.STDOUT, env = env)
</source>

==== Path to GISDBASE ====

In order to a avoid hardcoded paths to GRASS mapset files like the SQLite DB file, you can get the GISDBASE variable from the environment:
<source lang="python">
import grass.script as grass
import os.path

env = grass.gisenv()

gisdbase = env['GISDBASE']
location = env['LOCATION_NAME']
mapset = env['MAPSET']

path = os.path.join(gisdbase, location, mapset, 'sqlite.db')
</source>

==Python extensions for GRASS GIS==
=== wxPython GUI development for GRASS ===

* See the [[wxGUI]] wiki page

=== GRASS Python Scripting Library ===

See [http://grass.osgeo.org/programming7/pythonlib.html GRASS Python Scripting Library] (Programmer's manual). See also [[Converting Bash scripts to Python]], and [http://trac.osgeo.org/grass/browser/grass/trunk/scripts sample Python scripts in GRASS 7]

==== Uses for read, feed and pipe, start and exec commands ====

All of the *_command functions use make_command to construct a command
line for a program which uses the GRASS parser. Most of them then pass
that command line to ''subprocess.Popen()'' via ''start_command()'', except
for ''exec_command()'' which uses ''os.execvpe()''.

[To be precise, they use grass.Popen(), which just calls
subprocess.Popen() with shell=True on Windows and shell=False
otherwise. On Windows, you need to use shell=True to be able to
execute scripts (including batch files); shell=False only works with
binary executables.]

start_command() separates the arguments into those which
subprocess.Popen() understands and the rest. The rest are passed to
make_command() to construct a command line which is passed as the
"args" parameter to subprocess.Popen().

In other words, start_command() is a GRASS-oriented interface to
subprocess.Popen(). It should be suitable for any situation where you
would use subprocess.Popen() to execute a normal GRASS command (one
which uses the GRASS parser, which is almost all of them; the main
exception is r.mapcalc in 6.x).

Most of the others are convenience wrappers around start_command(), for common use cases.

* run_command() calls the wait() method on the process, so it doesn't return until the command has finished, and returns the command's exit code. Similar to system().

* pipe_command() calls start_command() with stdout=PIPE and returns the process object. You can use the process' .stdout member to read the command's stdout. Similar to popen(..., "r").

* feed_command() calls start_command() with stdin=PIPE and returns the process object. You can use the process' .stdin member to write to the command's stdout. Similar to popen(..., "w")

* read_command() calls pipe_command(), reads the data from the command's stdout, and returns it as a string. Similar to `backticks` in the shell.

* write_command() calls feed_command(), sends the string specified by the "stdin" argument to the command's stdin, waits for the command to finish and returns its exit code. Similar to "echo ... | command".

* parse_command() calls read_command() and parses its output as key-value pairs. Useful for obtaining information from g.region, g.proj, r.info, etc.

* exec_command() doesn't use start_command() but os.execvpe(). This causes the specified command to replace the current program (i.e. the Python script), so exec_command() never returns. Similar to bash's "exec" command. This can be useful if the script is a "wrapper" around a single command, where you construct the command line and execute the command as the final step.

If you have any other questions, you might want to look at the code ($GISBASE/etc/python/grass/script/core.py). Most of these functions are only a few lines long.

==== Interfacing with NumPy ====

The {{api|pythonlib.html#pythonArray|grass.script.array}} module defines a {{api|classpython_1_1array_1_1array.html|class array}} which is a subclass of [http://docs.scipy.org/doc/numpy/reference/generated/numpy.memmap.html numpy.memmap] with <code>.read()</code> and <code>.write()</code> methods to read/write the underlying file via {{cmd|r.out.bin}}/{{cmd|r.in.bin}}. Metadata can be read with {{api|namespacepython_1_1raster.html#a69e4a61eb59a31608410b733d174b8a7|raster::raster_info}}():

Example:

<source lang="python">
import grass.script as grass
import grass.script.array as garray

def main():
map = "elevation.dem"

# read map
a = garray.array()
a.read(map)

# get raster map info
print grass.raster_info(map)['datatype']
i = grass.raster_info(map)

# get computational region info
c = grass.region()
print "rows: %d" % c['rows']
print "cols: %d" % c['cols']

# new array for result
b = garray.array()
# calculate new map from input map and store as GRASS raster map
b[...] = (a / 50).astype(int) * 50
b.write("elev.50m")
</source>

The size of the array is taken from the current region ([[computational region]]).

The main drawback of using numpy is that you're limited by available
memory. Using a subclass of <code>numpy.memmap</code> lets you use files which may
be much larger, but processing the entire array in one go is likely to
produce in-memory results of a similar size.

==== Interfacing with NumPy and SciPy ====

[http://docs.scipy.org/doc/scipy/reference/index.html SciPy] offers simple access to complex calculations. Example:

<source lang="python">
from scipy import stats
import grass.script as grass
import grass.script.array as garray

def main():
map = "elevation.dem"

x = garray.array()
x.read(map)

# Descriptive Statistics:
print "max, min, mean, var:"
print x.max(), x.min(), x.mean(), x.var()
print "Skewness test: z-score and 2-sided p-value:"
print stats.skewtest(stats.skew(x))
</source>

==== Interfacing with NumPy, SciPy and Matlab ====

One may also use the SciPy - Matlab interface:

### SH: in GRASS ###
r.out.mat input=elevation output=elev.mat

<source lang="python">
### PY ###
import scipy.io as sio
# load data
elev = sio.loadmat('elev.mat')
# retrive the actual array. the data set contains also the spatial reference
elev.get('map_data')
data = elev.get('map_data')
# a first simple plot
import pylab
pylab.plot(data)
pylab.show()
# the contour plot
pylab.contour(data)
# obviously data needs to ne reversed
import numpy as np
data_rev = data[::-1]
pylab.contour(data_rev)
# => this is a quick plot. basemap mapping may provide a nicer map!
#######
</source>

=== Testing and installing Python extensions ===

==== Debugging ====

Make sure the script is executable:

chmod +x /path/to/my.extension.py

During development, a Python script can be debugged using the Python Debugger (pdb):

python -m pdb /path/to/my.extension.py input=my_input_layer output=my_output_layer option=value -f

==== Installation ====

Once you're happy with your script, you can put it in the scripts/ folder of your GRASS install. To do so, first create a directory named after your extension, then create a Makefile for it, and a HTML man page:

cd /path/to/grass_src/
cd scripts
ls # It is useful to check out the existing scripts and their structure
mkdir my.extension
cd my.extension
cp path/to/my.extension.py .
touch my.extension.html
touch Makefile

Next step is to edit the Makefile. It is a very simple text file, the only thing to check is to put the right extension name (WITHOUT the .py file extension) after PGM:

MODULE_TOPDIR = ../..

PGM = my.extension

include $(MODULE_TOPDIR)/include/Make/Script.make

default: script

The HTML file would be generated automatically. If you want to add more precisions in it, you can do it (just make sure you start at DESCRIPTION. See existing scripts.)

You can then run "make" within the my.extension folder. Running "make" in the extension directory places the resulting files in the staging directory (path/to/grass_src/dist.<YOUR_ARCH>/). If you're running GRASS from the staging directory (/path/to/grass_src/bin.<YOUR_ARCH>/grass7), subsequent commands will used the updated files.

# in your extension directory (/path/to/grass_src/scripts/my.extension/)
make
# Starting GRASS from the staging directory
/path/to/grass_src/bin.<YOUR_ARCH>/grass7
my.extension help

You can also run "make install" from the top level directory of your GRASS install (say /usr/local/src/grass_trunk/). Running "make install" from the top level just copies the whole of the dist.<YOUR_ARCH>/ directory to the installation directory (e.g. /usr/local/grass70) and the bin.<YOUR_ARCH>/grass70 bin file to the bin directory (e.g. /usr/local/bin), and fixes any embedded paths in scripts and configuration files.

cd /path/to/grass_src
make install
# Starting GRASS as usual would work and show your extension available
grass7
my.extension help

=== Python Ctypes Interface ===

This interface allows calling GRASS library functions from Python scripts. See [[Python Ctypes Examples]] for details.

Examples:

* GRASS 7: [http://trac.osgeo.org/grass/browser/grass/trunk/doc/python/raster_example_ctypes.py raster], [http://trac.osgeo.org/grass/browser/grass/trunk/doc/python/vector_example_ctypes.py vector] example

* Latest and greatest: [[http://trac.osgeo.org/grass/browser/grass/trunk/scripts GRASS 7 Python scripts]]

* [[PythonSwigExamples|More complicated examples]] <<-- TODO: update to Ctypes

Sample script for GRASS 6 raster access (use within GRASS, Spearfish session):
<source lang="python">
#!/usr/bin/env python

## TODO: update example to Ctypes

import os, sys
from grass.lib import grass

if "GISBASE" not in os.environ:
print "You must be in GRASS GIS to run this program."
sys.exit(1)

if len(sys.argv)==2:
input = sys.argv[1]
else:
input = raw_input("Raster Map Name? ")

# initialize
grass.G_gisinit('')

# find map in search path
mapset = grass.G_find_cell2(input, '')

# determine the inputmap type (CELL/FCELL/DCELL) */
data_type = grass.G_raster_map_type(input, mapset)

infd = grass.G_open_cell_old(input, mapset)
inrast = grass.G_allocate_raster_buf(data_type)

rown = 0
while True:
myrow = grass.G_get_raster_row(infd, inrast, rown, data_type)
print rown, myrow[0:10]
rown += 1
if rown == 476:
break

grass.G_close_cell(inrast)
grass.G_free(cell)
</source>

Sample script for vector access (use within GRASS, Spearfish session):

<source lang="python">
#!/usr/bin/python

# run within GRASS Spearfish session
# run this before starting python to append module search path:
# export PYTHONPATH=/usr/src/grass70/swig/python
# check with "import sys; sys.path"
# or:
# sys.path.append("/usr/src/grass70/swig/python")
# FIXME: install the grass bindings in $GISBASE/lib/ ?

import os, sys
from grass.lib import grass
from grass.lib import vector as grassvect

if "GISBASE" not in os.environ:
print "You must be in GRASS GIS to run this program."
sys.exit(1)

if len(sys.argv)==2:
input = sys.argv[1]
else:
input = raw_input("Vector Map Name? ")

# initialize
grass.G_gisinit('')

# find map in search path
mapset = grass.G_find_vector2(input,'')

# define map structure
map = grassvect.Map_info()

# define open level (level 2: topology)
grassvect.Vect_set_open_level (2)

# open existing map
grassvect.Vect_open_old(map, input, mapset)

# query
print 'Vect map: ', input
print 'Vect is 3D: ', grassvect.Vect_is_3d (map)
print 'Vect DB links: ', grassvect.Vect_get_num_dblinks(map)
print 'Map Scale: 1:', grassvect.Vect_get_scale(map)
print 'Number of areas:', grassvect.Vect_get_num_areas(map)

# close map
grassvect.Vect_close(map)
</source>

=== Python-GRASS add-ons ===

Stand-alone addons:

# Jáchym Čepický's G-ps.map, a GUI to typeset printable maps with ps.map (http://193.84.38.2/~jachym/index.py?cat=gpsmap)
# Jáchym Čepický's v.pydigit, a GUI to v.edit (http://les-ejk.cz/?cat=vpydigit)
# Jáchym Čepický's PyWPS, GRASS-Web Processing Service (http://pywps.wald.intevation.org)

=== Using GRASS gui.tcl in Python ===

Here is some example code to use the grass automatically generated guis in python code. This could (should) all be bundled up and abstracted away so that the implementation can be replaced later.

<source lang="python">
import Tkinter
import os

# Startup (once):

tk = Tkinter.Tk()
tk.eval ("wm withdraw .")
tk.eval ("source $env(GISBASE)/etc/gui.tcl")
# Here you could do various things to change what the gui does
# See gui.tcl and README.GUI

# Make a gui (per dialog)
# This sets up a window for the command.
# This can be different to integrate with tkinter:
tk.eval ('set path ".dialog$dlg"')
tk.eval ('toplevel .dialog$dlg')
# Load the code for this command:
fd = os.popen ("d.vect --tcltk")
gui = fd.read()
# Run it
tk.eval(gui)
dlg = tk.eval('set dlg') # This is used later to get and set

# Get the current command in the gui we just made:
currentcommand = tk.eval ("dialog_get_command " + dlg)

# Set the command in the dialog we just made:
tk.eval ("dialog_set_command " + dlg + " {d.vect map=roads}")
</source>

== FAQ ==

* '''Q:''' Error message "execl() failed: Permission denied" - what to do?
: '''A:''' Be sure that the execute bit of the script is set.

== Links ==

=== General guides ===

* [http://en.wikibooks.org/wiki/Python_Programming/ Wikibook Python Programming]
* [http://www.poromenos.org/tutorials/python Quick Python tutorial] for programmers of other languages
*: [http://wiki.python.org/moin/BeginnersGuide/Programmers More Python tutorials] for programmers
* [http://www.python.org/dev/peps/pep-0008/ Python programming style guide]
* [http://wiki.python.org/moin/PythonEditors Python Editors]

=== Programming ===

* Python and GRASS:
** GRASS Python interface to library functions: http://download.osgeo.org/grass/grass6_progman/swig/ based on SWIG http://www.swig.org/
** GRASS Python scripting library: http://download.osgeo.org/grass/grass6_progman/pythonlib.html
** PyWPS, GRASS-Web Processing Service http://pywps.wald.intevation.org

* Python and OSGeo:
** [http://wiki.osgeo.org/wiki/OSGeo_Python_Library OSGeo Python Library]

* Python and GDAL/OGR:
** [http://mapserver.gis.umn.edu/community/conferences/MUM3/workshop/python Open Source Python GIS Hacks Mum'03]
** http://hobu.biz/software/OSGIS_Hacks - Python OSGIS Hacks '05
** http://zcologia.com/news/categorylist_html?cat_id=8
** http://www.perrygeo.net/wordpress/?p=4

* Python bindings to PROJ:
** http://www.cdc.noaa.gov/people/jeffrey.s.whitaker/python/pyproj.html

* Python and GIS:
** [http://gispython.org/ Open Source GIS-Python Laboratory]

* Python and Statistics:
** [http://rpy.sourceforge.net/ RPy] - Python interface to the R-statistics programming language

* Bindings:
** SIP (C/C++ bindings generator) http://directory.fsf.org/all/Python-SIP.html
** [http://www.cython.org/ Cython] - C-Extensions for Python (compile where speed is needed)

* Other external projects
** [http://www.scipy.org Scientific Python]
** [http://wiki.python.org/moin/NumericAndScientific Numeric and Scientific]
** [http://w3.pppl.gov/~hammett/comp/python/python.html Info on Python for Scientific Applications]

=== Presentations ===

From FOSS4G2006:
* [http://www.foss4g2006.org/materialDisplay.py?contribId=136&sessionId=48&materialId=slides&confId=1 A Python sweeps in the GRASS] - A. Frigeri 2006
* [http://www.foss4g2006.org/materialDisplay.py?contribId=67&sessionId=48&materialId=slides&confId=1 GRASS goes web: PyWPS] - J. Cepicky 2006 (see also [[WPS]])

{{Python}}

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

GRASS and MapServer

2011-12-30T20:51:26Z

⚠️Reverse22:

==GRASS maps from mapfiles==

MapServer needs a mapfile containing the information, how to create the maps. Examples of these can be found, so here you'll find GRASS specific information.

==Raster Maps==

A short example of a layer definition to access a GRASS raster:

<pre>
LAYER
NAME "Example"
TYPE RASTER
STATUS ON
DATA "/path/to/grassdb/location/mapset/cellhd/example"
CLASS NAME "Example" # You need to have a class definition in the layer
END
END
</pre>

Notes:

* The rasters are limited to values from 0 to 255, the values over this are interpreted as 255. Rescale (<code>r.rescale</code>) your maps when necessary.
* You really need to have a CLASS in your layer, otherwise no data will be shown. An empty class is quite fine to show the whole map.

==Vector Maps==

A short example of a layer definition to access a GRASS vector:

<pre>
LAYER
NAME "Example"
TYPE LINE
STATUS ON
CONNECTIONTYPE OGR
CONNECTION "/path/to/grassdb/mapset/location/vector/example/head"
DATA "1" # Layer number
CLASS # You need to have a class definition; otherwise nothing is shown on the map
NAME "Example"
COLOR 155 155 0
END
END
</pre>

Notes:

* You need to have GDAL with OGR and GRASS support for this to work. Note, that in this [http://grass.itc.it/start.html example] the maps are first exported to shapefiles. This is no longer necessary, as the maps can be accessed directly with OGR.
* Usually GRASS layers have no names and the layer number is used in DATA. However, it is possible that they do have names. This can happen for example when importing files with v.in.dxf, as the module keeps the dxf-file layer names and stores them into the GRASS vector. The layer names, if such there are, can be found in <tt>/path/to/grassdb/mapset/location/vector/vectorname/dbln</tt>, or with <code>ogrinfo -ro /path/to/grassdb/mapset/location/vector/vectorname/dbln</code>. Why this is so important is because if there are layer names defined, these layers cannot be accessed through the layer number with OGR. They ''have'' to be accessed through the layer name.

==Examples and useful links==

* [http://grass.itc.it/start.html Example] of GRASS with MapServer.
* [http://mapserver.gis.umn.edu UMN Mapserver homepage]

[[Category:Documentation]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

GRASS and Java

2011-12-30T20:51:16Z

⚠️Reverse22:

=== vtk-grass-bridge with JAVA bindings ===

The vtk-grass-bridge main page
http://code.google.com/p/vtk-grass-bridge/

Short introduction how to compile the vtk-grass-bridge:
http://code.google.com/p/vtk-grass-bridge/wiki/HowToCompile

==== Examples ====
The Java module v_sample_rast:
http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Modules/Java/v_sample_rast.java

=== Calling GRASS from JAVA ===

Define:
<source lang="java">
public String run(String[] cmd) {
...
Process p1=rt.exec(cmd, env);
</source>

and use:
<source lang="java">
gm.run({"r.info", "map=roads"});
</source>

==== Examples ====

===== Installation =====
It seems that calling grass in JAVA by using <tt>java.Lang.Runtime.exec()</tt> can be implemented easily in Linux platform (tested successfully on Ubuntu 9.10).

First install the grass use the apt-get:

sudo apt-get install grass # it will install the latest stable version

After the installation completed you can:

#Test it in the terminal without JAVA (make sure that you have a GRASS database installed):

Open a terminal and enter:

grass64

The following the instruction in the screen or check [http://trac.osgeo.org/grass/wiki/HowToTestGrass6 here].

===== Test the environment settings =====

Test using GRASS command directly in the terminal:

Set the environment (we assume GRASS being installed under /usr/lib/grass64):

<source lang="bash">
export GISBASE=/usr/lib/grass64
export GISRC=/home/kk/gisrc
export LD_LIBRARY_PATH=$GISBASE/lib
export PATH=$PATH:$GISBASE/bin:$GISBASE/scripts
</source>

Then try some GRASS command directly, for example:
<source lang="bash">
g.version
g.gisenv
...
</source>

Now call GRASS in JAVA if the above test 2 passed.

Just use the <tt>Runtime.getRuntime.exec(String cmd,String[] env)</tt>:
<source lang="java">
String cmd="g.version";

String[] exe = { "bash", "-c", cmd };
String[] env={"GISBASE=..","GISRC="".......}; // the environment variables which you set in the step 2.
p=Runtime.getRuntime.exec(exe,env);
</source>

[[Category:Development]]
[[Category:Linking to other languages]]
[[Category:Java]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

GRASS 7 Terminology

2011-12-30T20:51:06Z

⚠️Reverse22:

This page is dedicated to discussion about changes in terminology for GRASS 7.

== Map ==

Currently data entities like rasters or vectors are called in GRASS "maps", i.e. "raster map" or "vector map".

* [[User:Landa|ML]]: GRASS is basically '''"layer-based"''' GIS, calling single raster or vector entities as "maps" is quite confusing. Better would be to use term "layer" or "map layer" for this purpose. "Map" can be used for layer composition, e.g. for cartography outputs.

;Proposal(s)

* map layer
** raster layer
** 3D raster layer
** vector layer

== Vector layer ==

The term "vector layer" is currently used even in more confusing sense, to mark subgroup of vector objects in vector entity. Originally called as "field".

* [[User:Landa|ML]]: Not sure if to go back to the original term "field" (DB-based) or use something like "sub-layer".
* WB: How about calling it "attribute-layer" which connects to an "attribute-table" (DB table)?
* Moritz: I think the original motivation of layers was not necessarily DB-based, but rather to make it possible to have different types of features in one file. For example, you could have a file with fields and roads together, where the boundary of a field is a road. So in layer 1 (the fields) this line would not have a category value, but in layer 2 (the roads) it would. The fact that you can (but do not have to) then link each of these layers to different tables is just part of the story.
: Hamish: I'm pretty sure Radim meant for fields/layers to be a DB link from the start.

;Proposal(s)

* '''field number'''
** +0 (Hamish). The only thing I see against going back to this is that it can be confusing for non-native English speakers who only are familiar with the primary definition and not the intended & more abstract secondary meaning.
* '''key'''
** +1 ([[User:cmbarton|Michael]]). This is the proper term in database terminology. A vector must have at least one set of keys (= 1 or more layers). These are currently called "CAT" for category. The history of this is that it parallels the "category" of a raster cell. Back in GRASS 5 and below, vectors were not regularly linked to external tables (although it was possible to link up a PostgreSQL table) and each vector object had an integer identifier (i.e., a category) and a label, just like a raster. However, since Radim rewrote the vector architecture for GRASS 5.7 (6.0 beta) and above, it is used quite differently, as the key field to link vector objects to lines in an attribute data table. This is pretty standard relational database structure. A linked table is not mandatory, but AFAIK, at least 1 "layer" of "cat" values (i.e., key field values) is required for any vector file. So, I suggest that we don't make up a special GRASS term for a key field but just use the term key (or keyfield). Any set of vector objects in a file can have 1 or more key fields. This identifies each vector object with 1 or more keys, and has the potential to link each object to a line in an attribute data table that has a matching key. In GRASS, keys do not have to be unique; this does not keep them from being keys, but is simply a characteristic of GRASS key fields.
** +1 ([[User:micha|Micha]]). Despite the widespread use of "cat" and "category" in GRASS, it seems clearer to me to have a totally different term for database links. In a vector context, "category" or "category sets" reminds me of thematic maps, which is not what we want. Other GIS use field names like "fid" "gid" etc. "key" or "keyfield" makes perfect sense to me.
** -0 (Hamish). I've got nothing against ''key'' per se, but to someone not familar with common DB jargon like myself, there is little intuitive connection between the key to a lock and a link to a vector+DB grouping -- ''unless you are dealing with a DB which requires a username:password in which case it makes clear sense''. But many/most users will not be using Postgre/MySQL/Oracle out of the box and those who do are probably advanced enough to figure out whatever name we use pretty quickly. Note name-space collision with "key column", which may rule this one out.
* '''keyfield'''
** -1 (Hamish). Redundant; too wordy; too "wtf?".
* '''table link'''
** -1 (Hamish). I don't like "table link" as it is too wordy, but I do really like '''link''' on its own.
* '''link'''
** +1 (Hamish) IMHO this describes both the idea and actual mechanics of it rather well.
* '''category set'''
** +1 ([[User:Landa|ML]])
** +1 - in light of my above remark this seems to be the most general term (Moritz)
** -1 (Hamish). Too wordy; too close to "category" so would be confusing and in practice would get shortened to "set" which could possibly be confusing to MSWindows .bat users and csh dinosaurs; too "wtf?". "''Set the category to what? Have you set the category or not?''"

== See also ==

* http://lists.osgeo.org/pipermail/grass-dev/2008-August/039277.html
* [http://grass.osgeo.org/gdp/html_grass5/terminology.html GRASS 5 terminology]
* [[GRASS 6 Terminology]]
* [http://www.nabble.com/terminology-fixes-in-GRASS-td7856076.html#a7856076 GRASS 6 terminology fixes]
* The terminology is related to '''flags and parameters standardization'''. See [http://trac.osgeo.org/grass/browser/grass/trunk/doc/parms_flags.txt proposal(s)].
* [http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures#Renamedoptions GRASS 6 -> 7 renamed parameter options]
* [http://trac.osgeo.org/grass/wiki/MessageStandardization GRASS Message Standardization]
* [http://www.opengeospatial.org/standards OGC standards]
* [http://www.lib.unc.edu/reference/gis/datafinder/glossary.html GIS DataFinder]
* [http://www.opengeospatial.org/ogc/glossary/ OGC Glossary of Terms]
* [http://support.esri.com/index.cfm?fa=knowledgebase.gisDictionary.gateway ESRI GIS Dictionary]

[[Category: Development]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

GRASS 6 Tutorial

2011-12-30T20:50:53Z

⚠️Reverse22:

The Free Software/Open Source GIS GRASS 6 is fully operational and stable version for production use. This tutorial tries to
give you a hand to familiarize yourself with the improved functionality, especially in the vector engine and attribute management.
For further reading, see the references below.

'''Disclaimer:''' In case the examples described here do not work properly, you are kindly invited to send us further examples and/or code bugfixes/enhancements. Enjoy the WIKI!

This tutorial is intended for GRASS users who want to migrate from a previous release to the new GRASS Version. If you are a beginner, please also consider additional [http://grass.itc.it/gdp/tutorials.php books or tutorials].

'''''NOTE: This tutorial here still awaits the merge of the [http://grass.osgeo.org/grass57/tutorial/ previous GRASS 5.7 tutorial].'''''

==Introduction==

New GRASS development has made major improvements to the vector
architecture. The most significant change includes a new 2- and
3-dimensional vector library that manages vector attributes in
standard database management systems (DBMS). This system provides the
power of true relational databases for vector attribute management
while preserving the flexibility of traditional GRASS topological
tools. GRASS now also incorporates true 3-dimensional voxels in the
[http://grass.itc.it/gdp/nviz/index.html NVIZ] visualization environment as well as [http://grass.itc.it/grass60/index.php numerous enhancements] to
virtually every tool in the GRASS library.

==Getting started in general==

* [[GRASS_Help| Introductory Material]] for GRASS
* [http://www.linux.org/lessons/ Introductory Material] for Linux

==Getting started - how to migrate to the new GRASS version==

* [[Grass Six Tutorial Getting Started]]
* [[GRASS_Help#Migration_from_other_GIS_Software|Migration tips]] from other GIS softwares

==Raster data management==

* The raster management works as it did in previous GRASS versions.
: Tutorials and books written for GRASS 4 and 5 should for the most part still work.
* [http://grass.ibiblio.org/grass63/manuals/html63_user/rasterintro.html Raster data processing introduction] from the main help manual.

==Vector data management==

* [http://grass.ibiblio.org/grass63/manuals/html63_user/vectorintro.html Vector data processing introduction] from the main help manual.

===[[Grass Six Tutorial Default Settings]]===
- Default settings for vector geometry;
for vector attributes; for db.* modules

===[[Grass Six Tutorial Geometry Management]]===
http://grass.osgeo.org/grass57/tutorial/geom_storage.html
- General notes on Geometry
management; Managing the default settings;
GRASS vector architecture; Geometry stored in native format;
Geometry stored in SHAPE file;
Import/export of vector data Geometry;
Generating vector geometry from various sources

===[[Grass Six Tutorial Attribute Management]]===
http://grass.osgeo.org/grass57/tutorial/attrib_storage.html
- General notes on Attribute
management; Managing the default settings; Examples;
Database Schema

==Usage examples==

''There await porting from the GRASS 5.7 tutorial''

===Basic usage examples===
http://grass.osgeo.org/grass57/tutorial/ex_basic.html

===Complex usage examples===
http://grass.osgeo.org/grass57/tutorial/ex_complex.html

===Vector network analysis examples===

* New Spearfish examples: [http://grass.osgeo.org/grass63/manuals/html63_user/v.net.html v.net], [http://grass.osgeo.org/grass63/manuals/html63_user/v.net.iso.html v.net.iso], [http://grass.osgeo.org/grass63/manuals/html63_user/v.net.path.html v.net.path] etc.
* Old tutorial: http://grass.osgeo.org/grass57/tutorial/network.html

===Vector overlay/clipping examples===
http://grass.osgeo.org/grass57/tutorial/vectoroverlay.html

===Examples from US National Atlas===
http://grass.osgeo.org/grass57/tutorial/usa_demo.html

===FAQ (Frequently Asked Questions)===
* [[Faq|GRASS Wiki FAQ]]

* [[Grass Six Tutorial Faq]]

==Troubleshooting==
http://grass.osgeo.org/grass57/tutorial/troubleshooting.html

* Grass Six Tutorial Troubleshooting

==Links of interest==

* GRASS-GMT Examples: http://169.237.35.250/~dylan/grass_user_group/

==Further reading==

===GRASS and R kriging interpolation===

====Mini How to interpolate using kriging with GRASS and R====

[[How to interpolate point value using kriging method with R and GRASS 6]]

==== References ====
* GRASS [http://grass.osgeo.org/gdp/tutorials.php books and tutorials]
* GRASS 6 Tutorial: http://www.gdf-hannover.de/literature
* Translation Portal for GRASS 6 Tutorial http://www.gdf-hannover.de/translation

[[Category: Documentation]]
[[Category: Tutorial]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

GRASS 6 Terminology

2011-12-30T20:50:39Z

⚠️Reverse22:

== General ==

* '''LOCATION''': This is the name of an available geographic location. It contains a series of MAPSETS which share a common map projection.
: Typically its name will be based on the larger job/project you are working on, a reflection of the map projection which it will use, or a combination of both of these. For example: "''The_Rockies''", "''UTM18_nad27''", "''LL_wgs84''", "''Spearfish60''", "''simple_xy''".

* '''MAPSET''': Every GRASS session runs under the name of a MAPSET. A MAPSET may be a geographical subset or as large as the parent LOCATION. Technically they are subdirectories under any location. In a networked environment with several users working within the same location, mapsets play a special role. Users may only select (and thus modify) a mapset that they own (i.e., have created). However, data in all mapsets for a given location can be read by anyone (unless prevented by UNIX file permissions). The "PERMANENT" mapset usually contains the read-only base maps like the elevation model, while the other locations are readable and writable by their owners. The "PERMANENT" mapset also contains some information about the location itself that is not found in the mapsets (projection info etc.), thus it must exist in every location.
: The MAPSETS might be named for their owner (on a networked multi-user system) (''e.g. user1''), a specific area or study site within the greater region (''e.g. Wade_County''), all maps concerning a specific field study (''e.g. Jan2008''), or whatever is useful to organize your data.

* '''DATABASE''': This is the unix directory containing the geographic LOCATIONS (also called GIS'''D'''BASE). For a desktop GIS user typically this will be a subdirectory called <tt>grassdata</tt> in your home directory.

[[File:Loc_struct.png|center|thumb|600px|Structure of the GRASS data hierarchy]]

* '''REGION''': The REGION may be the entire area or subset of the chosen LOCATION. It is defined by northern, southern, eastern, and western bounds, as well as the raster grid resolution. It is controlled by the {{cmd|g.region}} module and is of primary importance for raster operations. Its most obvious effect is of setting the map zoom, but it is much more than that.

* '''WINDOW''': see REGION



== Raster maps ==

* '''CELL DATA TYPE''': a raster map from INTEGER type (whole numbers only)

* '''FCELL DATA TYPE''': a raster map from FLOAT type (4 bytes, 6 digits precision)

* '''DCELL DATA TYPE''': a raster map from DOUBLE type (8 bytes, 15 digits precision)

* '''NULL''': represents "no data" in raster maps, to be distinguished from 0 (zero) data value

* '''INTEGER MAP''': see CELL DATA TYPE

* '''FLOAT MAP''': see FCELL DATA TYPE

* '''DOUBLE MAP''': see DCELL DATA TYPE

== Raster 3D maps ==

* '''VOXEL''': A 3-dimensional grid cell. (An individual cube in a greater 3D region block)

== Vector maps ==

* '''CATEGORY NUMBER''': A numerical value for a map feature (e.g. road number). The CATEGORY NUMBER is related to the attribute database. The internal vector feature ID is different from this.

* '''LAYER''': A single vector map can be connected to multiple database tables. This number determines which table to use.

* '''DRIVER''': The database backend. e.g. dbf, sqlite, pg, mysql

* '''TABLE''': The attribute table(s) associated with a map.

* '''DATABASE''': The path or connection to the backend database storage.

* '''KEY COLUMN''': The attribute column that relates the spatial data to the attribute database data. Typically the <tt>cat</tt> column is used as the key column.

* '''SQL''': The Structured Query Language. A standardized method of accessing and manipulating databases. Almost all modern databases speak some dialect of this common language.

== Map Projections ==

''See the [[GIS Concepts]] wiki page for details.


see the [[GRASS 7 Terminology]] page for more discussion.

[[Category: Documentation]]
[[Category: FAQ]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

Global datasets

2011-12-30T20:50:28Z

⚠️Reverse22:

= Raster data =

== Elevation data ==

=== ASTER topography (GDEM V1) ===

Improved ASTER GDEM 1 from 2009:

GDEM global 30m elevation calculated from stereo-pair images collected by the Terra satellite.
''"This is the most complete, consistent global digital elevation data yet made available to the world."''
This is a very new dataset, at version 1 (treat as ''experimental''). Accuracy will be improved in forthcoming versions (validation with SRTM, etc.; [http://gfoss.blogspot.com/2009/08/aster-gdem-30m-quality-assessment.html see assessment here] and [http://www.viewfinderpanoramas.org/reviews.html#aster here]).

* ''[https://lpdaac.usgs.gov/lpdaac/about/news_archive/monday_june_22_20092 pre-release announcement]''
* [http://www.nasa.gov/home/hqnews/2009/jun/HQ_09-150_ASTER_Topographic_Map.html NASA press release]
* [https://wist.echo.nasa.gov/~wist/api/imswelcome/ Warehouse Inventory Search Tool] or [http://www.gdem.aster.ersdac.or.jp/search.jsp Easy search tool] (Data download)

'''Tutorial:''' [http://grass.osgeo.org/wiki/ASTER_topography ASTER topography].
* To order and download data: http://digitalelevation.blogspot.com/2009/07/aster-gdem-download-tutorial.html

=== ASTER topography (GDEM V2) ===

Improved ASTER GDEM 2 from 2011:
* https://lpdaac.usgs.gov/products/aster_products_table/routine/aster_global_digital_elevation_model/v2/astgtm

'''Notes:''' this DEM can be rather well filtered and smoothed with the [http://personalpages.manchester.ac.uk/staff/neil.mitchell/mdenoise/ Sun's denoising algorithm] (using GDAL and free / open source program <mdenoise> or simply GRASS add-on {{AddonCmd|r.denoise}}.

Experiments showed that the best smoothing of ASTER GDEM 2 is reached with such parameters of <mdenoise>:
* threshold = 0.8
* iterations = 10-20

Also filtering with {{cmd|r.neighbors}} by "average" method and window size >=5 is quite useful to remove some noise from DEM.

''See also: [http://gfoss.blogspot.com/2009/08/aster-gdem-30m-quality-assessment.html ASTER GDEM 30m quality assessment]''

=== ACE2 ===

The ACE2 Global Digital Elevation Model is available at 3", 30" and 5' spatial resolutions.

* http://tethys.eaprs.cse.dmu.ac.uk/ACE2/

Import example:
r.in.bin -f input="00N105E_3S.ACE2" output="ACE2_00N105E" bytes=4 \
order="native" north=15 south=0 east=120 west=105 \
rows=18000 cols=18000

=== ETOPO (DEM) ===

The ETOPO datasets provide global topography and bathymetry at 1', 2', and 5' per-cell resolutions.

==== ETOPO1 (DEM) ====

* http://www.ngdc.noaa.gov/mgg/global/

'''The ''cell registered'' version can be loaded directly into a lat/lon region'''. GRASS raster data is cell registered (see
the [[GRASS raster semantics]] page)

The ''grid registered'' version must be loaded into a simple XY location using the parameters found in the .hdr file, and needs to have the 90deg N,S rows cropped away:

# grid registered version only: create a new simple XY location and mapset

# Import grid registered binary float
r.in.bin -f in=etopo1_bed_g.flt out=etopo1_bed_g \
n=90.008333333335 s=-90.008333333335 e=180.00833333334 \
w=-180.00833333334 rows=10801 cols=21601 anull=-9999
r.colors out=etopo1_bed_g color=etopo2

# reduce region by 1 cell
g.region rast=etopo1_bed_g
eval `g.region -g`
g.region n=n-$nsres s=s+$nsres e=e-$ewres -p

# save smaller raster and remove original
r.mapcalc "etopo1_bed_g.crop = etopo1_bed_g"
g.remove etopo1_bed_g

# change the location to lat/lon by restarting GRASS
# in the PERMANENT mapset and running {{cmd|g.setproj}}
# or move the entire mapset into a lat/lon location
# and manually edit the $MAPSET/cellhd/ files (dirty!)

==== ETOPO2 (DEM) ====

* See the ETOPO2 (2' global) article by M.H. Bowman in the [http://grass.osgeo.org/newsletter/GRASSNews_vol1.pdf GRASS Newsletter, 1:8-11, August 2004].
: [http://www.ngdc.noaa.gov/mgg/fliers/01mgg04.html ETOPO2v2 data download] (take for example the ETOPO2v2g_f4_LSB.flt file)

=== GTOPO30 (DEM) ===

* Data [http://eros.usgs.gov/#/Find_Data/Products_and_Data_Available/gtopo30_info download] - Import with {{cmd|r.in.gdal}}.

''Note:'' To avoid that the GTOPO30 data are read incorrectly, you can add a new line "PIXELTYPE SIGNEDINT" in the .HDR to force interpretation of the file as signed rather than unsigned integers. Then the .DEM file can be imported. Finally, e.g. the 'terrain' color table can be assigned to the imported map with r.colors.

=== Global Multi-resolution Terrain Elevation Data 2010 (GMTED2010) ===

* Data [http://eros.usgs.gov/#/Find_Data/Products_and_Data_Available/GMTED2010 download] - Import with {{cmd|r.in.gdal}}.

Import of GMTED2010 tiles in GRASS GIS:

r.in.gdal 30N000E_20101117_gmted_mea075.tif out=gmted2010_30N000E_20101117
r.colors gmted2010_30N000E_20101117 color=elevation
g.region rast=gmted2010_30N000E_20101117
r.shaded.relief gmted2010_30N000E_20101117 units=meters
d.mon x0
d.rast gmted2010_30N000E_20101117.shade
d.grid 1 color=red textcolor=red

[[Image:Gmted2010_30N000E_20101117_shaded.png|thumb|center|300px|GMTED2010 example: Trento - Garda Lake - Verona area (Northern Italy)]]

=== CleanTOPO2 (DEM) ===

* [http://www.shadedrelief.com/cleantopo2/ CleanTOPO2 download]: Edited SRTM30 Plus World Elevation Data

Import in GRASS:
r.in.gdal CleanTOPO2.tif out=cleanTOPO2.tmp -l -o
g.region rast=cleanTOPO2 -p -g
# rescale from odd integer values to true world values
r.rescale cleanTOPO2.tmp out=cleanTOPO2 to=-10701,8248
r.colors cleanTOPO2_final col=terrain

[[Image:CleanTOPO2_map.png|thumb|center|300px|Rescaled ClearTOPO2 map]]

=== GEBCO Bathymetric Chart ===

* The General Bathymetric Chart of the Oceans (original 1' release 2003, new 1' and 30" releases 2008)
: http://www.gebco.net/data_and_products/gridded_bathymetry_data/
: http://www.bodc.ac.uk/data/online_delivery/gebco/

{{cmd|r.in.gdal}} can be used to import the GMT netCDF files directly, or if that doesn't work you can use GMT tools to convert to an old-style native GMT format and import that with {{cmd|r.in.bin}}.
: example: (GEBCO 2003 1' data)

# convert to an old style GMT binary .grd using grdreformat
$ grdreformat 3n24s47w14w.grd 3n24s47w14w_Native.grd=bs

# then import into GRASS,
GRASS> r.in.bin -h -s bytes=2 in=3n24s47w14w_Native.grd out=3n24s47w14w

# and set some nice colors
GRASS> r.colors 3n24s47w14w rules=- << EOF
nv magenta
0% black
-7740 0:0:168
0 84:176:248
0 40:124:0
522 68:148:24
1407 148:228:108
1929 232:228:108
2028 232:228:92
2550 228:160:32
2724 216:116:8
2730 grey
2754 grey
2760 252:252:252
2874 252:252:252
2883 192:192:192
2913 192:192:192
100% 252:252:252
EOF

=== Global Multi-Resolution Topography (GMRT DEM) ===

* Global ~1 arc-second (~90 m) topography using multi-beam and satellite data in the oceans combined with SRTM on land.
* Full information at: http://www.marine-geo.org/portals/gmrt/
* Accessible via [http://www.geomapapp.org/ GeoMapApp] or [http://www.virtualocean.org/ Virtual Ocean] software.
* Very convenient to download into GRASS via wget:

export `g.region -g`
wget "http://www.marine-geo.org/cgi-bin/getgridB?west=${w}&east=${e}&south=${s}&north=${n}&resolution=1" -O /tmp/test.grd
r.in.gdal /tmp/test.grd output=GMRT -o
rm /tmp/test.grd

* Note: Downloaded file contains no projection information, but is EPSG:4326 (WGS84 Geographic). The file size is limited, but lower resolution (resolution=2,4,8) data can be downloaded for larger areas.

=== Smith and Sandwell DEM ===

* Merge info here from the [[Marine Science]] wiki page

=== SRTM DEM ===

[http://www2.jpl.nasa.gov/srtm/ Space Shuttle Radar Topography Mission]
* see [[HOWTO import SRTM elevation data]]

=== SRTM30plus data DEM ===

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.

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
: GRASS Users Mailing List http://lists.osgeo.org/pipermail/grass-user/2005-August/030063.html
; Getting as SRTM30plus tiles: ftp://topex.ucsd.edu/pub/srtm30_plus/srtm30/data/
; Getting as SRTM30plus huge file: ftp://topex.ucsd.edu/pub/srtm30_plus/topo30/

=== EGM2008 Geoid Data (Earth Gravitational Model) ===

Global 2.5 Minute Geoid Undulations:
* download GIS Format at http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/egm08_gis.html

[[Image:Trentino_egm2008_map_5m_resampled.jpg|thumb|center|300px|Geoid undulations in Trentino, Italy]]

Verifications of points can be done with the http://geographiclib.sourceforge.net/cgi-bin/GeoidEval

== Imagery ==

=== AVHRR ===

* see the [[AVHRR]] wiki page

=== Blue Marble imagery ===

NASA's Blue Marble is a 500m-8 degree per-cell world wide visual image of the Earth from space, with the clouds removed.

* see the [[Blue Marble]] wiki page

=== Natural Earth imagery ===

* [http://www.naturalearthdata.com/ Natural Earth II]: World environment map in natural color. GeoTIFF (use the {{cmd|r.in.gdal}} module)
* see also 1:10 million, 1:50 million and 1:110million scale maps from http://www.naturalearthdata.com/

=== Orthoimagery ===

* [http://worldwindcentral.com/wiki/Sources_of_free_orthoimagery Sources of free orthoimagery]

=== True Marble imagery ===

* [http://www.unearthedoutdoors.net/global_data/true_marble/download True Marble]: 250m world wide visual image of the Earth from space, with the clouds removed. GeoTIFF (use the {{cmd|r.in.gdal}} module)

=== EO-1 imagery ===

(Earth Observing-1)
* "''Advanced Land Imager (ALI) provides image data from ten spectral bands (band designations). The instrument operates in a pushbroom fashion, with a spatial resolution of 30 meters for the multispectral bands and 10 meters for the panchromatic band.''"
:-- http://eros.usgs.gov/products/satellite/eo1.php
* On-board Atmospheric Corrections

=== Miscellaneous ===

==== Data sources ====

* Some datasource links: http://www.ruf.rice.edu/~ben/gmt.html
* [http://www.geotorrent.org/browse.php Geotorrent.org]

==== Import Modules ====
* The {{cmd|r.in.gdal}} modules may be used to import data of [http://www.gdal.org/formats_list.html many formats], including GMT netCDF
* The {{cmd|r.in.bin}} module may be used to import raw binary files

=== LANDSAT imagery ===

Since October 1, 2008 all Landsat 7 ETM+ scenes held in the [http://landsat.usgs.gov/ USGS EROS archive] are available for download at no charge.
* Download via the [http://glovis.usgs.gov/ Glovis] online search tool (req. Java)
* Download via the USGS's [http://edcsns17.cr.usgs.gov/EarthExplorer/ EarthExplorer] interface

==== Import Modules ====

* {{cmd|r.in.gdal}} - Main import tool for complete multiband scenes
* {{cmd|r.in.wms}} - Download data covering current map region via WMS server
* [[GRASS_AddOns#r.in.onearth|r.in.onearth]] - WMS frontend for NASA's OnEarth Global Landsat Mosaic
* {{cmd|i.landsat.rgb}} - Color balancing/enhancement tool

==== See also ====

* Processing tips can be found on the [[LANDSAT]] wiki page

=== MODIS imagery ===

* see the [[MODIS]] wiki page

=== Pathfinder AVHRR SST imagery ===

* see the Pathfinder [[AVHRR]] SST wiki page

=== QuickBird imagery ===

* See the [[QuickBird]] wiki page

=== SeaWiFS imagery ===

* see the [[SeaWiFS]] wiki page

=== SPOT Vegetation imagery ===

SPOT Vegetation (1km) global: NDVI data sets

* [http://free.vgt.vito.be/ SPOT Vegetation (1km, global) NDVI data set server]
* for import, see {{cmd|i.in.spotvgt}}

== Climatic data ==

=== WorldClim maps ===

[http://www.worldclim.org/ WorldClim] is a set of global climate layers (climate grids) with a spatial resolution of a square kilometer.
* Load into a Lat/Lon WGS84 location (EPSG:4326)
* Import with {{cmd|r.in.bin}} or {{cmd|r.in.gdal}}
* {{cmd|r.in.gdal}} will read .BIL format, see the {{cmd|r.in.srtm}} shell script for hints
* binary format is 2 byte integer. Multiply by 10 using {{cmd|r.mapcalc}} to convert units. See http://www.worldclim.org/format.htm for more information and the [[MODIS]] help page for example of converting raw to data units.

=== OGC WCS - Albedo example ===

GRASS imports OGC Web Coverage Service data. Example server (please suggest a better one!)
<WCS_GDAL>
<ServiceURL>http://laits.gmu.edu/cgi-bin/NWGISS/NWGISS?</ServiceURL>
<CoverageName>AUTUMN.hdf</CoverageName>
<Timeout>90</Timeout>
<Resample>nearest</Resample>
</WCS_GDAL>

Save this as albedo.xml. Import into a LatLong WGS84 location:
r.in.gdal albedo.xml out=albedo

Unfortunately this server sends out the map shifted by 0.5 pixel. This requires a fix to the map boundary coordinates:
r.region albedo n=90 s=-90 w=-180 e=180

Now apply color table and look at the map:
r.colors albedo color=byr
d.mon x0
d.rast albedo

=== SNODAS maps ===

[http://nsidc.org/data/docs/noaa/g02158_snodas_snow_cover_model/index.html Snow Data Assimilation System] data that support hydrological modeling and analysis. First download the data, and untar them (once for each month, and once for each day), and you should get pairs of “.dat” and “.Hdr” files. The data files are stored in flat 16-bit binary format, so assuming that “snowdas_in.dat” is the name of the input file, at the GRASS prompt:

r.in.bin -bs bytes=2 rows=3351 cols=6935 north=52.874583333332339 \
south=24.949583333333454 east=-66.942083333334011 west=-124.733749999998366 \
anull=-9999 input=snowdas_input.dat output=snowdas

== Population maps ==

=== Gridded Population of the World ===

* http://sedac.ciesin.columbia.edu/gpw/global.jsp

Import with {{cmd|r.in.gdal}}, assign population color table with {{cmd|r.colors}}

== Topographic maps ==
=== Soviet topographic maps ===

* [http://en.poehali.org/maps Soviet topographic maps] as geocoded GeoTIFFs

== Vector data ==

=== CDC Geographic Boundary and Public Health Maps ===

* http://www.cdc.gov/epiinfo/maps.htm

=== Global Administrative Areas ===

* GADM is a database of the location of the world's administrative areas (boundaries) available in shapefiles.
: http://gadm.org (extracted by country [http://gadm.org/country here])

* World Borders Dataset including ISO 3166-1 Country codes available in shapefiles.
: http://thematicmapping.org/downloads/world_borders.php
* Free GIS data from Mapping Hacks
: http://mappinghacks.com/data/

=== GSHHS World Coastline ===

GSHHS is a high resolution shoreline dataset. It is derived from data in the public domain and licensed as GPL. The shorelines are constructed entirely from hierarchically arranged closed polygons. It is closely linked to the [[GMT]] project.

* Download original data from http://www.soest.hawaii.edu/wessel/gshhs/gshhs.html

* Import with the {{AddonCmd|v.in.gshhs}} GRASS Add-on module.

* Download data from [http://www.ngdc.noaa.gov/mgg/shorelines/shorelines.html NOAA's shoreline extractor] site.
: For GRASS 6 you can download 1:250,000 shoreline data from NOAA's site in Mapgen format, which can be imported with the {{cmd|v.in.mapgen}} module.

* '''Shapefiles''' for the 1.6 version are available from ftp://ftp.ihg.uni-duisburg.de/GIS/GISData/GSHHS/

=== OpenStreetMap ===

See the [[OpenStreetMap]] wiki page.

=== SALB ===

Second Administrative Level Boundaries: ''"The SALB dataset is a global digital dataset consisting of digital maps and codes that can be downloaded on a country by country basis."''

* http://www.who.int/whosis/database/gis/salb/salb_home.htm

=== VMap0 ===

1:1 million vector data. Formerly known as ''Digital Chart of the World''

* see the two articles in [http://grass.osgeo.org/newsletter/index.php ''GRASS Newsletter vol. 3 (June 2005)'']

Check the [http://en.wikipedia.org/wiki/Vector_Map Wikipedia page] on VMAP, see the links at the bottom of that article to shapefile versions of VMAP0 and VMAP1. Those look like the versions that were, several years ago, on a NIMA (predecessor to NGA, and successor to the Defense Mapping Agency that managed the Digital Chart of the World and VMAP project) Website. Many GRASS users may prefer the shapefiles to the original Vector Product Format data.

== See also ==

* [http://spatial-analyst.net/wiki/index.php?title=Global_datasets Global datasets] list by T. Hengl (with dataset download)
* The FreeGIS.org database: http://www.freegis.org/database/
* http://finder.geocommons.com/
* http://wiki.openstreetmap.org/wiki/Potential_Datasources
* http://www.geonames.org/data-sources.html
* [http://ckan.net/tag/read/geo Open Knowledge Foundation link collection]

=== National datasets ===

* [http://asdd.ga.gov.au/asdd/tech/zap/basic.html Australian Spatial Data Directory]
* [http://wiki.gfoss.it/index.php/GIS_Open_Data Italian Geodata collection]
* [http://koordinates.com/ New Zealand] data from Koordinates.com
* United States from NOAA/USGSs data portal (FIXME: link?)
* [http://geodata.gov.gr/geodata/ Greek Public Geodata] (in Greek)

=== European datasets ===

* [http://grass.osgeo.org/wiki/European_datasets European datasets]

=== Various datasets worldwide ===

* [http://geospatial.edublogs.org/ GEOSPATIAL DATA REPORT: Finding and Using GIS Data]

[[Category: Geodata]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

GIS Concepts

2011-12-30T20:50:15Z

⚠️Reverse22:

== Geodesy and Cartography ==
=== Background material ===

* [http://oceanservice.noaa.gov/education/kits/geodesy/welcome.html An introduction to Geodesy] from NOAA
* [http://en.wikipedia.org/wiki/Geodesy Wikipedia's Geodesy entry]
* [http://en.wikipedia.org/wiki/GIS Wikipedia's GIS entry]
* [http://www.nga.mil/portal/site/maritime/ Bowditch's American Practical Navigator] - (especially chapter 2)
* [http://earth-info.nima.mil/GandG/publications/ NGA Geodesy and Geophysics publications]
* [http://www.ordnancesurvey.co.uk/oswebsite/gps/information/coordinatesystemsinfo/guidecontents/index.html UK Ordnance Survey primer on coordinate system concepts] ([http://www.ordnancesurvey.co.uk/gps/docs/A_Guide_to_Coordinate_Systems_in_Great_Britain.pdf PDF])
* Clifford J Mugnier's [http://www.asprs.org/resources/grids/ Grids and Datums column from PE&RS] containing detailed descriptions of many national projections & datums

=== Map projections ===

* [http://www.mapref.org/ MapRef] - The Collection of Map Projections and Reference Systems for Europe
* [http://www.remotesensing.org/geotiff/proj_list/ Projections Transform Lists] (PROJ4)
* [http://www.dmap.co.uk/utmworld.htm UTM Zones]

EPSG:
* [http://www.epsg.org EPSG projection codes]
* [http://www.epsg-registry.org/ EPSG database search]
* [http://spatialreference.org/ Spatialreference community portal]

Projection galleries:
* [http://www.progonos.com/furuti/MapProj/CartIndex/cartIndex.html Map projection concepts] by Carlos Furuti
* [http://www.csiss.org/map-projections/index.html Map projection gallery] by Paul Anderson ([http://www.galleryofmapprojections.com/ old link])


=== Map datums ===

An extra calculation is needed when re-projecting maps and data between
two different co-ordinate systems (in addition to the re-projection) if
the two co-ordinate systems are based on different models of the
curvature of the earth. E.g. OSGB36 uses the Airy ellipsoid and WGS84 uses the WGS84 ellipsoid, which have slightly different sizes and shapes. The error is not large - generally a few hundred metres at most on the ground.
The datum transformation parameters describe this adjustment
mathematically.

As the transformation between any two datums is approximate and varies by location, different sets of parameters are often offered to give improved accuracy in different regions of a country. In general there is no one "correct" set of transformation parameters - indeed the accuracy changes over time due to tectonic movements in the Earth.

* [http://sourceforge.net/mailarchive/forum.php?thread_name=1190060064.27461.57.camel%40blackpad&forum_name=jump-pilot-devel A brief history of map datums] for the layman
* [http://www.colorado.edu/geography/gcraft/notes/datum/datum.html An introduction to geodetic datums] by Peter Dana
* [http://home.online.no/~sigurdhu/WGS84_Eng.html How WGS 84 defines the Earth]
* A discussion of [http://www.linz.govt.nz/geodetic/conversion-coordinates/geodetic-datum-conversion/nzgd1949-nzgd2000/index.aspx 3-term, 7-term, and NTv2 grid datum transformations] by Land Information New Zealand
: (besides the web page have a look at the PDF fact sheet and guide linked therein)


==How GRASS deals with geodetics==

As far as GRASS is concerned, an ellipsoid and a spheroid are the same thing, and ellipsoid is the prefered name.

As far as GRASS is concerned, a datum is made up of an ellipsoid and an origin.
Setting a datum is optional, but highly recommended.

GRASS uses a modified version of the [http://proj.maptools.org PROJ.4] library.

=== Modules controling a location's map projection ===
* [http://grass.osgeo.org/grass64/manuals/html64_user/g.proj.html g.proj] help page
* [http://grass.osgeo.org/grass64/manuals/html64_user/g.setproj.html g.setproj] help page

=== Modules for reprojecting GIS maps and data ===

* [http://grass.osgeo.org/grass64/manuals/html64_user/r.proj.html r.proj] for reprojecting raster maps
* [http://grass.osgeo.org/grass64/manuals/html64_user/v.proj.html v.proj] for reprojecting vector maps
* [http://grass.osgeo.org/grass64/manuals/html64_user/m.proj.html m.proj] for reprojecting a list of coordinate pairs

=== Modules for georectifying images ===

* [http://grass.osgeo.org/grass64/manuals/html64_user/r.region.html r.region] for resetting a raster map's bounds information
* gis.m GIS manager GeoReferencing tool (File menu)
* [http://grass.osgeo.org/grass64/manuals/html64_user/i.points.html i.points] and [http://grass.osgeo.org/grass64/manuals/html64_user/i.vpoints.html i.vpoints] for setting GCPs
* [http://grass.osgeo.org/grass64/manuals/html64_user/i.rectify.html i.rectify] for georectifying imagery
* [http://www.gdal.org GDALwarp] (use with gdal_translate, see the i.warp script in the wiki [[GRASS_AddOns#Imagery_add-ons|AddOns]] page)

;[[Georeferencing]]

==GIS Data types==

===Raster Data===

Data which occurs in a regularly spaced grid. e.g. a satellite image or digital terrain map.<BR>
Region settings determine the spatial extent and resolution of the grid.

;[http://grass.osgeo.org/grass64/manuals/html64_user/rasterintro.html Raster Intro]

[[GRASS Raster Mask]]

[[GRASS raster semantics]]

===3D Raster Data (Voxel)===

A stack of 2D raster maps.

;[http://grass.osgeo.org/grass64/manuals/html64_user/raster3dintro.html Raster 3D Intro]

===Vector Data===

Data which occurs as a series of coordinates. e.g. a GPS position or coastline map. May be a point, line, area, etc in either 2D or 3D space. Generally independent of region settings.

;[http://grass.osgeo.org/grass64/manuals/html64_user/vectorintro.html Vector Intro]
[[Vectordata]]

=== Imagery Data ===
Pixelated photographic or satellite images, often imported from a
[http://en.wikipedia.org/wiki/GeoTIFF GeoTIFF] or PNG image file.

As far as the GIS is concerned this is just another raster map, but there are several modules specially tailored for rectification and processing common imagery types. e.g. ortho-photos or multi-channel [[LANDSAT]] data.

* [http://grass.osgeo.org/grass64/manuals/html64_user/imageryintro.html GRASS Imagery module introduction]

* The GRASS [[Image processing]] wiki page

===Site Data===
Old versions of GRASS (5 and earlier) treated point data separate to line and polygon data. GRASS 6 classes all vector data features the same. Convert old sites file data into GRASS 6 vector format with the GRASS 6 [http://grass.osgeo.org/grass64/manuals/html64_user/v.in.sites.html v.in.sites] or
[http://grass.osgeo.org/grass64/manuals/html64_user/v.in.sites.all.html v.in.sites.all] modules.

==Conversions between data types==

The following table is intended to catalog transformations from one type of data to another:<BR>
''[table is currently incomplete!]''

{| border="1"
| From / To
![http://grass.osgeo.org/grass64/manuals/html64_user/rasterintro.html Raster]
![http://grass.osgeo.org/grass64/manuals/html64_user/raster3dintro.html 3D Raster]
![http://grass.osgeo.org/grass64/manuals/html64_user/vectorintro.html Vector]
|-
! Raster
| r.mapcalc
| r.to.rast3
| r.to.vect, v.sample, r.volume
|-
! 3D Raster
| r3.to.rast, r3.cross.rast
| r3.mapcalc
|
|-
! Vector
| v.to.rast, v.surf.rst, v.surf.idw
| v.vol.rst, v.vol.idw, v.to.rast3
| v.clean
|-
! Data
| r.in.*
| r3.in.*
| v.in.*
|}

==How a GRASS project is organized==

GRASS data is stored in a three level structure, the database, location and mapset. These can be found in a series of nested directories on the user's computer. All three must exist and are set at GRASS startup time.

===The Database===

The directory in which all GIS data is to be stored.

e.g. <tt>~/grassdata/</tt>

===The Location===

A ''location'' is a GRASS project consisting of an area, projection definition (or unprojected), a grouping of mapsets, all with the same projection settings. A location is a subdirectory of the GRASS ''database''.

e.g. world_lat_lon, utm_zone_59, or west_coast

A ''location'' contains one or many ''mapsets''.

===The Mapset===

A ''mapset'' contains map(s), it is a subdirectory of a ''location''.
Conceptually, if several mapsets are used in a location, they may be assigned to different users (each has one or several own mapsets to work in and cannot modify thos of other users), and/or it they are used to organize a project (''location'') by subareas or subprojects.
There are no specific organizational limitations.

There is always a PERMANENT mapset which is readable from all other mapsets within the same location. Read access to maps in other mapsets is managed with the 'g.mapsets' command or by adding the "@" symbol and mapset name (e.g. <tt>map@othermapset</tt>).

==Raster GIS Analysis==

===Simple Raster Math===

Sometimes when analyzing the relationship between two or more raster data sets, a relatively simple mathematical approach is best. One example using the {{cmd|r.mapcalc}} tool would be to look at changes between two raster data sets. By subtracting the values in these two data sets you can assume that resulting cells with a positive value have a positive change and those with a negative value have negative change. If the cell values have a zero value then there would be no change.

GRASS comes bundled with the {{cmd|r.mapcalc}} command line tool as well as a GUI interface for the tool accessible using the {{cmd|r.mapcalculator}} command. This GUI allows the user to easily assign raster maps to the variables used in the formulas and easily create mathematical strings that will result in a new raster data set containing the results.

[[Category:Community]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

Geophysics

2011-12-30T20:49:53Z

⚠️Reverse22:

Given GRASS great raster function, it is suprising that so few (none?) geophysics applications surfaced so far.

In August, 2008, talks were initiated regarding the creation of modules to address potential field methods.

So far, the iniative has produced some wikipages and tentative "software specs".

The initial focus is on '''[[Gravity]]''' and '''[[Geomagnetism]]'''.

== Potential Field Methods ==

The USGS has two reports on this subject. [http://pubs.usgs.gov/of/1997/ofr-97-0725/ Open-File Report 97-725], '''Potential-Field Geophysical Software for the PC, version 2.2''' and [http://pubs.usgs.gov/of/1995/ofr-95-0077/of-95-77.html Open-File Report 95-77], '''A bibliography of some geophysical computer programs, databases, and maps from the U.S. Geological Survey, 1971-1994'''. Most of the software listed here is provided with source.

The Colorado School of Mines also has [http://geophysics.mines.edu/cgem/workshops_software/CGEM_App.html software libraries].

== Reflection Seismic ==

GRASS has already support for 3D rasters. Reading 2D/3D seismic data might be achieved via integration with [http://www.cwp.mines.edu/cwpcodes/ CWP/SU], which is licensed under a BSD-style open source [http://www.cwp.mines.edu/cwpcodes/LEGAL_STATEMENT license].

== P190 input ==

Have a look in the GRASS addons for the {{AddonCmd|v.in.p190}} script for loading ship tracks as vector lines.
: ''v.in.p190 is a shell script that imports 'Centre of Source' "S" navigation data from seismic P1/90 (UKOOA) data files and writes it either GRASS vector points or vector lines format. Optionally it will export the navigation data into .csv text files as well.''

== SEG-Y input ==

Have a look in the GRASS addons for the {{AddonCmd|v.in.mbsys_fnv}} script for loading ship tracks as vector lines.
: ''v.in.mbsys_fnv imports MB-System navigation files into a GRASS vector map. You can choose from swath area coverage, track lines (including outer port/starboard edges), all bounds as points, etc. An attribute database is created containing the vital statistics of the specified feature such as track length or swath coverage (geodesic), start stop time and location, pitch, roll, heave, etc.''

The MB-Systems software (GPL) has a `segytogrd` program which creates a GMT grid which can be imported into GRASS with the {{cmd|r.in.gdal}} module. (theoretically)

[[Category:Applications]]
[[Category:Documentation]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

Geomagnetism

2011-12-30T20:49:43Z

⚠️Reverse22:

Magnetism is an ever present phenomenon in our daily lives. More so in some geo/cartographic contexts. Providing a way to add magnetic information to our GRASS projects might be helpful.

Here is a gathering of ideas, in order to produce geomagnetic modules or scripts to GRASS

== Interesting Links ==

The California Soil Resource Lab has some quite interesting information for production of a
[http://casoilresource.lawr.ucdavis.edu/drupal/node/560 Detailed Magnetic Declination] map.

As Dylan points out in his post, Stefan Maus has put together an excellent website on the [http://geomag.org/info/declination.html Historical main field change and declination]. (This sentence shamelessly pasted from Dylan's blog)

They also cite the NOAA website, which has [http://www.ngdc.noaa.gov/IAGA/vmod/igrf.html IGRF] and [http://www.ngdc.noaa.gov/geomag/WMM/soft.shtml WMM] computer models available for download (registration not necessary). They also have several [http://www.ngdc.noaa.gov/geomag/geom_util/utilities_home.shtml utility programs].

The USGS has a [http://pubs.usgs.gov/of/1997/ofr-97-0725/ collection of software], however it dates of 1997. This Open-File Report (97-725) is named '''Potential-Field Geophysical Software for the PC, version 2.2''' and supersedes [http://pubs.usgs.gov/of/1995/ofr-95-0077/of-95-77.html Open-File Report 95-77], from 1995, '''A bibliography of some geophysical computer programs, databases, and maps from the U.S. Geological Survey, 1971-1994'''.

The [http://www.on.br Brazilian National Observatory] (ON) also had its own geomagnetic model, called ELEMAG, which agrees with the IGRF, but is calibrated to work only in Brazil. I ([[User:Pmarc|Pmarc]]) however, have not been able to find it on their website, on the other hand, [http://www.google.com/search?q=Declinação+elemag+on Google] was able to find some versions online.

== Tips ==

* Rotating a [[IconSymbols|north arrow symbol]] by a given amount can be accomplished using the '''d.graph''' module or in a '''[[Ps.map_scripts#Creating_a_fancy_North_Arrow|ps.map]]''' plot using a specified rotation angle.

* The d.rast.arrow module may be of use for [http://grass.osgeo.org/grass62/screenshots/images/d_rast_arrow_magnitude.png visualizing] gravity fields.

== Wishlist ==

* Module capable of computing the magnetic field (all 7 components) over a location, for a given date or range of dates. It seems to me ([[User:Pmarc|Pmarc]]) that the most appropriate output would be a vector map. The starting point could be the IGRF model provided by NOAA (link above)

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

Geology

2011-12-30T20:49:33Z

⚠️Reverse22:

== Modules of interest ==

* {{cmd|ps.map}} for cartography
* {{cmd|v.vol.rst}} for 3D raster voxel interpolation
* {{cmd|raster3dintro}}: Introduction to 3D raster processing
: see also r3.* commands
* {{cmd|nviz}}: Native 3D visualization and animation suite (interactive cutting planes through stacked 3D grid surfaces, etc.)
* {{cmd|v.out.vtk}}, {{cmd|r.out.vtk}}, and {{cmd|r3.out.vtk}}: Export to VTK format for ParaView or other 3D visualization software

* [http://grass.osgeo.org/wiki/GRASS_AddOns#d.frontline d.frontline] Shell script that draws frontlines on the graphics monitor using d.graph module and different types of symbols. Also it optionally saves frontline graphics to d.graph commands file and/or ps.map file (for later use with the "read" ps.map instruction).

== Cartography ==

=== Examples ===
* See the Cartography {{website|screenshots|screenshots}} page

=== Strike-and-dip symbols ===

See the [[IconSymbols]] wiki page

* <tt>geology/strike_line,box,triangle,circle</tt>:
: [[Image:Symb-geo.png|350px]]

* <tt>geology/strike_half-bowtie</tt>:
: [[Image:Symb-geo_bowtie.png|100px]]
: (to get a full bowtie: overlay two, rotate one of them by 180 degrees)

* <tt>geology/half_arrow</tt>:
: [[Image:Half_arrow_x2.png]]
: (two displayed, one of which has been rotated 180 degrees)

* {{cmd|ps.map}} can take rotation angle from an attribute column for each site with the '''''vpoints''' rotatecolumn'' instruction; for {{cmd|d.graph}} you can prepare a command file with a custom rotation for each point using {{cmd|v.out.ascii}}, {{cmd|v.db.select}}, or the ''v.out.ascii.db'' addon script. Note that GRASS uses the Cartesian convention for rotation angles, i.e. CCW from east. Convert from compass angles (CW from north) with:
theta = 90 - degrees_true
: You could possibly write a small {{cmd|db.execute}} script to populate a new column with this conversion by way of a SQL query. (and post it here :)

* to make open symbols set the fill color to 'none'.
* to make a double sided dip symbol draw the same symbol twice with 180 rotation the second time.

=== Fill patterns ===

* [[AreaFillPatterns]]: {{cmd|ps.map}} allows custom fill patterns based on simple PostScript-like rules files. A number of patterns are provided. It is reasonably simple to create new ones- just copy an existing one to a new file and edit the drawing coordinates in a text editor. (new contributions welcome)

=== Dashed lines ===

In {{cmd|ps.map}} use the '''''vlines''' style'' instruction to set the line style. The ''linecap'' instruction can further refine the draw mode.

== Links ==

* ...

[[Category:Applications]]
[[Category:Documentation]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

Create concave hull

2011-12-30T20:49:13Z

⚠️Reverse22:

Q: I have a set of points and would like to compute the concave hull of it.

A: You can approximate a concave hull through the following steps:

* create map of lines connecting all points (I find it easier to do this with v.net.visibility, but v.distance works also)
* add a table with a column 'cat' and a column 'length double precision' and categories to these lines (v.db.addtable, v.category)
* upload the length of each line to the table (v.to.db)
* visually identify a length threshold above which the lines should not be used
* extract only those lines below that threshold (v.extract where="length<MAXLENGTH)
* convert the lines to boundaries (v.type)
* break overlapping lines (v.clean tool=break, there shouldn't be any duplicate lines, but just in case you can also use rmdupl)
* add centroids with the same category value to the boundaries (v.centroids step=0)
* dissolve the areas into one (v.dissolve)

The image to shows the results:

[[Image:Concave_hull.jpg|500px]]

[[Category:FAQ]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

Compile and Install

2011-12-30T20:49:04Z

⚠️Reverse22:

{{MoveToTrac}}

'''Disclaimer''': This page explains how to turn the GRASS GIS source code into an installable binary package ("compilation") for different operating systems. If you just want to get ready-to-use binaries, go [http://grass.osgeo.org/download/ here], otherwise read on...

== How to do compilation and installation of GRASS 6? ==

Here we explain the procedure to compile GRASS from SVN, but it also applies to official GRASS 6 releases.

''For installation of precompiled binary packages, see the main [[Installation Guide]].''

For detailed information on compilation, please see the [http://grass.osgeo.org/grass64/source/INSTALL INSTALL] file in the source code.

=== Prerequisites ===

GRASS needs at least two extra libraries: PROJ and GDAL/OGR

''Note: if you want to have DBMS support in GDAL (subsequently in GRASS) you have to perform the "Optional" steps below as well.''

* [http://trac.osgeo.org/proj/ PROJ4] for management of projections (with proj-datumgrid-1.3.zip support)
* Optional: [http://trac.osgeo.org/geos/ GEOS]
* Optional: [http://www.postgresql.org PostgreSQL], [http://www.mysql.org mySQL], [http://www.unixodbc.org unixODBC], [http://www.sqlite.org SQLite] (SQLite is needed for [[QGIS]])
* [http://www.gdal.org GDAL/OGR] for reading and writing various GIS data formats (interoperability)

You have to install these two libraries '''first'''.

It is easiest to obtain a prepackaged version of these libraries (e.g., .rpm; .deb) for your particular operating system and run the corresponding package installation (e.g., rpm -Uhv packagename.rpm; apt-get) in a terminal window. Take care to also install the development packages of these libraries (...-devel packages). If there is no prepackage version, then you will have to download the source code (see links above, source code packages usually ends in .tar.gz or .zip) and compile it (you must have a C compiler installed as part of your operating system). The Web sites show the steps to compile the libraries.

Other libraries needed to run GRASS are listed on the {{website|grass64/source/REQUIREMENTS.html|requirements page}}.

To compile, you will also need the respective "-devel" packages.

Then [http://grass.osgeo.org/download/index.php#g64x download GRASS] of course.

=== Generic Compilation and installation procedure ===

* It is wise that compilation processes are carried out as a normal user: If you want to get the source code in a place where you do not have write permissions (e.g. in /usr/local/src/) just follow this:
cd /usr/local/src/
su -c 'mkdir grass6'
su -c 'chown yourlogin:yourgroup grass6'

Otherwise if you have permissions just continue as a normal user:
cd /usr/local/src/
svn checkout ...

* do a code checkout from the SVN source code repository
: checkout the latest GRASS 6.x from SVN (see: {{twiki|DownloadSource}})

* in the grass6 directory, you will find the precious INSTALL file, open it with your favourite pager/editor and read it carefully!

* run configure with parameters to adapt the compile process to your own system. To see what options can be passed to it, run:
./configure --help | less


It may (!) look like this:

./configure \
--with-cxx \
--with-sqlite \
--with-postgres-libs=/usr/include/pgsql/libpq \
--with-postgres-includes=/usr/include/pgsql \
--with-freetype \
--with-freetype-includes=/usr/include/freetype2 \
--with-motif \
--with-proj-share=/usr/share/proj

You may have to explicitly state the path for certain packages (i.e., gdal). The Unix 'locate' command will come in handy for finding the path of the package you need (you may have to run locate as root ex: sudo locate gdal-config).

Please note that the paths mentioned may widely vary due to the distribution used.
See [[Compile_and_Install#Platform_Specific_Notes|Platform Specific Notes]] below.

Depending on your needs it may be a good idea to include debugging hooks.
: See [[GRASS_Debugging#Compile_Time_Setup]].
CFLAGS="-ggdb -Wall -Werror-implicit-function-declaration" ./configure ...

At the end of configuration process you should get report not much different from this:

GRASS is now configured for: i686-pc-linux-gnu

Source directory: /usr/src/grass6
Build directory: /usr/src/grass6
Installation directory: /usr/local/grass-6.3.svn
Startup script in directory: ${exec_prefix}/bin
C compiler: gcc -g -O2
C++ compiler: c++ -g -O2
FORTRAN compiler:
Building shared libraries: yes
64bit support: no

NVIZ: yes

BLAS support: no
C++ support: yes
DWG support: no
FFMPEG support: no
FFTW support: yes
FreeType support: yes
GDAL support: yes
GLw support: no
JPEG support: yes
LAPACK support: no
Large File Support (LFS): no
Motif support: no
MySQL support: no
NLS support: no
ODBC support: no
OGR support: yes
OpenGL(R) support: yes
PNG support: yes
PostgreSQL support: yes
Readline support: no
SQLite support: no
Tcl/Tk support: yes
TIFF support: yes
X11 support: yes

* Let's compile it (takes a little while...)!
make
* At the end, you should get report not much different from this:
----------------------------------------------------------------------
Following modules are missing the 'description.html' file in src code:
----------------------------------------------------------------------
GRASS GIS compilation log
-------------------------
Started compilation: Ne kvě 28 13:18:43 CEST 2006
--
Errors in:
--
Finished compilation: Ne kvě 28 13:43:40 CEST 2006
(In case of errors please change into the directory with error and run 'make')

* If there is any error, change directory to directory with error and run "make" again. Report occuring bug to grass mailing list
* Once the installation process is finished, you're ready to install GRASS system wide.
su -c 'make install'
* enjoy GRASS:
grass64

=== What else? ===

If you want to use [http://www.qgis.org QGIS], then also compile the GRASS-GDAL/OGR plugin. This is also useful to access your GRASS-data
from other application using GDAL/OGR like [http://thuban.intevation.de thuban].
* [[Compile and install GRASS and QGIS with GDAL/OGR Plugin]] (enables QGIS to read GRASS data directly)

=== Compile and install GDAL-GRASS plugin ===

* See [[Compile and install GDAL-GRASS plugin]]

=== Platform Specific Notes ===

==== Linux ====

===== Debian =====

Read the instructions here:
: http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/debian/README.debian

# first install PROJ, GDAL, etc.
cd grass64/
# follow instructions in debian/README.debian
fakeroot buildpackage

* Official [http://wiki.debian.org/DebianGis DebianGIS] packaging [http://svn.debian.org/viewsvn/pkg-grass/packages/grass/ control files], also accessible via svn:

svn co svn://svn.debian.org/svn/pkg-grass/packages/grass/trunk/

or

svn co svn://svn.debian.org/svn/pkg-grass/packages/grass/branches/<GRASS Version>

====== GRASS 6.1 on Debian Sarge ======

* [http://hamish.bowman.googlepages.com/debiangisfiles#compile Compiling GRASS 6.1-CVS on Debian/OldStable (aka 3.1, Sarge)]

====== GRASS 6.4 on Debian Lenny ======

Install needed packages:
apt-get install flex bison libreadline-dev libncurses5-dev lesstif2-dev debhelper dpatch libtiff4-dev \
tcl-dev tk-dev libfftw3-dev libxmu-dev libfreetype6-dev autoconf2.13 autotools-dev doxygen \
libmysqlclient15-dev graphviz libsqlite3-dev python-wxgtk2.8 libcairo2-dev libwxgtk2.8-dev \
python-dev swig libgdal1-dev libgdal1-1.5.0 libproj-dev libproj0 proj-data mysql

Configure:
./configure \
--with-cxx \
--with-sqlite \
--with-postgres --with-postgres-includes=/usr/include/postgresql \
--with-mysql --with-mysql-includes=/usr/include/mysql --with-mysql-libs=/usr/lib/mysql \
--with-odbc \
--with-cairo \
--with-proj-share=/usr/share/proj \
--with-tcltk-includes=/usr/include/tcl8.4/ \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--with-motif --with-fftw --with-nls --with-python

Compile:
make

Install:
sudo make install

====== GRASS 7 on Debian Squeeze ======

Install needed packages:
apt-get install flex bison debhelper dpatch autoconf2.13 autotools-dev python-dev
g++ gcc gettext graphviz libcairo2-dev libfftw3-dev libfreetype6-dev \
libgdal1-1.6.0 libgdal1-dev libglu1-mesa-dev libglw1-mesa-dev \
libncurses5-dev libproj-dev libreadline-dev libsqlite3-dev libtiff4-dev \
libwxgtk2.8-dev libxmu-dev libxmu-headers libxt-dev mesa-common-dev \
proj-bin python-numpy python-wxgtk2.8 subversion wx-common zlib1g-dev

Download source code:

svn checkout https://svn.osgeo.org/grass/grass/trunk grass_trunk

Configure:

CFLAGS="-g -Wall -Werror-implicit-function-declaration -fno-common -Wextra -Wunused" \
CXXFLAGS="-g -Wall" \
./configure --prefix=/usr/local \
--with-gdal --with-proj --with-proj-share=/usr/share \
--with-glw --with-nls --with-readline \
--without-tcltk \
--with-cxx \
--enable-largefile \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--with-sqlite \
--with-cairo --with-python=/usr/bin/python2.6-config --with-wxwidgets \
--with-geos --with-pthread

Compile:
make

Install:
sudo make install

===== Ubuntu =====

''The above Debian notes will probably work with Ubuntu as well.''

A more [[Compile_and_Install_Ubuntu | specific page]] towards Ubuntu is being written on.

====== Ubuntu 6.06, 7.10 ======

* [http://david.p.finlayson.googlepages.com/makegrass.sh makegrass.sh] is script designed to automate most of the download, configuration and compilation of GRASS 6.x-CVS
** it is advised use [https://help.ubuntu.com/community/CheckInstall checkinstall] (''sudo apt-get install checkinstall'') instead of ''make install'' to keep track of installed software
** Think twice before using this script. Some users experienced problems such as disabled XGL etc.
* [[User:Steko/Automated_CVS_compiling|Here]] is another of these scripts, it's homemade so probably you'll find the above more useful for production sites.

====== Ubuntu 7.10 64-bit ======

* Compiling latest GRASS source code on a 64-bit machine (with an ATI graphic card) under Ubuntu 7.10 64-bit with support for: 64-bit, SQLite, OpenGL, PYTHON, FFMPEG
(Based on "Ubuntu 6.06 LTS - GRASS 6.1 Compilation Script" by David Finlayson)
''Assuming it is the first time attempting to compile GRASS' source code & installing SVN, PROJ, GDAL/OGR''

'''Preparation'''
sudo apt-get update && sudo apt-get upgrade

* install dependencies for compiling (in general) and dependencies for GRASS: PROJ, GDAL/OGR
sudo apt-get install grass build-essential flex bison libncurses5-dev zlib1g-dev \
libjpeg62-dev libgdal1-dev libtiff4-dev libgcc1 libpng12-dev tcl8.4-dev tk8.4-dev fftw3-dev \
libfreetype6-dev libavcodec-dev libxmu-dev gdal-bin libreadline5 libreadline5-dev \
make python-dev python-wxversion swig

* install SQLite
sudo apt-get install sqlite3 libsqlite3-dev

* install SVN
sudo apt-get install subversion

* create a directory as a simple user where source code(s) are going to be stored (in our example we use a directory called '''src''' under '''/usr/local''')

sudo mkdir /usr/local/src

* grant rwx (read-write-execute) permissions for our userid/ groupid on the directory (replace words userid and groupid with real userid):
sudo chown ''userid'':''groupid'' /usr/local/src

sudo chmod ug+rwx /usr/local/src

* download latest source code from GRASS SVN repository in a directory on the system (e.g. /usr/local/src)
svn checkout https://svn.osgeo.org/grass/grass/trunk grass_trunk

* Above command places GRASS' source code in '''/usr/local/src/grass_trunk'''. In case of a subsequent update use the command: '''svn up''' from within the grass_trunk directory

----
'''Before''' attempting to compile GRASS, READ section (C) in the '''INSTALL''' file located in the main directory of GRASS source code entitled:
'''(C) COMPILATION NOTES for 64bit platforms'''
----

* installing FFTW3 if not already on system
sudo apt-get install fftw3 fftw3-dev

'''FFMPEG'''

Note: Back in Ubuntu 7.10, installing ffmpeg through the repositories wouldn't work with grass. The following steps were successfully used.

* install FFMPEG (information taken from: http://stream0.org/2008/01/install-ffmpeg-on-ubuntu-gutsy.html)
* download source code with svn
svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg

* install dependencies
sudo apt-get install liblame-dev libfaad2-dev libfaac-dev libxvidcore4-dev \
liba52-0.7.4 liba52-0.7.4-dev libx264-dev libdts-dev checkinstall \
build-essential subversion

* guide to ffmpeg directory
cd ffmpeg

if necessary: '''make distclean''' before configuration (look at notes below)

* configuration ('''note:''' the configuration parameter "'''--enable-pp'''" does not work anymore)
# configure FFMPEG
./configure --enable-gpl --enable-libvorbis --enable-libtheora \
--enable-liba52 --enable-libdc1394 --enable-libgsm \
--enable-libmp3lame --enable-libfaad --enable-libfaac \
--enable-libxvid --enable-pthreads --enable-libx264 \
--enable-shared

* compilation
make

* installation on /usr/local/bin -- important to remember when configuring GRASS' source code for compilation
sudo checkinstall

'''Go for GRASS!'''
* in our example we used the /usr/local/src directory to store GRASS' source code, so:
cd /usr/local/src/grass_trunk

* configuration
CFLAGS="-g -Wall" ./configure --enable-64bit \
--with-libs=/usr/lib64 --with-cxx --with-freetype=yes \
--with-postgres=no --with-sqlite=yes --enable-largefile=yes \
--with-tcltk-includes=/usr/include/tcl8.4 \
--with-freetype-includes=/usr/include/freetype2 \
--with-opengl-libs=/usr/include/GL --with-readline \
--with-python=yes --with-ffmpeg=yes \
--with-ffmpeg-includes=/usr/local/include/ffmpeg

*if OpenGL fails then maybe it is necessary to link '''glxATI.h''' with '''glx.h''' and re-run the configuration

cd /usr/include/GL

sudo ln glxATI.h glx.h

* compilation
make

* compilation is expected to end with a statement similar to the following:

Started compilation: Wed Feb 27 00:24:36 CET 2008
--
Errors in:
No errors detected.

* installation
sudo checkinstall

* launch 64-bit GRASS.6.4.svn
grass64

'''Notes'''
* in case of errors in future compilation attempts, remember to remove program binaries with
make clean
* and the files created with the "configuration" from previous compilations with
make distclean

====== Ubuntu 8.04 and above ======

* See [[Compile and Install Ubuntu‎]]

===== Mandriva =====

Installation of dependencies (urpmi will ask you a few more):

'''Mandriva 2009:''' (take out the '64' everywhere if you are on 32bit)
# as root
urpmi flex bison zlib-devel tiff-devel png-devel tcl-devel tk-devel sqlite3-devel \
mesagl1-devel mesaglu1-devel lib64xmu6-devel gcc-c++ swig gettext \
lib64wxgtk2.8 lib64wxgtk2.8-devel lib64wxgtkgl2.8 wxgtk2.8 \
lib64wxPythonGTK2.8 lib64wxPythonGTK2.8-devel wxPythonGTK wxPythonGTK-wxversion
exit

'''Mandriva 2010:''' (take out the '64' everywhere if you are on 32bit) - see also [http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/grass/current/SPECS/ SPEC] file
# as root
# installation of PROJ and GDAL
urpmi proj proj-devel gdal gdal-devel gcc-gfortran lib64openssl1.0.0 \
lib64openssl1.0.0-devel postgresql8.4-devel lib64pq8.4

# installation of compilation environment
urpmi flex bison zlib-devel tiff-devel png-devel tcl-devel tk-devel sqlite3-devel \
lib64mesagl1-devel lib64mesaglu1-devel lib64xmu6-devel gcc-c++ swig gettext \
lib64jpeg-devel lib64wxgtk2.8 lib64wxgtk2.8-devel lib64wxgtkgl2.8 wxgtk2.8 \
lib64wxPythonGTK2.8 lib64wxPythonGTK2.8-devel wxPythonGTK wxPythonGTK-wxversion
exit

Then, to configure GRASS, run (64 bit stuff optional of course):
# as user
./configure \
--enable-64bit --with-libs=/usr/lib64 \
--with-cxx \
--with-gdal=/usr/local/bin/gdal-config \
--with-sqlite \
--with-nls \
--with-python \
--with-wxwidgets=/usr/lib/wxPython/bin/wx-config \
--with-fftw \
--with-ffmpeg --with-ffmpeg-includes="/usr/include/libav* /usr/include/libpostproc /usr/include/libswscale" \
--with-motif \
--with-mysql --with-mysql-includes=/usr/include/mysql --with-mysql-libs=/usr/lib64 \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--enable-largefile

# compilation (use -j2 ior -j4 parameter on multi-core CPUs to accelerate):
make

Installation:
su
# this will install into /usr/local/
make install
exit

===== CentOS =====

Note: CentOS 5 comes with Python 2.4 which lacks python-config, hence two extra tweaks are needed.

Preparation:
yum install flex bison zlib-devel tcl-devel tk-devel gcc-c++ swig gettext \
libtiff-devel libpng-devel sqlite-devel libjpeg-devel \
mesa-libGL-devel mesa-libGLU-devel mesa-libGLw-devel \
mesa-libOSMesa-devel libXmu-devel python-devel gtk2-devel\
ncurses-devel postgresql-devel

Compile and install [http://proj.osgeo.org PROJ4]:

# get source code and unpack:
wget http://download.osgeo.org/proj/proj-4.7.0.tar.gz
tar xvfz proj-4.7.0.tar.gz
rm -f proj-4.7.0.tar.gz
cd proj-4.7.0/

# get and install datum files into right directory:
cd nad/
wget http://download.osgeo.org/proj/proj-datumgrid-1.5.zip
unzip proj-datumgrid-1.5.zip
rm -f proj-datumgrid-1.5.zip
cd ..

# configure and compile
sh configure
make -j4

# install (may require "root" permissions, use "su"):
make install

Compile and install [http://www.gdal.org GDAL]:
# get source code and unpack:
wget http://download.osgeo.org/gdal/gdal-1.6.3.tar.gz
tar xvfz gdal-1.6.3.tar.gz
rm -f gdal-1.6.3.tar.gz
cd gdal-1.6.3/

# configure and compile
sh configure
make -j4

# install (may require "root" permissions, use "su"):
make install

# add /usr/local/lib/ to LD_LIBRARY_PATH, requires "root" permissions:
su -
echo "/usr/local/lib" > /etc/ld.so.conf.d/gdal.conf
ldconfig
exit

# test installation by running
gdalinfo

GRASS 7 compilation and installation, here 64bit example:

1. Download wxGTP and wxPython:

wget http://packages.sw.be/wxPython/wxPython-2.8.9.1-1.el5.rf.x86_64.rpm
wget http://packages.sw.be/wxPython/wxPython-devel-2.8.9.1-1.el5.rf.x86_64.rpm
wget http://packages.sw.be/wxGTK/wxGTK-2.8.9-1.el5.rf.x86_64.rpm
wget http://packages.sw.be/wxGTK/wxGTK-devel-2.8.9-1.el5.rf.x86_64.rpm

# Install:
rpm -Uhv wxPython-2.8.9.1-1.el5.rf.x86_64.rpm wxPython-devel-2.8.9.1-1.el5.rf.x86_64.rpm \
wxGTK-2.8.9-1.el5.rf.x86_64.rpm wxGTK-devel-2.8.9-1.el5.rf.x86_64.rpm

2. [http://grass.osgeo.org/download/ Download] and configure GRASS 7 (suggestion: save this as script). Note that [http://proj.osgeo.org PROJ4] and [http://www.gdal.org GDAL] must be compiled first:

./configure \
--with-libs=/usr/lib64 \
--with-cxx \
--without-ffmpeg \
--with-gdal=/usr/local/bin/gdal-config \
--without-odbc \
--with-sqlite \
--with-postgres \
--without-mysql \
--with-nls \
--with-python \
--with-cairo \
--with-wxwidgets=/usr/bin/wx-config \
--without-fftw \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--enable-largefile \
--with-pthread

3. Hack the Makefile of GRASS-SWIG since python-config isn't there (add one line without the '+'):

svn diff swig/
Index: swig/python/Makefile
===================================================================
--- swig/python/Makefile (revision 38916)
+++ swig/python/Makefile (working copy)
@@ -36,6 +36,7 @@
EXTRA_SWIG = ../include/python/my_typemaps.i ../include/python/common.i
SWIGFLAGS = $(INC) -I../include/python -outdir .
EXTRA_CFLAGS = $(PYMOD_CFLAGS)
+EXTRA_LIBS = -lpython2.4
EXTRA_CLEAN_FILES := $(foreach M,$(MODULES),$(M)_wrap.o $(M)_wrap.c $(M).pyc $(M).py _$(M).so)
CLEAN_SUBDIRS = NumPtr

4. Add manually the path to the python include directory since python-config isn't there:

# edit include/Make/Platform.make
# and add manually the line

PYTHONINC = -I/usr/include/python2.4

5. Compile
make
or on multicore:
make -j4

6. Either install with "make install" or run directly from compile directory (substitute ARCH with i586 or x86_64):

bin.$ARCH/grass70 -wx

===== Gentoo =====

See http://gentoo-portage.com/sci-geosciences/grass

===== Fedora =====

Ingredients:

yum install proj-devel libjpeg-devel gdal-devel sqlite-devel ffmpeg-devel mesa-libGL-devel \
mesa-libGLU-devel libXmu-devel tcl-devel fftw-devel lesstif-devel python-devel \
wxPython wxGTK-devel bison flex ncurses-devel proj-epsg proj-nad xml2

''Note 1: that currently gdal-devel has (too) many dependencies and will lead to a massive download of extra packages (200 on a fresh Fedora 16 install).''

''Note 2: ffmpeg-devel comes from the rpmfusion-free repository.''

This is an example how to compile GRASS 6 on a 32bit Fedora system:

./configure \
--with-cxx \
--with-gdal=/usr/bin/gdal-config \
--with-proj --with-proj-share=/usr/share/proj \
--with-sqlite \
--with-nls \
--with-wxwidgets=/usr/bin/wx-config \
--with-fftw \
--with-python=/usr/bin/python-config \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--enable-largefile \
--without-odbc

This is an example how to compile GRASS 6 on a 64bit Fedora system:

./configure \
--with-cxx \
--with-gdal=/usr/bin/gdal-config \
--with-proj --with-proj-share=/usr/share/proj \
--with-sqlite \
--with-nls \
--with-wxwidgets=/usr/bin/wx-config \
--with-fftw \
--with-python=/usr/bin/python-config \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--without-odbc

An effective (but not fast) way of getting dependencies is to decide what to enable in the configuration, and then run ./config and see which files are missing. The package providing it can be found via:

yum provides */<name of the file>

and then installed with your favourite package manager frontend.

===== RPM SPEC files =====
* ... can be found in the source code, rpm/ directory,
* or [https://build.opensuse.org/package/show?package=grass&project=Application%3AGeo OpenSuSe]
* or [https://admin.fedoraproject.org/pkgdb/acls/name/grass Fedora]
* or [http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/grass/ Mandriva] (there are also [http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/proj/ proj4], [http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/geos/ geos], [http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/gdal/ gdal], [http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/gdal-grass/ gdal-grass-plugin], [http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/qgis/ qgis] etc)

===== Zaurus =====

... see [http://wiki.debian.org/?GrassGISonZaurus here] for instructions

==== Mac OSX ====

* see the source/macosx readme
* also see [[Compiling on MacOSX]]
* some notes on [[Packaging on MacOSX]]
* Download [http://www.kyngchaos.com/software/frameworks#build_scripts build scripts]

==== Solaris ====

* ''2008 Oct 15'': see [http://lists.osgeo.org/pipermail/grass-user/2008-October/047093.html this post on the grass mailing list]

===== 10 SPARC/i86pc =====

* get gcc compiler and tools. There are several sources: Solaris Companion CD (SFW pkg, installs in /opt/sfw/), Blastwave ([http://www.blastwave.org], CSW pkg, installs in /opt/csw/) or Sunfreeware ([http://www.sunfreeware.com], SMC pkg, installs in /usr/local/).
Needed Packages from Sunfreeware: SMCbinut, SMCbison, SMCcoreu, SMCfindu, SMCflex, SMCgawk, SMCgcc, SMCgrep, SMCgzip, SMCless, SMClibt, SMClicon, SMCmake, SMCncurs, SMCproj, SMCsed, SMCtar, SMCtcl, SMCtiff, SMCtk, SMCunzip, SMCzlib.

* compile and install fftw-library ([http://www.fftw.org]). You need to re-compile the library with:

./configure --with-pic --enable-shared; make ; make install.

The pre-built packages don't work.

* compile and install gdal library (see documentation of gdal, [http://www.gdal.org]).

* compile and install any additional libraries (e. g. GEOS, [http://geos.refractions.net]).

* set compiler flags and path. e. g.:

# on ultra-sparc machine:
CFLAGS="-O3 -mcpu=v9"
CXXFLAGS="-O3 -mcpu=v9"
PATH="/usr/local/bin:/opt/sfw/bin:/usr/ccs/bin:/usr/bin:/usr/sbin"
export CFLAGS CXXFLAGS PATH

Path has to be changed for the packages (Sunfreeware: /usr/local/bin, Solaris Companion: /opt/sfw/bin, Blastwave: /opt/csw/bin).

* Next configure, e. g.:

./configure --with-postgres-includes=/usr/include/pgsql/ \
--with-postgres-libs=/usr/lib --with-postgres=yes \
--with-includes=/usr/local/include/ncurses

If you use n(ew)curses, you have to include the path /usr/local/include/ncurses.

then:

make
su
make install

If the shared libraries are not found at runtime of the modules, use 'crle' to add the paths of the libraries for the dynamic linker, e. g. as root:

crle -l /lib:/usr/lib:/usr/local/lib:/opt/sfw/lib:/usr/X11/lib

Be careful not to omit a library path, the system may be unusable if you forget the /lib path.

==== AIX ====

* ''see [http://thread.gmane.org/gmane.comp.gis.grass.user/32667 this mailing list thread]''

Mike wrote:
<pre>
After attempting all the suggestions, I finally used
--disable-shared on the configure command, and all but
a handful of modules successfully compiled. I was able to
individually address the ones that failed through Makefile
edits and several small source code/header file edits.

The environment variables and configure command that worked were:

export PATH=/usr/local/bin:/opt/freeware/bin:$PATH
export OBJECT_MODE=64
export LIBICONV=/opt/freeware
export CC="xlc_r -q64"
export CFLAGS="-O -qstrict"
export CXX="xlC_r -q64"
export CXXFLAGS="-O -qstrict"
export AR="ar -X64"
export F77="xlf_r -q64"
export CPPFLAGS="-I/afs/isis/pkg/libpng/include -I/usr/local/include -I$LIBICONV/include -I/usr/lpp/X11/include/X11"
export LDFLAGS="-L/usr/local/lib -L$LIBICONV/lib -L/usr/lib -L/usr/X11R6/lib -lc"

./configure --prefix=/afs/isis/pkg/grass-6.4.0 \
--enable-64bit \
--disable-shared \
--with-includes="/usr/include/fontconfig /usr/include/X11 /usr/include/X11/Xft /usr/include/X11/ext" \
--x-includes=/usr/include/X11 \
--x-libraries=/usr/X11R6/lib \
--with-fftw-includes=/afs/isis/pkg/fftw-3.2.2/include \
--with-fftw-libs=/afs/isis/pkg/fftw-3.2.2/lib \
--with-gdal=/afs/isis/pkg/gdal/bin/gdal-config \
--with-proj-includes=/afs/isis/pkg/proj/include \
--with-proj-libs=/afs/isis/pkg/proj/lib \
--with-proj-share=/afs/isis/pkg/proj/share/proj \
--with-tcltk-includes=/usr/local/include \
--with-tcltk-libs=/usr/local/lib \
--with-opengl-includes=/usr/include/GL
</pre>

==== MS-Windows ====

===== MS-Windows/Cygwin =====

... see [http://grass.itc.it/platforms/wingrass.html here] (should be moved to the Wiki)

===== MS-Windows/native =====

====== Compile ======

* [http://www.webalice.it/marco.pasetti/grass/BuildFromSource.html GRASS Windows Native Binary Building Guide] (GRASS 6.3.x)
* [http://trac.osgeo.org/grass/wiki/CompileOnWindows GRASS Windows Native Binary Building Guide] (GRASS 6.4.x)
* See/adapt [http://blog.qgis.org/node/124 idea] for unattended install of QGIS (et al) from [http://trac.osgeo.org/osgeo4w/ OSGeo4W] from the QuantumGIS Blog.

See also [[WinGRASS Current Status]] for latest updates.

=== Common problems and solutions ===

During compilation, error can occur if certain packages are not installed. Here a list of problems with solution:

* error: X11/Xlib.h: No such file or directory
** this suggests that you don't have the X headers installed
** Solution: Install the libx11-dev package

* error: g.list: error while loading shared libraries: libgdal1.6.0.so.1: cannot open shared object file: No such file or directory
** this error appears in the shell right after the user clicks GUI's "Start GRASS" button. The GUI shows an error about geographic extent and gets closed afterwards.
** It happens when you launch bin.i686 executable on 64bit system. Be careful and choose the right architecture.

=== Optimization ===

GCC and other compilers support [http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Optimize-Options.html#Optimize-Options optimization]

If you would like to set compiler optimisations, for a possibly faster binary, type (don't enter a ";" anywhere):

CFLAGS=-O ./configure
or,
setenv CFLAGS -O
./configure

whichever works on your shell. Use -O2 instead of -O if your compiler supports this (note: O is the letter, not zero). Using the "gcc" compiler, you can also specify processor specific flags (examples, please suggest better settings to us):

CFLAGS="-mcpu=athlon -O2" # AMD Athlon processor with code optimisations
CFLAGS="-march=amdfam10" # AMD Phenom II X4 64bit processor with gcc >=4.3
CFLAGS="-mcpu=pentium" # Intel Pentium processor
CFLAGS="-mcpu=pentium4" # Intel Pentium4 processor
CFLAGS="-O2 -msse -msse2 -mfpmath=sse -minline-all-stringops" # Intel XEON 64bit processor
CFLAGS="-mtune=nocona -m64 -minline-all-stringops" # Intel Pentium 64bit processor

To find out optional CFLAGS for your platform, enter:
gcc -dumpspecs

See also: http://gcc.gnu.org/

A real fast GRASS version (and small binaries) will be created with LDFLAGS set to "stripping" (but this disables debugging):

CFLAGS="-O2 -mcpu=<cpu_see_above> -Wall" LDFLAGS="-s" ./configure

=== Configure options and their meanings ===

For configure there are many options and some GRASS modules are built only if some options are set. Here are listed common configuration options with short explanation.

* --prefix=/path - Sets path where GRASS will be installed. GRASS will reside in /path/grass-version.
* --enable-largefile - Enables large (>2Gb on 32bit systems) support. For current large file support status look at [[Large File Support]] page.
* --with-cxx - Enables compilation of C++ code. Required for r.terraflow module.
* --with-readline - Enables readline support. If readline is enabled, you can use its history/editing facilities when entering r.mapcalc expressions on stdin.
* --with-glw - Enables GLw support. The GLw library provides OpenGL "canvas" widgets for Athena and Motif.

That switch is unnecessary for normal compilation. It's only
required for r3.showdspf, which isn't normally built; if you
want it, you have build it manually
(e.g. "make -C raster3d/r3.showdspf").
As similar functionality is now provided by NVIZ, r3.showdspf
is deprecated.
r3.showdspf uses the Motif widget (so you also need a
Motif library, e.g. Lesstif or OpenMotif).
[http://grass.itc.it/pipermail/grassuser/2006-December/037475.html Glynn Clements at GRASS-user mailing list]

=== Parallelized compilation on multi-core CPUs ===

You can dramatically accelerate the compilation of the GRASS code with the -j flag of "make" if you have a multi-core CPU system. This determines the maximum number of jobs to have running at once, so cores don't have to sit idle waiting for jobs on other cores to complete. A good rule of thumb for this value is <tt>number_of_cores * 1.5</tt>, but note that setting any higher than the actual number of cores will only affect the timing slightly. For example, on a dual-core processor:
make -j 4



== GRASS-GDAL plugin ==

* see [[Compile and install GRASS and QGIS with GDAL/OGR Plugin]]

== Addons ==

=== Compiled C modules ===

'''Requirements:'''

Either:
* a binary GRASS package, or
* source code which has been prepared with:
./configure [opionally flags]
make libs

Each of the [[GRASS_AddOns|addon]] modules should come with a Makefile. To compile it, just run:
make MODULE_TOPDIR=/path/to/grass64/

If using Bash it may be useful to set that up as an alias:
alias gmake64='make MODULE_TOPDIR=/path/to/grass64/'

Installation (perhaps requires "sudo"):
make MODULE_TOPDIR=/path/to/grass64/ install

Note: Compiled addons may require a re-compilation if you changed/updated your GRASS standard binaries.

==== If binary comes with a -dev package ====

''(work in progress, this text states how it eventually will be :)''
Nowadays one does not need to the source code, nor compiling GRASS by oneself to be able to add add-ons. On Debian, you can just install the grass-dev package and then run:
make MODULE_TOPDIR=/usr/lib/grass64/ INST_DIR=/usr/lib/grass64/

The grass-dev package essentially provides GRASS's <tt>include</tt> header files and Make configuration files.

=== Scripts ===

If the addon module is a script, it is sufficient to copy it into the (GRASS binaries) path somewhere. Alternatively, install addons into a separate GRASS addons binaries/scripts directory which is easier to maintain. It avoids getting clobbered every time you reinstall GRASS. To use these separately stored scripts, set and export the GRASS_ADDON_PATH environment variable before starting GRASS and it will automatically be added to the module search path (see the {{cmd|variables}} help page). To simplify this, do for example:

# add in $HOME/.bashrc:
GRASS_ADDON_PATH=/usr/local/grass/addons/
export GRASS_ADDON_PATH

Make sure that the script is executable, then just call it in GRASS typing the filename. Python scripts need to be called writing the extension as well, like:

GRASS 6.5.svn (spearfish60):~ > v.krige.py

[[Category:Development]]
[[Category:Documentation]]
[[Category:Installation]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

Atmospheric correction

2011-12-30T20:48:47Z

⚠️Reverse22:

See also the [[LANDSAT]] wiki page.

'''Aim of this tutorial:'''

* Transforming a Landsat ETM+ image from DN values to radiance values
* Conducting an atmospheric correction of a Landsat image using the {{cmd|i.atcorr}} module in GRASS GIS

== Introduction ==

The standard steps for processing satellite images are:

# Convert DN (digital number = pixel values) to ''Radiance at TOA'' (see formula below or use {{cmd|i.landsat.toar|version=65}}). {{cmd|i.landsat.toar|version=65}} supports all Landsat versions from MSS to TM to ETM+.
# Perform atmospheric correction (which converts Radiance at TOA -> ''Reflectance at surface''): done by {{cmd|i.atcorr}}.

''Note:'' Remember, to check if water areas are > 0, since reflectance is always positive. If negative, you have a "cornichon" (pickle in English ;-0). Means the transform equation inputs are not belong to image processed.

== Requirements ==

* GRASS 6.4.0 or higher
* North Carolina sample dataset (location): http://grass.osgeo.org/download/data.php

After downloading of the North Carolina dataset, it must be unzipped into your GIS database. When starting GRASS GIS, select this GIS database, open the ‘nc_spm_08’ dataset as LOCATION, and ‘PERMANENT’ as MAPSET.

== Calculating radiance values ==

The NC data set mapset contains, amongst others, a Landsat ETM+ image of 24th of May 2002. Every pixel of this image contains a DN or grey value. In order to be able to make calculations with satellite imagery, or compare values amongst different sensors, these values have to be converted to radiances or reflectances. The formulas to do this conversion are described here for Landsat images (or use [[GRASS_AddOns#i.landsat.toar|i.landsat.toar]]).
The conversion from DN values to top-of-atmosphere radiances is done as follows:


Lλ = ((LMAXλ - LMINλ)/(QCALMAX-QCALMIN)) * (QCAL-QCALMIN) + LMINλ

Where:

* Lλ - spectral Radiance at the sensor's aperture in watts/(meter squared * ster * μm), the apparent radiance as seen by the satellite sensor;
* QCAL - the quantized calibrated pixel value in DN;
* LMINλ - the spectral radiance that is scaled to QCALMIN in watts/(meter squared * ster * μm);
* LMAXλ - the spectral radiance that is scaled to QCALMAX in watts/(meter squared * ster * μm);
* QCALMIN - the minimum quantized calibrated pixel value (corresponding to LMINλ) in DN;
* QCALMAX - the maximum quantized calibrated pixel value (corresponding to LMAXλ) in DN=255.

LMINλ and LMAXλ are the radiances related to the minimal and maximal DN value, and are reported in the metadata file for each image, or in the table 1. High gain or low gain is also reported in the metadata file of each Landsat image. The minimal DN value (QCALMIN) is 1 for Landsat ETM+ images (1), and the maximal DN value (QCALMAX) is 255. QCAL is the DN value for every separate pixel in the Landsat image.

Accessing the metadata:

{{cmd|r.info}} lsat7_2002_xx

Under ‘comments’, the maximal and minimal radiance (LMAX and LMIN) for each band are given.

Power users may use this for nicely readable output (example for channel 1):

CHAN=1
{{cmd|r.info}} lsat7_2002_${CHAN}0 -h | tr '\n' ' ' | sed 's+ ++g' | tr ':' '\n' | grep "LMIN_BAND${CHAN}\|LMAX_BAND${CHAN}"

Conversion to radiance (this calculation is done for band 1, for the other bands, the numbers in italics need to be replaced with their correct values):

{{cmd|g.region}} rast=lsat7_2002_10 -p
{{cmd|r.mapcalc}} "lsat7_2002_10_rad=((''191.6'' - (''-6.2'')) / (255.0 - 1.0)) * (lsat7_2002_10 - 1.0) + (''-6.2'')"

For faster computations, use an integer DEM:

{{cmd|r.mapcalc}} "elev_int = round(elevation)"

Find mean elevation to initialize computations (needed in 'icnd' file below)

{{cmd|r.univar}} elev_int

== Estimating the overpass time from the sun position ==

The satellite overpass time can be estimated rather precisely from the sun position reported in metadata using {{cmd|r.sunmask}}:
The [ftp://ftp.glcf.umiacs.umd.edu/glcf/Landsat/WRS2/p016/r035/p016r035_7x20020524.ETM-EarthSat-Orthorectified/p016r035_7x20020524.met metadata] of this example report: SUN_AZIMUTH = 120.8810347, SUN_ELEVATION = 64.7730999

# iteratively change hour and minutes to obtain a good result, timezone needs to be correct of course:
{{cmd|r.sunmask}} -s elev=elevation out=dummy year=2002 month=5 day=24 hour=10 min=42 sec=7 timezone=-5

Reports: sun azimuth: 121.342461, sun angle above horz.(refraction corrected): 65.396652

The resulting overpass local time 10:42:07 corresponds to 15:42 in GMT which corresponds to 15.67 in decimal GMT hours (decimal minutes: 42 * 100 / 60). This value is needed for the control file.

== Atmospheric correction ==

This radiance image can be used for the atmospheric correction with the '''6S algorithm'''. The algorithm will transform the top-of-the-atmosphere radiance values to top-of-canopy reflectance values using predefined information on the aerosol content and atmospheric composition of the time the image was taken. What follows describes the method to use this algorithm in GRASS GIS. Again, only the calculations for band 1 are shown, and the numbers to be changed for the other bands are indicated in red. The 'icnd_lsat1.txt' control file consists of the following parameters, and is written with a text editor:

8 # indicates that it is an ETM+ image
05 24 15.67 -78.691 35.749 # image taken on the 24th of May, at 15:42 GMT in decimals; the center of the image lies at 78.691°W and 35.749°N
2 # the midlatitude summer atmospheric model
1 # the continental aerosol model
50 # the visibility for the aerosol model [km]
-0.110 # the terrain lies 110 meters above sea level [km] * -1
-1000 # image taken of a satellite sensor (1000)
61 # spectral band, here 1: blue

''TODO: understand if the [http://modis.gsfc.nasa.gov/data/dataprod/dataproducts.php?MOD_NUMBER=04 MODIS Aerosol Product (MOD04)] could be useful to estimate the visibility for the aerosol model.''

This file is then used in the {{cmd|i.atcorr}} module:

{{cmd|i.atcorr}} -a -o iimg=lsat7_2002_10_rad ialt=elev_int icnd=icdn_lsat1.txt oimg=lsat7_2002_10_atcorr

Where:
* <tt>-a</tt> refers to a Landsat image taken after July 2000
* <tt>-o</tt> activates the cache acceleration
* <tt>iimg</tt> is the image to be corrected
* <tt>ialt</tt> is the altitude map which overrides the initialization value of 110 meters
* <tt>icnd</tt> is the path to the icnd.txt file
* <tt>oimg</tt> is the name of the output image

More information on the use of {{cmd|i.atcorr}} for other images can be found in the {{cmd|i.atcorr}} manual.

== References ==

* [http://6s.ltdri.org 6S Web site]
* [http://modis-sr.ltdri.org/ Land Surface Reflectance Science Computing Facility website - 6S]
* (1) http://landsathandbook.gsfc.nasa.gov/handbook/handbook_htmls/chapter11/chapter11.html
* (2) http://landsat.usgs.gov/documents/L5TM_postcal_v11.pdf
* [http://www-air.larc.nasa.gov/tools/predict.htm NASA LaRC Satellite Overpass Predictor]

Adding new sensors:
* see http://trac.osgeo.org/grass/browser/grass/trunk/imagery/i.atcorr/README

[[Category: Documentation]]
[[Category: Tutorial]]
[[Category: Image processing]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

Archeology

2011-12-30T20:48:23Z

⚠️Reverse22:

GRASS GIS is used in many archaeological projects.

== Mailing list threads ==

* [http://thread.gmane.org/gmane.comp.gis.grass.user/27990 Who's using GRASS for archaeological applications?]

== Sample archeological data sets ==

* [http://www.tuarc.trentu.ca/~aspweb/en/downloads.shtml Antikythera Survey Project (ASP)]

== See also ==

* Barton, C.M., Ullah, I. & Mitasova, H., 2010. ''Computational modeling and neolithic socioecological dynamics: A case study from southwest Asia''. Am antiquity, 75(2), 364-386. [ [http://sagunto.la.asu.edu:8080/medlandweb/Barton_etal2010.pdf PDF] ]
* M. Neteler, 2009: ''[http://www.slideshare.net/markusN/grass-and-osgeo-a-framework-for-archeology GRASS GIS and OSGeo: A framework for archeology]'' (Invited keynote). Quarto Workshop Italiano [http://www.archeo-foss.org/ "Open Source, Free Software e Open Format nei processi di ricerca archeologica"], CNR di Roma, 27-28 April 2009
* Conolly, J., Lake, M., 2006. Geographical Information Systems in Archaeology (Cambridge Manuals in Archaeology) [ [http://www.amazon.co.uk/Geographical-Information-Systems-Archaeology-Cambridge/dp/0521797446/ Book] ]
* A. Bezzi, L. Bezzi, D. Francisci, R. Gietl, 2006. ''L'utilizzo di Voxel in campo archeologico'', Geomatics workbooks 6 [ [http://geomatica.como.polimi.it/workbooks/n6/list.php PDF] ]

== Some archaeological links related to GRASS ==

* http://wiki.iosa.it/ Quantitative Archaeology Wiki (check out the "Spatial Analysis" section)
* http://arc-team-open-research.blogspot.com/ - GRASS and Blender in archaeology
* http://arkygeek.blogspot.com/
* http://www.arc-team.com/wiki/doku.php - ArcheOS - The first GNU/Linux distribution for archaeology ([http://www.arc-team.com/archeos/wiki/doku.php?id=screenshots screenshots])
* [http://undine-lieberwirth.info/?page_id=8 Voxels and GRASS] in Archeology (animations)
* http://tdx.cat/TESIS_UB/AVAILABLE/TDX-0720109-092434/ - PhD Dissertation about conflict archaeology, with extensive use of GRASS and QGIS.

[[Category:Applications]]
[[Category:Documentation]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

[http://www.prlog.org/11289974-phone-number-lookup-verizon-phone-number-reverse-lookup-to-get-information-you-need-quickly.html phone number lookup]

GRASS-Wiki

2011-12-30T20:48:02Z

⚠️Reverse22:

__NOTOC__
{| width="100%"
|-
| width="68%" style="vertical-align:top" |
<div style="margin:0; margin-right:10px; border:1px solid #dfdfdf; background-color:#f8f8ff;">

<div style="padding:0.3em 1em 0.7em 1em;">

[[Image:grasslogo_vector_small.png|right|link=http://grass.osgeo.org]]

=== Welcome to the GRASS GIS Users Wiki ===

{{website|intro/general.php|'''GRASS GIS'''}} is a [http://en.wikipedia.org/wiki/Geographic_information_system Geographic Information System] used for geospatial data management and analysis, image processing, graphics/map production, spatial modeling, and visualization.

On this Wiki, you can get and contribute to GRASS related information, documents and community provided add-ons programs. To edit here, you need to register and login first (see top right link).

For GRASS at a glance, see [[Core features]]. For usage examples, see the [http://grass.osgeo.org/screenshots/index.php screenshots gallery] and [[Applications]].
</div>
</div>

<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0em 1em 1em 1em; background-color:#FFE5E5;">
'''What's hot:'''
* [http://grass.osgeo.org/download/ '''GRASS 6.4.2RC2''' available for testing - get it now!]
* Then try the [[Quick wxGUI tutorial]]
* Temporal support and other new [[Initiatives]]
* [http://www.osgeo.org/node/1069 Helena Mitasova Receives Sol Katz Award 2010]
</div>

<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0em 1em 1em 1em; background-color:#f8f8ff;">
==== User Documentation and Support ====
* [[GRASS Help|GRASS Help and Getting Started]]
* [[GRASS Documents|In depth GRASS Documentation]]
* [[Installation Guide]] for precompiled binaries
* '''[[Faq|FAQ]] - Frequently Asked Questions'''
* [[Applications]] - use cases of GRASS in various disciplines
* [[wxGUI]] - Graphical User Interface based on wxPython
</div>

<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0em 1em 1em 1em; background-color:#f8f8ff;">

==== Community ====
* [[GRASS Community]]: Getting in touch
* [[Applications|Research applications]]: What people are doing with GRASS
* [[GRASS migration hints|Migrating to GRASS]]
* [[GRASS Blogger]]
* Get involved: [[Project jobs]]
* [http://grass.osgeo.org/wiki/Special:Recentchanges?feed=rss RSS feed] of recent changes of this Wiki
</div>

<div>Have a look at the GRASS GIS users worldwide [http://grass.osgeo.org/community/ GRASS GIS User Online]. If you operate a GRASS GIS installation, you are welcome to enter your user data there.
</div>

<div><p>''[[GRASS-Wiki:Language policy|Translate this Wiki]]''</p></div>


| width="38%" style="vertical-align:top" |
<div style="margin:0; border:1px solid #dfdfdf; padding:0em 1em 1em 1em; background-color:#f8f8ff;">
[[Image:OSGeo 220pix.png|center|220px|link=http://www.osgeo.org]]
<center>OSGeo Foundation Project</center>
</div>

<div style="margin:0; margin-top:10px; border:1px solid #dfdfdf; padding:1em 1em 1em 1em; background-color:#f8f8ff;">
[[Image:Btn_donate_SM.gif|center|link=http://grass.osgeo.org/donation.php]]<center>[http://grass.osgeo.org/donation.php Donate via PayPal.com]</center>
</div>

<div style="margin:0; margin-top:10px; border:1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#f8f8ff;">
* [http://grass.osgeo.org/screenshots/index.php GRASS Screenshots]
* [http://trac.osgeo.org SVN/trac] Source Code Repository
* [http://grass.osgeo.org/community/support.php Mailing lists] and [http://grass.osgeo.org/community/support.php#irc IRC]
* [http://trac.osgeo.org/grass/ Report errors or wishes]
* [https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4/COPYING Licensed under GNU GPL]
</div>

<div style="margin:0; margin-top:10px; border:1px solid #dfdfdf; padding:0em 1em 1em 1em; background-color:#f8f8ff;">

==== Download ====
* [http://grass.osgeo.org/download/ Source code and binaries]
* '''[[GRASS AddOns]]'''
* [[Promotional material]]
* [[Sample datasets]]
* [[Global datasets]]
</div>

<div style="margin:0; margin-top:10px; border:1px solid #dfdfdf; padding:0em 1em 1em 1em; background-color:#f8f8ff;">

==== Development ====
* [[Compile and Install]] of Source Code
* [[Development|GRASS Development]] intro
* [http://trac.osgeo.org/grass/wiki GRASS-trac]: the development Wiki, bugtracker, source code browser
* [[Release Roadmap]]
* [[GRASS 7 ideas collection]]
* [[GRASS SoC Ideas|Google Summer of Code ideas collection]]
* [http://trac.osgeo.org/grass/wiki/HowToContribute How to contribute to GRASS development] (getting write access and such)
</div>

<div style="margin:0; margin-top:10px; border:1px solid #dfdfdf; padding:0em 1em 1em 1em; background-color:#f8f8ff;">
Project Metrics provided by [http://www.ohloh.net/projects/3666 Ohloh].

{{#widget:Ohloh Project|id=3666|type=partner_badge}}
</div>
|}

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

[http://www.prlog.org/11289974-phone-number-lookup-verizon-phone-number-reverse-lookup-to-get-information-you-need-quickly.html phone number lookup]

Agriculture and HPC

2011-12-30T20:41:23Z

⚠️Reverse22:

=== Introduction ===
Agricultural activity monitoring, e.g. enclosed quantifying the irrigation scheduling, tracing the soil hydraulic properties, generating the crop calendar etc., is necessary for efficient food security management at country level. The near real time monitoring or prediction on crop parameters such as crop growth in terms of planting date, date of emergence, extents, acreage, planting intensity, water stress, biomass, yield and etc. is important. It can contribute to better policymaking, timely countermeasures, optimization of water resources distributions, damage assessment and finally to supply food security and stable market. Researchers of agriculture also try to analyze various information about crops in order to take measures if they had some problems. Particularly, when an on-going experiment covers large area such as a country, satellite imagery plays a vital role by providing useful information over large/provincial area. However, some information, or crop parameters, is not visible through satellite images such as sowing dates, cropping intensity, growth, stress etc., which reflects a practical problem that we can not generate or observe those parameters from remote places. To collect those data, time by time basis field experiments are required. This is a time consuming, complex and expensive procedure. To overcome such problems, crop or simulation models can help. Usually, crop models calculate those missing information by analyzing the crop information with real fields' experiment data. Indirect methods such as inverse modeling with crop model can be used to obtain those basic input parameters. One such method is the manual calibration by "trial and error" procedure, which is very subjective and time consuming, and uncertainty associated with them can not be quantified. A more robust way of inverse modeling is to combine the model and assimilate data with optimization algorithm.

Thus, the challenge for the future is to obtain besides the more direct observable data (land cover, leaf area index, digital elevation model and evapotranspiration), non-visible data (soil characteristics, groundwater depth and irrigation practices) from satellite images.

=== Crop Assimilation Model (CAM) ===
Crop models, Soil-Water-Air-Plant (SWAP)<ref> [http://www.wiz.uni-kassel.de/model_db/mdb/swap.html Soil Water Atmosphere Plant-General Model Information]</ref> or Decision Support System for Agrotechnology Transfer (DSSAT) <ref>[http://www.icasa.net/dssat/ ICASA DSSAT software Introduction]</ref>, have capacity to simulate soil, water and crop processes and serve as crop productivity monitoring tool. Crop Assimilation Model (CAM) predicts parameters of crop models with satelite images. A new methodology was developed in <ref>[http://www.hydrol-earth-syst-sci.net/6/49/2002/hess-6-49-2002.html Inverse modelling in estimating soil hydraulic functions: a Genetic Algorithm approach]</ref>, CAM-GA, to analyze the crop model (SWAP) parameters assimilation with Remote Sensing (RS) data and that parameters assimilation procedure was optimized by an evolutionary searching technique called Genetic Algorithm (GA). Due to the changing in input parameters of SWAP model for pixel-to-pixel basis, the assimilation search space is very large. Evolutionary search algorithms are performing well in such conditions. Similar works in <ref>[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6VCF-4FPJBB4-1&_user=126251&_rdoc=1&_fmt=&_orig=search&_sort=d&_docanchor=&view=c&_searchStrId=1016133229&_rerunOrigin=google&_acct=C000010218&_version=1&_urlVersion=0&_userid=126251&md5=93a7735a8b4bcbfc2bea9cde9bf4e66a On quantifying agricultural and water management practices from low spatial resolution RS data using genetic algorithms: A numerical study for mixed-pixel environment]</ref> and <ref>[http://www.aars-acrs.org/acrs/proceeding/ACRS2004/Papers/DF204-6.htm SWAP crop model Parameter Identification using SPOT Vegetation in Suphanburi, Thailand]</ref> used some remotely sensed information combined with a binary GA <ref>[http://www.amazon.com/reader/3540606769?_encoding=UTF8&ref_=sib%5Fdp%5Fpt#reader-link]</ref> and SWAP model for optimizing soil hydraulic parameters. CAM with double layers GA, CAM-DLGA <ref>[http://www.freewebs.com/ychemin/2006_IEEE_TGRS_chemin_honda.pdf Spatiotemporal Fusion of Rice Actual Evapotranspiration With Genetic Algorithms and an Agrohydrological Model]</ref>, uses directly visible multi-resolution RS images (ASTER <ref>[http://asterweb.jpl.nasa.gov/ Advanced Spaceborne Thermal Emission and Reflection Radiometer]</ref>, MODIS <ref>[http://modis.gsfc.nasa.gov/ Moderate Resolution Imaging Spectroradiometer]</ref>) and inversely assimilates to SWAP model data for estimating the non-visible model parameters. One of the advantages of the GA is that they operate well even in domains, where little information is known. However, the main difficulty on GA is to decide an appropriate set of parameters, such as population size, number of generation, selection rate, crossover probability, and mutation probability. Other models, e.g., CAM-PSO <ref>[http://www.igarss08.org/Abstracts/pdfs/2357.pdf Combining remote sensing maeasurements and model estimates through hybrid data assimilation scheme to predict hydrological fluxes at a watershed scale]</ref> and CAM-PEST <ref>[http://www.itc.nl/library/papers_2003/msc/wrem/minur_dorji.pdf]</ref>, use different evolutionary searching technique. They were developed and provided the similar functionality as CAM-GA. However, processing the agricultural information with CAM has a problem in practicality, that is, they require a huge amount of processing times. It becomes necessary to introduce methods for using higher processing power such as High Performance Computing (HPC) technologies.

=== Rationale ===
Multi computer based distributed systems (clusters and Grids) have a large processing capacity for a lower cost, naturally, choice turns towards developing HPC applications. However, it is not an easy job to port CAM in HPC environment. The application performance is significantly affected by the data distribution and task distribution methods on the HPC, and developers of agriculture or satellite image processing applications need to solve the problem of both data and task distribution, or how to distribute data and tasks among single or multiple clusters environment. The workload in HPC, the bandwidth, the processors speed, parameters of evaluation methods and data size are additional concerning factors. Moreover, interoperability between the agriculture application and existing RS image processing software is also necessary to improve practicality. However, users need to manually extract satellite data from some databases in the existing CAM works. Some researches separately focused on the agricultural models activities or satellite image processing performance on HPC and a few of them are in the merging domains with satellite image processing, agriculture and HPC. Still, the merging domain researches are mainly in hypothetical or conjectural theme rather than practical implementation. Thus, agricultural researchers require a web based system or tool for the agricultural activity monitoring so that they do not need to concern about the implementation issues for agricultural models or RS image processing on HPC.

=== Research Objectives ===
Thus, the main focus of the research is to propose a new software system to support agriculture activities using both Remote Sensing (RS) and HPC. Processing satellite images automatically through HPC, CAM HPC implementation with appropriate data and task distribution schemes, web portal system on HPC are the vital sectors for modeling the overall distributed agriculture monitoring scheme and require individual experiments. Therefore, the research question is "Does the HPC system help to improve the performance in each sector separately?". In this study, the performance in HPC system for each sector is successfully examined and experimented with different targeted applications. The applications are being implemented first time in HPC platform and their performance results are quite impressive and acceptable.

GRASS GIS (Geographical Resources Analysis Support System) is a free, open source software/tool and has been used for RS and GIS data analysis and visualization. GRASS module [[r.vi]] is used as a test example for experimenting on HPC ([[r.vi.mpi]], [[r.vi.grid]]) <ref>[http://www.osgeo.org/ojs/index.php/journal/article/view/93 Porting a GRASS raster module to distributed computing Examples for MPI and Ninf-G]</ref>. Moreover, temporally splined procedure such as Local Maximum Fitting (LMF) processing methodology is improved to reduce the processing time by combining the parallelization of data and task distribution together on multi-cluster Grids<ref>[http://j-geoinfo.net/Content/Dec2008/p02.html Asynchronous Grid LMF Processing of Vegetation Index for Asia]</ref>. CAM-GA, is implemented in grid testbed and the impact on the performance of parallelization methods is discussed. Additionally, a new CAM called CAM-PLDLGA is proposed and implemented <ref>[http://www.alab.ip.titech.ac.jp/papers/shamim-ICCSA-Jul2009.pdf Parameter-Less GA Based Crop Parameter Assimilation with Satellite Image]</ref>. A CAM-GA web interface with MapServer and PHPMapscripts is implemented. Thereafter, an implementation methodology with Python based Web Processing Service (PyWPS), Embrio Interface and MapServer are discussed for future extension.

'''Shamim Akhter,18-9-2009'''

P.S: The complete research, ''Study on High Performance Computing of Crop Parameter Identification with The Grid, PhD dissertation, 2009, Information Processing,Tokyo Institute of Technology'', will be sent upon mail request to Shamim Akhter (shamimakhter@gmail.com).

=== References ===
<references/>

[[Category:Applications]]

==Other==
[http://thetvtopc.com/Reverse_Cell_Phone_Lookup_Number reverse phone lookup]

[http://www.prlog.org/11289974-phone-number-lookup-verizon-phone-number-reverse-lookup-to-get-information-you-need-quickly.html phone number lookup]