GRASS-Wiki - User contributions [en]

Community Sprint Funding

2016-02-17T17:49:27Z

⚠️Smitch: /* Procedure to request Community Sprint funding */ small edits for extra explanation

== Procedure to request Community Sprint funding ==

# Open this page in editing mode to '''copy''' the template part below into a new Wiki "discussion" page using a name scheme something like this example: [[GRASS GIS contributors meetings in Solany/February 2016]].
# Remember: don't edit here but create a new Wiki page. Store the template into the related "Discussion" page first, by copying from the source of this page, then pasting in the new page, and then filling in the details.
# Send the URL of the new page to the [http://lists.osgeo.org/mailman/listinfo/grass-psc GRASS-PSC mailing list] (requires subscription to post there). Do that at least 2 weeks before the meeting starts.
# The PSC will decide about funding or no/partial funding within one week.

Below is a template for Community Sprint funding request ('''DO NOT EDIT THIS PAGE''').

Confused? See this example:
* Request for funding: [[Talk:GRASS GIS contributors meetings in Solany/February 2016]]
* Report: [[GRASS GIS contributors meetings in Solany/February 2016]].

''(template below)''

== Name of Meeting/Place ==
=== What is to be funded? ===
=== How many participants are expected? ===
=== How to fund? (financially, with material resources, in-kind ...) ===
=== How much money is needed? ===

(Please add a simple table here; you can convert from LibreOffice or Excel to Wiki here: http://excel2wiki.net/index.php) or adapt the table below:

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Community Sprint cost estimate'''
| align="center" style="background:#f0f0f0;"|'''Euro'''
|-
| Reimbursements for participants || 0
|-
| Public Transport || 0
|-
| Promo (T-Shirts + stickers) || 0
|-
| Office stuff || 0
|-
| Small food + Drinks || 0
|-
| align="center" style="background:#f0f0f0;" | '''TOTAL COST''' || '''0'''
|-
|}

=== What relationship has the proposed project to GRASS GIS? ===
=== Is the event additionally sponsored by others? ===
=== What are the consequences of funding / non-funding? ===
=== What kind of documentation / reporting will be delivered after the event? ===
=== Contact info ===
=== Mail to PSC mailing list sent? ===
=== Decision taken ===
=== Report after the event ===

= Comments from community =

[[Category: Workshops]]
[[Category: Code Sprint]]

Community Sprint Funding

2016-02-17T17:44:14Z

⚠️Smitch: small grammar fixes

== Procedure to request Community Sprint funding ==

# Open this page in editing mode to '''copy''' the template part below into a new Wiki "discussion" page with the name scheme like this example [[GRASS GIS contributors meetings in Solany/February 2016]].
# Remember: don't edit here but create a new Wiki page. Store the template into the related "Discussion" page first and fill it.
# Send the URL to the [http://lists.osgeo.org/mailman/listinfo/grass-psc GRASS-PSC mailing list] (requires subscription to post there). Do that at least 2 weeks before the meeting starts.
# The PSC will decide about funding or no/partial funding within one week.

Below is a template for Community Sprint funding request ('''DO NOT EDIT THIS PAGE''').

Confused? See this example:
* Request for funding: [[Talk:GRASS GIS contributors meetings in Solany/February 2016]]
* Report: [[GRASS GIS contributors meetings in Solany/February 2016]].

''(template below)''

== Name of Meeting/Place ==
=== What is to be funded? ===
=== How many participants are expected? ===
=== How to fund? (financially, with material resources, in-kind ...) ===
=== How much money is needed? ===

(Please add a simple table here; you can convert from LibreOffice or Excel to Wiki here: http://excel2wiki.net/index.php) or adapt the table below:

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Community Sprint cost estimate'''
| align="center" style="background:#f0f0f0;"|'''Euro'''
|-
| Reimbursements for participants || 0
|-
| Public Transport || 0
|-
| Promo (T-Shirts + stickers) || 0
|-
| Office stuff || 0
|-
| Small food + Drinks || 0
|-
| align="center" style="background:#f0f0f0;" | '''TOTAL COST''' || '''0'''
|-
|}

=== What relationship has the proposed project to GRASS GIS? ===
=== Is the event additionally sponsored by others? ===
=== What are the consequences of funding / non-funding? ===
=== What kind of documentation / reporting will be delivered after the event? ===
=== Contact info ===
=== Mail to PSC mailing list sent? ===
=== Decision taken ===
=== Report after the event ===

= Comments from community =

[[Category: Workshops]]
[[Category: Code Sprint]]

Compile and Install

2011-07-07T15:27:31Z

⚠️Smitch:

{{MoveToTrac}}
== 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://proj.maptools.org PROJ4] for management of projections (with proj-datumgrid-1.3.zip support)
* Optional: [http://geos.refractions.net 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 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 \
libmysqlclient-dev graphviz libsqlite3-dev python-wxgtk2.8 libcairo2-dev libwxgtk2.8-dev \
python-dev swig libgdal1-dev libgdal1-1.6.0 libproj-dev proj-bin libglw1-mesa-dev \
mysql-client-5.1 mysql-server-5.1 libpq-dev subversion gcc lesstif2-dev \
zlib1g-dev libproj-dev libtiff4-dev mesa-common-dev libglu1-mesa-dev libcairo2-dev \
g++ wx-common python-wxgtk2.8 libwxgtk2.8-dev libxt-dev libxmu-headers gettext python-numpy

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-postgres --with-postgres-includes=/usr/include/postgresql \
--with-mysql --with-mysql-includes=/usr/include/mysql \
--with-gdal --with-proj --with-proj-share=/usr/share \
--with-motif --with-glw --with-nls --with-readline \
--with-cxx --enable-largefile \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--with-sqlite \
--with-odbc --with-cairo --with-python=/usr/bin/python2.6-config --with-wxwidgets \
--with-tcltk-includes=/usr/include/tcl8.5 --with-tcltk-libs=/usr/lib/tcl8.5 \
--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 =====

This is an example how to compile GRASS on a 64bit Fedora system:

./configure \
--enable-64bit \
--with-cxx \
--with-libs=/usr/lib64 \
--with-gdal=/usr/bin/gdal-config \
--with-proj-share=/usr/share/proj \
--without-odbc \
--with-sqlite \
--with-nls \
--without-tcltk \
--with-python=/usr/bin/python-config \
--without-cairo \
--without-opengl \
--with-wxwidgets=/usr/bin/wx-config \
--with-fftw \
--with-blas \
--with-lapack \
--without-freetype \
--enable-largefile \
--with-x \
--x-includes=/usr/include/X11/

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]]

==== 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



== Addons ==

=== GRASS-GDAL plugin ===

* see [[Compile and install GRASS and QGIS with GDAL/OGR Plugin]]

=== 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]]

Citing GRASS

2009-08-31T15:22:05Z

⚠️Smitch: Apparently people aren't finding the citation info, so make a link in the FAQ

Example citations for GRASS are given at the bottom of the downloads page, here: http://grass.osgeo.org/download/index.php#citing
[[Category:FAQ]]

GRASS Project Incubation

2007-04-18T18:49:11Z

⚠️Smitch: /* Project Incubation at the OSGeo Foundation */

==Project Incubation at the OSGeo Foundation==

Each project proposed to go into the OSGeo Foundation has to go
through an incubation process (see http://www.osgeo.org/incubator/).

This is a process derived from the Apache Foundation with some
modifications. It basically covers license issues, a contributor
agreement, project management and the state of the
community (no dead projects are desired). Some draft
notes can be found here:

http://wiki.osgeo.org/index.php/IncCom_Wiki

The basic role of the incubator is to do various sorts of review of
projects as they join the foundation. This includes IP review (is
all the code cleanly under an OS license?), arranging setup or
approval of a project steering committee with appropriate governance,
and ensuring that committers sign appropriate contributor agreements
(see below).

Some information on the Incubation Committee can be found at:

http://www.osgeo.org/incubator/

At the Feb 27, 2006 (?) OSGEO board meeting it was decided that all founding projects
would go through the incubation process, not just new projects added in the
future. To that end, that the incubation committee needs one official
representative on the incubation committee from each of the eight founding
projects.

One of the first items of discussion for incubation is the Committer
Agreements. These are legal documents that anyone with CVS/SVN commit
access may sign (will become optional). Basically they provide the foundation the right to
redistribute the provided code, and to defend the code in case of litigation.
But it does require the committer and possibly their employer to agree that
they have the right to provide code they are committing to the project.

The board has reviewed a proposed committer agreement based loosely on
the Apache committer agreement. Now the incubation committee is looking for
broader feedback on it the agreements. Of most interest is feedback from
significant code contributors. The draft agreements and a FAQ are available at:

http://wiki.osgeo.org/index.php/Contributor_Agreement

Feedback may be sent to OSGeo discuss mailing list, or to the incubation committee via project representatives there.

A questionaire was answered here: http://wiki.osgeo.org/index.php/GRASS_Incubation_Progress

'''Update'''

The Contributor Agreement is no longer a requirement.

RFC1

2007-04-07T18:51:25Z

⚠️Smitch: /* Operation of the PSC */

== RFC 1: Project Steering Committee Guidelines ==
: '''Author:''' GRASS Founding PSC
: '''Status:''' Adopted

A GRASS Project Steering Committee ([[PSC]]) is proposed to formalize control
over the GRASS codebase and to facilitate GRASS project management issues.
It is desired to keep the administrative overhead as low as possible.

This document describes how the GRASS Project Steering Committee
determines membership and makes decisions on GRASS project issues.

"The GRASS Project" is defined as the GPL-licenced GIS software known as the
Geographic Resources Analysis Support System, together with the surrounding
development, distribution and promotion infrastructure currently headquarted
at FBK-irst (formerly ITC-irst), Trento, Italy.

= Terms of Reference =

The two primary functions of the PSC are:

1) To enforce control over the GRASS codebase. This can be summarised as:
: a) Enforce mechanisms to ensure quality control.
: b) Ensure compliance with all required legal measures.
2) Project Management and responsibility for the "public face" of GRASS.
The PSC is expected to be able to speak and act on behalf of the GRASS
project.

== Codebase Control ==

=== Quality Control Mechanisms ===

The quality control mechanisms, which are the responsibility of the PSC,
currently include:
* Maintaining submitter guidelines and making all developers aware of them.
* Granting write access to the source code repository for new developers.
* Enforcing the submitter guidelines, with the ultimate sanction against non-compliance being removal of write access to the source code repository.

In general, once write access has been granted, developers are allowed to make changes to the codebase as they see fit. For controversial or complicated changes consensus must be obtained on the developers' mailing list as far as reasonably practicable. It is recognised that the ultimate
arbitration on technical issues always lies with consensus on the developers' mailing list. Specifically, it is not the role of the PSC to impose technical solutions. Its role is limited to enforcing the quality control mechanisms outlined above.

However, if consensus fails to emerge naturally, an issue can be referred to the PSC for more structured efforts to build consensus. As a last resort, if lack of consensus continues, the developer community can request the PSC to choose options best preserving the quality of the GRASS project.

Removal of write access to the source code repository is handled as a proposal to the committee as described below in the \ref operation section.

=== Compliance with Legal Measures ===

Control over the codebase also extends to ensuring that it complies with
all relevant legal requirements. This includes copyright and licensing
amongst other issues. The PSC is resonsible for developing rules and
procedures to cover this. These are outlined in a separate document [http://mpa.itc.it/markus/grass63progman/rfc/rfc2_psc.html RFC 2: Legal aspects of code contributions]. This document will be updated and
revised by the PSC as required.

== Project Management ==

The PSC will share responsibility and make decisions over issues related
to the management of the overall direction of the GRASS project and
external visibility, etc. These include, but are not limited to:
* Release Cycles
* Project infrastructure
* Website Maintenance
* Promotion and Public Relations
* Other issues as they become relevant

It is the responsibility of the PSC to ensure that issues critical to the
future of the GRASS project are adequately attended to. This may involve
delegation to interested helpers.

= Operation of the PSC =

A dedicated [http://grass.itc.it/mailman/listinfo/grass-psc Mailing List] exists for the purpose of PSC discussions. When a
decision is required of the PSC, it will be presented by any member to the
mailing list in the form of a proposal. A decision will then be achieved
by discussion of the proposal on the mailing list until a consensus is
reached. Voting on issues is also permissable and may be used as a means
to reach a consensus or, only in case of extreme cases of disagreement, to
force a decision. The [[PSC Agenda]] lists all open motions.
Any member may call a vote on any proposal. The voting procedure is outlined in a separate document, [http://mpa.itc.it/markus/grass63progman/rfc/rfc3_psc.html RFC3 - PSC Voting Procedures].

The Chair is the ultimate adjudicator in case of deadlock or irretrievable
break down of decision-making, or in case of disputes over voting.

The following issue(s) *must* have a vote called before a decision is reached:
* Granting source code repository write access for new developers
* Selection of a committee Chair

= Composition of the Committee =

Initial PSC membership was decided based on a nomination and informal voting
period on the community's mailing lists. Michael Barton, Dylan Beaudette,
Hamish Bowman, Massimiliano Cannata, Brad Douglas, Paul Kelly, Helena Mitasova,
Scott Mitchell, Markus Neteler, and Maciej Sieczka are declared to be the
founding Project Steering Committee.

Addition and removal of members from the committee, as well as selection
of Chair is handled as a proposal to the committee as described above.

The Chair is responsible for keeping track of the [[PSC | membership of the PSC]].

[[Category: PSC]]

RFC1

2007-04-07T18:50:33Z

⚠️Smitch: /* Compliance with Legal Measures */

== RFC 1: Project Steering Committee Guidelines ==
: '''Author:''' GRASS Founding PSC
: '''Status:''' Adopted

A GRASS Project Steering Committee ([[PSC]]) is proposed to formalize control
over the GRASS codebase and to facilitate GRASS project management issues.
It is desired to keep the administrative overhead as low as possible.

This document describes how the GRASS Project Steering Committee
determines membership and makes decisions on GRASS project issues.

"The GRASS Project" is defined as the GPL-licenced GIS software known as the
Geographic Resources Analysis Support System, together with the surrounding
development, distribution and promotion infrastructure currently headquarted
at FBK-irst (formerly ITC-irst), Trento, Italy.

= Terms of Reference =

The two primary functions of the PSC are:

1) To enforce control over the GRASS codebase. This can be summarised as:
: a) Enforce mechanisms to ensure quality control.
: b) Ensure compliance with all required legal measures.
2) Project Management and responsibility for the "public face" of GRASS.
The PSC is expected to be able to speak and act on behalf of the GRASS
project.

== Codebase Control ==

=== Quality Control Mechanisms ===

The quality control mechanisms, which are the responsibility of the PSC,
currently include:
* Maintaining submitter guidelines and making all developers aware of them.
* Granting write access to the source code repository for new developers.
* Enforcing the submitter guidelines, with the ultimate sanction against non-compliance being removal of write access to the source code repository.

In general, once write access has been granted, developers are allowed to make changes to the codebase as they see fit. For controversial or complicated changes consensus must be obtained on the developers' mailing list as far as reasonably practicable. It is recognised that the ultimate
arbitration on technical issues always lies with consensus on the developers' mailing list. Specifically, it is not the role of the PSC to impose technical solutions. Its role is limited to enforcing the quality control mechanisms outlined above.

However, if consensus fails to emerge naturally, an issue can be referred to the PSC for more structured efforts to build consensus. As a last resort, if lack of consensus continues, the developer community can request the PSC to choose options best preserving the quality of the GRASS project.

Removal of write access to the source code repository is handled as a proposal to the committee as described below in the \ref operation section.

=== Compliance with Legal Measures ===

Control over the codebase also extends to ensuring that it complies with
all relevant legal requirements. This includes copyright and licensing
amongst other issues. The PSC is resonsible for developing rules and
procedures to cover this. These are outlined in a separate document [http://mpa.itc.it/markus/grass63progman/rfc/rfc2_psc.html RFC 2: Legal aspects of code contributions]. This document will be updated and
revised by the PSC as required.

== Project Management ==

The PSC will share responsibility and make decisions over issues related
to the management of the overall direction of the GRASS project and
external visibility, etc. These include, but are not limited to:
* Release Cycles
* Project infrastructure
* Website Maintenance
* Promotion and Public Relations
* Other issues as they become relevant

It is the responsibility of the PSC to ensure that issues critical to the
future of the GRASS project are adequately attended to. This may involve
delegation to interested helpers.

= Operation of the PSC =

A dedicated [http://grass.itc.it/mailman/listinfo/grass-psc Mailing List] exists for the purpose of PSC discussions. When a
decision is required of the PSC, it will be presented by any member to the
mailing list in the form of a proposal. A decision will then be achieved
by discussion of the proposal on the mailing list until a consensus is
reached. Voting on issues is also permissable and may be used as a means
to reach a consensus or, only in case of extreme cases of disagreement, to
force a decision. The [[PSC Agenda]] lists all open motions.
Any member may call a vote on any proposal. The voting procedure is outlined in a separate document, [[RFC3 | RFC3 - PSC Voting Procedures]].

The Chair is the ultimate adjudicator in case of deadlock or irretrievable
break down of decision-making, or in case of disputes over voting.

The following issue(s) *must* have a vote called before a decision is reached:
* Granting source code repository write access for new developers
* Selection of a committee Chair

= Composition of the Committee =

Initial PSC membership was decided based on a nomination and informal voting
period on the community's mailing lists. Michael Barton, Dylan Beaudette,
Hamish Bowman, Massimiliano Cannata, Brad Douglas, Paul Kelly, Helena Mitasova,
Scott Mitchell, Markus Neteler, and Maciej Sieczka are declared to be the
founding Project Steering Committee.

Addition and removal of members from the committee, as well as selection
of Chair is handled as a proposal to the committee as described above.

The Chair is responsible for keeping track of the [[PSC | membership of the PSC]].

[[Category: PSC]]

RFC1

2007-04-07T18:41:08Z

⚠️Smitch: /* Compliance with Legal Measures */

== RFC 1: Project Steering Committee Guidelines ==
: '''Author:''' GRASS Founding PSC
: '''Status:''' Adopted

A GRASS Project Steering Committee ([[PSC]]) is proposed to formalize control
over the GRASS codebase and to facilitate GRASS project management issues.
It is desired to keep the administrative overhead as low as possible.

This document describes how the GRASS Project Steering Committee
determines membership and makes decisions on GRASS project issues.

"The GRASS Project" is defined as the GPL-licenced GIS software known as the
Geographic Resources Analysis Support System, together with the surrounding
development, distribution and promotion infrastructure currently headquarted
at FBK-irst (formerly ITC-irst), Trento, Italy.

= Terms of Reference =

The two primary functions of the PSC are:

1) To enforce control over the GRASS codebase. This can be summarised as:
: a) Enforce mechanisms to ensure quality control.
: b) Ensure compliance with all required legal measures.
2) Project Management and responsibility for the "public face" of GRASS.
The PSC is expected to be able to speak and act on behalf of the GRASS
project.

== Codebase Control ==

=== Quality Control Mechanisms ===

The quality control mechanisms, which are the responsibility of the PSC,
currently include:
* Maintaining submitter guidelines and making all developers aware of them.
* Granting write access to the source code repository for new developers.
* Enforcing the submitter guidelines, with the ultimate sanction against non-compliance being removal of write access to the source code repository.

In general, once write access has been granted, developers are allowed to make changes to the codebase as they see fit. For controversial or complicated changes consensus must be obtained on the developers' mailing list as far as reasonably practicable. It is recognised that the ultimate
arbitration on technical issues always lies with consensus on the developers' mailing list. Specifically, it is not the role of the PSC to impose technical solutions. Its role is limited to enforcing the quality control mechanisms outlined above.

However, if consensus fails to emerge naturally, an issue can be referred to the PSC for more structured efforts to build consensus. As a last resort, if lack of consensus continues, the developer community can request the PSC to choose options best preserving the quality of the GRASS project.

Removal of write access to the source code repository is handled as a proposal to the committee as described below in the \ref operation section.

=== Compliance with Legal Measures ===

Control over the codebase also extends to ensuring that it complies with
all relevant legal requirements. This includes copyright and licensing
amongst other issues. The PSC is resonsible for developing rules and
procedures to cover this. These are outlined in a separate document: [[RFC2 | RFC
2: Legal aspects of code contributions]]. This document will be updated and
revised by the PSC as required.

== Project Management ==

The PSC will share responsibility and make decisions over issues related
to the management of the overall direction of the GRASS project and
external visibility, etc. These include, but are not limited to:
* Release Cycles
* Project infrastructure
* Website Maintenance
* Promotion and Public Relations
* Other issues as they become relevant

It is the responsibility of the PSC to ensure that issues critical to the
future of the GRASS project are adequately attended to. This may involve
delegation to interested helpers.

= Operation of the PSC =

A dedicated [http://grass.itc.it/mailman/listinfo/grass-psc Mailing List] exists for the purpose of PSC discussions. When a
decision is required of the PSC, it will be presented by any member to the
mailing list in the form of a proposal. A decision will then be achieved
by discussion of the proposal on the mailing list until a consensus is
reached. Voting on issues is also permissable and may be used as a means
to reach a consensus or, only in case of extreme cases of disagreement, to
force a decision. The [[PSC Agenda]] lists all open motions.
Any member may call a vote on any proposal. The voting procedure is outlined in a separate document, [[RFC3 | RFC3 - PSC Voting Procedures]].

The Chair is the ultimate adjudicator in case of deadlock or irretrievable
break down of decision-making, or in case of disputes over voting.

The following issue(s) *must* have a vote called before a decision is reached:
* Granting source code repository write access for new developers
* Selection of a committee Chair

= Composition of the Committee =

Initial PSC membership was decided based on a nomination and informal voting
period on the community's mailing lists. Michael Barton, Dylan Beaudette,
Hamish Bowman, Massimiliano Cannata, Brad Douglas, Paul Kelly, Helena Mitasova,
Scott Mitchell, Markus Neteler, and Maciej Sieczka are declared to be the
founding Project Steering Committee.

Addition and removal of members from the committee, as well as selection
of Chair is handled as a proposal to the committee as described above.

The Chair is responsible for keeping track of the [[PSC | membership of the PSC]].

[[Category: PSC]]

RFC1

2007-04-07T18:39:58Z

⚠️Smitch: /* Quality Control Mechanisms */ formatting fix

== RFC 1: Project Steering Committee Guidelines ==
: '''Author:''' GRASS Founding PSC
: '''Status:''' Adopted

A GRASS Project Steering Committee ([[PSC]]) is proposed to formalize control
over the GRASS codebase and to facilitate GRASS project management issues.
It is desired to keep the administrative overhead as low as possible.

This document describes how the GRASS Project Steering Committee
determines membership and makes decisions on GRASS project issues.

"The GRASS Project" is defined as the GPL-licenced GIS software known as the
Geographic Resources Analysis Support System, together with the surrounding
development, distribution and promotion infrastructure currently headquarted
at FBK-irst (formerly ITC-irst), Trento, Italy.

= Terms of Reference =

The two primary functions of the PSC are:

1) To enforce control over the GRASS codebase. This can be summarised as:
: a) Enforce mechanisms to ensure quality control.
: b) Ensure compliance with all required legal measures.
2) Project Management and responsibility for the "public face" of GRASS.
The PSC is expected to be able to speak and act on behalf of the GRASS
project.

== Codebase Control ==

=== Quality Control Mechanisms ===

The quality control mechanisms, which are the responsibility of the PSC,
currently include:
* Maintaining submitter guidelines and making all developers aware of them.
* Granting write access to the source code repository for new developers.
* Enforcing the submitter guidelines, with the ultimate sanction against non-compliance being removal of write access to the source code repository.

In general, once write access has been granted, developers are allowed to make changes to the codebase as they see fit. For controversial or complicated changes consensus must be obtained on the developers' mailing list as far as reasonably practicable. It is recognised that the ultimate
arbitration on technical issues always lies with consensus on the developers' mailing list. Specifically, it is not the role of the PSC to impose technical solutions. Its role is limited to enforcing the quality control mechanisms outlined above.

However, if consensus fails to emerge naturally, an issue can be referred to the PSC for more structured efforts to build consensus. As a last resort, if lack of consensus continues, the developer community can request the PSC to choose options best preserving the quality of the GRASS project.

Removal of write access to the source code repository is handled as a proposal to the committee as described below in the \ref operation section.

=== Compliance with Legal Measures ===

Control over the codebase also extends to ensuring that it complies with
all relevant legal requirements. This includes copyright and licensing
amongst other issues. The PSC is resonsible for developing rules and
procedures to cover this. These are outlined in a separate document: "RFC
2: Legal aspects of code contributions". This document will be updated and
revised by the PSC as required.

== Project Management ==

The PSC will share responsibility and make decisions over issues related
to the management of the overall direction of the GRASS project and
external visibility, etc. These include, but are not limited to:
* Release Cycles
* Project infrastructure
* Website Maintenance
* Promotion and Public Relations
* Other issues as they become relevant

It is the responsibility of the PSC to ensure that issues critical to the
future of the GRASS project are adequately attended to. This may involve
delegation to interested helpers.

= Operation of the PSC =

A dedicated [http://grass.itc.it/mailman/listinfo/grass-psc Mailing List] exists for the purpose of PSC discussions. When a
decision is required of the PSC, it will be presented by any member to the
mailing list in the form of a proposal. A decision will then be achieved
by discussion of the proposal on the mailing list until a consensus is
reached. Voting on issues is also permissable and may be used as a means
to reach a consensus or, only in case of extreme cases of disagreement, to
force a decision. The [[PSC Agenda]] lists all open motions.
Any member may call a vote on any proposal. The voting procedure is outlined in a separate document, [[RFC3 | RFC3 - PSC Voting Procedures]].

The Chair is the ultimate adjudicator in case of deadlock or irretrievable
break down of decision-making, or in case of disputes over voting.

The following issue(s) *must* have a vote called before a decision is reached:
* Granting source code repository write access for new developers
* Selection of a committee Chair

= Composition of the Committee =

Initial PSC membership was decided based on a nomination and informal voting
period on the community's mailing lists. Michael Barton, Dylan Beaudette,
Hamish Bowman, Massimiliano Cannata, Brad Douglas, Paul Kelly, Helena Mitasova,
Scott Mitchell, Markus Neteler, and Maciej Sieczka are declared to be the
founding Project Steering Committee.

Addition and removal of members from the committee, as well as selection
of Chair is handled as a proposal to the committee as described above.

The Chair is responsible for keeping track of the [[PSC | membership of the PSC]].

[[Category: PSC]]

RFC1

2007-04-07T16:59:40Z

⚠️Smitch: updated to match RFC1 adopted April 5 (CVS ver 1.11)

== RFC 1: Project Steering Committee Guidelines ==
: '''Author:''' GRASS Founding PSC
: '''Status:''' Adopted

A GRASS Project Steering Committee ([[PSC]]) is proposed to formalize control
over the GRASS codebase and to facilitate GRASS project management issues.
It is desired to keep the administrative overhead as low as possible.

This document describes how the GRASS Project Steering Committee
determines membership and makes decisions on GRASS project issues.

"The GRASS Project" is defined as the GPL-licenced GIS software known as the
Geographic Resources Analysis Support System, together with the surrounding
development, distribution and promotion infrastructure currently headquarted
at FBK-irst (formerly ITC-irst), Trento, Italy.

= Terms of Reference =

The two primary functions of the PSC are:

1) To enforce control over the GRASS codebase. This can be summarised as:
: a) Enforce mechanisms to ensure quality control.
: b) Ensure compliance with all required legal measures.
2) Project Management and responsibility for the "public face" of GRASS.
The PSC is expected to be able to speak and act on behalf of the GRASS
project.

== Codebase Control ==

=== Quality Control Mechanisms ===

The quality control mechanisms, which are the responsibility of the PSC,
currently include:
* Maintaining submitter guidelines and making all developers aware of them.
* Granting write access to the source code repository for new developers.
* Enforcing the submitter guidelines, with the ultimate sanction against
non-compliance being removal of write access to the source code repository.

In general, once write access has been granted, developers are allowed to
make changes to the codebase as they see fit. For controversial or
complicated changes consensus must be obtained on the developers' mailing
list as far as reasonably practicable. It is recognised that the ultimate
arbitration on technical issues always lies with consensus on the
developers' mailing list. Specifically, it is not the role of the PSC to
impose technical solutions. Its role is limited to enforcing the quality
control mechanisms outlined above.

However, if consensus fails to emerge naturally, an issue can be
referred to the PSC for more structured efforts to build consensus.
As a last resort, if lack of consensus continues, the developer
community can request the PSC to choose options best preserving the
quality of the GRASS project.

Removal of write access to the source code repository is handled as a
proposal to the committee as described below in the \ref operation section.

=== Compliance with Legal Measures ===

Control over the codebase also extends to ensuring that it complies with
all relevant legal requirements. This includes copyright and licensing
amongst other issues. The PSC is resonsible for developing rules and
procedures to cover this. These are outlined in a separate document: "RFC
2: Legal aspects of code contributions". This document will be updated and
revised by the PSC as required.

== Project Management ==

The PSC will share responsibility and make decisions over issues related
to the management of the overall direction of the GRASS project and
external visibility, etc. These include, but are not limited to:
* Release Cycles
* Project infrastructure
* Website Maintenance
* Promotion and Public Relations
* Other issues as they become relevant

It is the responsibility of the PSC to ensure that issues critical to the
future of the GRASS project are adequately attended to. This may involve
delegation to interested helpers.

= Operation of the PSC =

A dedicated [http://grass.itc.it/mailman/listinfo/grass-psc Mailing List] exists for the purpose of PSC discussions. When a
decision is required of the PSC, it will be presented by any member to the
mailing list in the form of a proposal. A decision will then be achieved
by discussion of the proposal on the mailing list until a consensus is
reached. Voting on issues is also permissable and may be used as a means
to reach a consensus or, only in case of extreme cases of disagreement, to
force a decision. The [[PSC Agenda]] lists all open motions.
Any member may call a vote on any proposal. The voting procedure is outlined in a separate document, [[RFC3 | RFC3 - PSC Voting Procedures]].

The Chair is the ultimate adjudicator in case of deadlock or irretrievable
break down of decision-making, or in case of disputes over voting.

The following issue(s) *must* have a vote called before a decision is reached:
* Granting source code repository write access for new developers
* Selection of a committee Chair

= Composition of the Committee =

Initial PSC membership was decided based on a nomination and informal voting
period on the community's mailing lists. Michael Barton, Dylan Beaudette,
Hamish Bowman, Massimiliano Cannata, Brad Douglas, Paul Kelly, Helena Mitasova,
Scott Mitchell, Markus Neteler, and Maciej Sieczka are declared to be the
founding Project Steering Committee.

Addition and removal of members from the committee, as well as selection
of Chair is handled as a proposal to the committee as described above.

The Chair is responsible for keeping track of the [[PSC | membership of the PSC]].

[[Category: PSC]]

PSC Agenda

2007-04-06T19:36:00Z

⚠️Smitch: /* Motions */

''This page contains the agenda of the [[PSC | GRASS Project Steering Commitee]].''

=== Open issues ===

==== Motions ====

''These entries need a vote from each committee member.''

*

==== Discussions ====

''These entries do not need a formal vote.''

* License issues of translation support through [https://launchpad.net/products/grass6 Rosetta]

---------------

=== Resolved issues ===

==== Motions ====
<strike>
* [[RFC1 Development Page | RFC1]]Project Steering Committee guidelines- originally moved March 22, was edited and then a new motion for a vote issued April 1 (adopted April 5) [http://mpa.itc.it/markus/grass63progman/rfc/rfc1_psc.html HTML version of CVS file]
* CVS write access to S. Pallecchi (granted, 12 Dec 2006)
* PSC Chair motion (chair: M Neteler, 9 Dec 2006, [http://grass.itc.it/pipermail/grass-psc/2006-December/000143.html see related email message])
* CVS write access to R. Antolin (granted, 8 Dec 2006)
* [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/rfc/RFC2_PSC.dox?rev=HEAD&content-type=text/vnd.viewcvs-markup RFC2] - Legal aspects of code contributions (adopted 8 Dec 2006)
</strike>

==== Discussions ====
<strike>
* GRASS on koders.com: recommendation to do so. A friend of MN has submitted the code.
</strike>
: Did it ever make it?

* Add GRASS to Canonical's Rosetta translation project?
: Unresolved issue: a translation is a derivative and non-original work, and Cononical demands BSD-style copyright assignment of translations submitted through them (but not translations coming from the project). Could a translation back to english from one of those be a end-run around our copyright and the GPL?

=== See also ===
* List of [http://mpa.itc.it/markus/grass63progman/rfc/ RFCs and Motions]

[[Category: PSC]]

PSC Agenda

2007-04-06T19:33:32Z

⚠️Smitch: /* Motions */

''This page contains the agenda of the [[PSC | GRASS Project Steering Commitee]].''

=== Open issues ===

==== Motions ====

''These entries need a vote from each committee member.''

*

==== Discussions ====

''These entries do not need a formal vote.''

* License issues of translation support through [https://launchpad.net/products/grass6 Rosetta]

---------------

=== Resolved issues ===

==== Motions ====
<strike>
* CVS write access to S. Pallecchi (granted, 12 Dec 2006)
* PSC Chair motion (chair: M Neteler, 9 Dec 2006, [http://grass.itc.it/pipermail/grass-psc/2006-December/000143.html see related email message])
* CVS write access to R. Antolin (granted, 8 Dec 2006)
* [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/rfc/RFC2_PSC.dox?rev=HEAD&content-type=text/vnd.viewcvs-markup RFC2] - Legal aspects of code contributions (adopted 8 Dec 2006)
</strike>

==== Discussions ====
<strike>
* GRASS on koders.com: recommendation to do so. A friend of MN has submitted the code.
</strike>
: Did it ever make it?

* Add GRASS to Canonical's Rosetta translation project?
: Unresolved issue: a translation is a derivative and non-original work, and Cononical demands BSD-style copyright assignment of translations submitted through them (but not translations coming from the project). Could a translation back to english from one of those be a end-run around our copyright and the GPL?

=== See also ===
* List of [http://mpa.itc.it/markus/grass63progman/rfc/ RFCs and Motions]

[[Category: PSC]]

GRASS Project Update 2007Q1

2007-04-03T12:01:24Z

⚠️Smitch: small edits for flow, consistency

''This page will be published in the [http://wiki.osgeo.org/index.php/Journal_Volume_1 OSGeo Journal Vol. 1], Developer Announcements section''

== About GRASS GIS ==

GRASS (the Geographic Resources Analysis Support System) is a vector and raster GIS, image processing system, graphics production system, and spatial modelling system. It contains many modules for raster and vector data manipulation, rendering images on the monitor or paper, multispectral image geocoding and processing, and attribute management. It is published under the GNU General Public License.
GRASS is written in the C language with a prototype GRASS-SWIG interface and further Python based WebGIS applications. The data management capabilities also include 3D raster (voxel) modelling as well as vector network analysis. Through the R interface geostatistical analysis can be performed. GRASS is portable multi-platform software running on Linux, MacOS X, Posix compliant Unixes and MS-Windows (through Cygwin, and major parts now also working natively).

== Recent Events ==

* Italian GRASS and GFOSS Users Meeting - GRASS and GFOSS Users Meeting, Palermo (Italy), 14-16 Feb 2007
* 12 Feb 2007: New GRASS bug and wish tracker - Gforge based
* 10 Feb 2007: GRASS GIS 6.2.1 winGRASS/Cygwin binaries available
* 20 Dec 2006: GRASS GIS / OSGeo Newsletter Published - The first combined GRASS-News / OSGeo-News volume is available
* 12 Dec 2006: GRASS 6.2.1 released - This release fixes several bugs discovered in the 6.2.0 source code
* 31 Oct 2006: GRASS 6.2.0 released - The stable version is published
* 11 August 2006: GRASS 6.1.0 released - this is a technology preview release
* 12 April 2006: Experimental native winGRASS 6 version integrated with QGIS
* 22 Feb 2006: GRASS GIS 6.0.2 released - bugfix release
* Spring 2006: GRASS Quality Assessment (QA) source code navigator online

== Under Development ==

Besides hard testing and bugfixing, several major projects are underway:

* native winGRASS port to be completed
* GRASS GIS 6.3.0 to be published ([http://grass.itc.it/announces/announce_grass630.html draft announcement])
* new Python based graphical user interface in progress
* Work related to the OSGeo incubation process (code vetting and addition of missing copyright statements)

== Statistics ==

* In the first three months of 2007, the [http://grass.itc.it/webalizer/ main server statistics] show approximately (there are more than 20 mirror sites, not included here):
** > 5000 GRASS 6.2.1 source code downloads
** > 2000 MS-Windows/Cygwin downloads
** > 1000 Linux downloads
** 11100 Spearfish sample dataset downloads
* grass-users mailing list
** > 800 members
** averaging about 15 messages/day
* grass-dev mailing list
** > 450 members
** averaging about 20 messages/day
* further 12 mailing lists exists plus several national GRASS user lists
* More useful stats can be found on the Ohloh site:
** http://www.ohloh.net/projects/3666

RFC1

2007-03-09T23:47:41Z

⚠️Smitch: /* Quality Control Mechanisms */

''This is a working document with a preliminary proposal, and has not been approved.''

== RFC 1: Project Steering Committee Guidelines ==
: '''Author:''' GRASS Founding PSC
: '''Status:''' Proposed

The GRASS Project Steering Committee ([[PSC]]) is proposed to formalize control
over the GRASS codebase and to facilitate GRASS project management issues.
It is desired to keep the administrative overhead as low as possible.

This document describes how the GRASS Project Steering Committee
determines membership and makes decisions on GRASS project issues.

The Geographic Resources Analysis Support System, commonly referred to as GRASS, is a Geographic Information System (GIS) used for geospatial data management and analysis, image processing, graphics/maps production, spatial modelling, and visualization. "The GRASS Project" is defined as the collection of community-managed source code, documentation, sample data sets, and related intellectual property which has been submitted under the terms of the project's license(s) (see [[Project:Copyrights]] for details) for shared use.

= Terms of Reference =

The two primary functions of the PSC are:

1) To enforce control over the GRASS codebase. This can be summarised as:
: a) Enforce mechanisms to ensure quality control.
: b) Ensure compliance with all required legal measures.
2) Project Management and responsibility for the "public face" of GRASS.
The PSC is expected to be able to speak and act on behalf of the GRASS
project.

== Codebase Control ==

=== Quality Control Mechanisms ===

The quality control mechanisms, which are the responsibility of the PSC,
currently include:
* Maintaining submitter guidelines and making all developers aware of them.
* Granting write access to the source code repository for new developers.
* Enforcing the submitter guidelines, with the ultimate sanction against
non-compliance being removal of write access to the source code repository.

In general, once write access has been granted, developers are allowed to
make changes to the codebase as they see fit. For controversial or
complicated changes consensus must be obtained on the developers' mailing
list as far as reasonably practicable. It is recognised that the ultimate
arbitration on technical issues always lies with consensus on the
developers' mailing list. Specifically, it is not the role of the PSC to
impose technical solutions. Its role is limited to enforcing the quality
control mechanisms outlined above.

=== Compliance with Legal Measures ===

Control over the codebase also extends to ensuring that it complies with
all relevant legal requirements. This includes copyright and licensing
amongst other issues. The PSC is resonsible for developing rules and
procedures to cover this. These are outlined in a separate document: "RFC
2: Legal aspects of code contributions". This document will be updated and
revised by the PSC as required.

== Project Management ==

The PSC will share responsibility and make decisions over issues related
to the management of the overall direction of the GRASS project and
external visibility, etc. These include, but are not limited to:
* Release Cycles
* Project infrastructure
* Website Maintenance
* Promotion and Public Relations
* Other issues as they become relevant

It is the responsibility of the PSC to ensure that issues critical to the
future of the GRASS project are adequately attended to. This may involve
delegation to interested helpers.

= Operation of the PSC =

The PSC has its own public [http://grass.itc.it/mailman/listinfo/grass-psc Mailing List].

A dedicated [http://grass.itc.it/mailman/listinfo/grass-psc Mailing List] exists for the purpose of PSC discussions. When a
decision is required of the PSC, it will be presented by any member to the
mailing list in the form of a proposal. A decision will then be achieved
by discussion of the proposal on the mailing list until a consensus is
reached. Voting on issues is also permissable and may be used as a means
to reach a consensus or, only in case of extreme cases of disagreement, to
force a decision. The [[PSC Agenda]] lists all open motions.
Any member may call a vote on any proposal. That member
is then responsible for collating votes and presenting the result to the
PSC. The voting procedure is outlined in a separate document: XXXXXXX

(Copy all the +1/0- stuff in there). -> Can somebody please do that, potentially a link to the docuemnt is enough.

== Issues that must be voted by the PSC ==

The following issue(s) *must* have a vote called before a decision is reached:
* Granting source code repository write access for new developers
* Selection of a committee Chair

== Prevent Consensus Process from Stalement ==

It is recognised that the ultimate arbitration on technical issues
should always lie with consensus on the developers' mailing list.
Specifically, it is not the role of the [[PSC]] to impose technical
solutions. Its role is limited to enforcing the quality control
mechanisms outlined above. In general, once write access has been
granted, developers are allowed to make changes to the codebase as
they see fit. For controversial or complicated changes consensus must
be obtained on the developers' mailing list as far as reasonably
practicable. If consensus fails to emerge naturally, issues can be
referred to the PSC for more structured efforts to build consensus.
As a last resort, if lack of consensus continues, the developer
community can request the PSC to choose options best preserving the
quality of the GRASS project.

== Resolving Deadlock or Break Down ==
The Chair is the ultimate adjudicator in case of deadlock or irretrievable
break down of decision-making, or in case of disputes over voting.

= Composition of the Committee =
''This list could be replace by a link to the [[PSC]] page:''

Michael Barton, Dylan Beaudette, Hamish Bowman, Massimiliano Cannata, Brad
Douglas, Paul Kelly, Helena Mitasova, Scott Mitchell, Markus Neteler, and
Maciej Sieczka are declared to be the founding Project Steering Committee.

Addition and removal of members from the committee, as well as selection
of a Chair is handled as a proposal to the committee as described above.

The Chair is responsible for keeping track of the membership of the [[PSC]].

RFC1

2007-03-09T23:47:03Z

⚠️Smitch: /* RFC 1: Project Steering Committee Guidelines */

''This is a working document with a preliminary proposal, and has not been approved.''

== RFC 1: Project Steering Committee Guidelines ==
: '''Author:''' GRASS Founding PSC
: '''Status:''' Proposed

The GRASS Project Steering Committee ([[PSC]]) is proposed to formalize control
over the GRASS codebase and to facilitate GRASS project management issues.
It is desired to keep the administrative overhead as low as possible.

This document describes how the GRASS Project Steering Committee
determines membership and makes decisions on GRASS project issues.

The Geographic Resources Analysis Support System, commonly referred to as GRASS, is a Geographic Information System (GIS) used for geospatial data management and analysis, image processing, graphics/maps production, spatial modelling, and visualization. "The GRASS Project" is defined as the collection of community-managed source code, documentation, sample data sets, and related intellectual property which has been submitted under the terms of the project's license(s) (see [[Project:Copyrights]] for details) for shared use.

= Terms of Reference =

The two primary functions of the PSC are:

1) To enforce control over the GRASS codebase. This can be summarised as:
: a) Enforce mechanisms to ensure quality control.
: b) Ensure compliance with all required legal measures.
2) Project Management and responsibility for the "public face" of GRASS.
The PSC is expected to be able to speak and act on behalf of the GRASS
project.

== Codebase Control ==

=== Quality Control Mechanisms ===

The quality control mechanisms, which are the responsibility of the PSC,
currently include:
* Maintaining submitter guidelines and making all developers aware of
them.
* Granting write access to the source code repository for new developers.
* Enforcing the submitter guidelines, with the ultimate sanction against
non-compliance being removal of write access to the source code repository.

In general, once write access has been granted, developers are allowed to
make changes to the codebase as they see fit. For controversial or
complicated changes consensus must be obtained on the developers' mailing
list as far as reasonably practicable. It is recognised that the ultimate
arbitration on technical issues always lies with consensus on the
developers' mailing list. Specifically, it is not the role of the PSC to
impose technical solutions. Its role is limited to enforcing the quality
control mechanisms outlined above.

=== Compliance with Legal Measures ===

Control over the codebase also extends to ensuring that it complies with
all relevant legal requirements. This includes copyright and licensing
amongst other issues. The PSC is resonsible for developing rules and
procedures to cover this. These are outlined in a separate document: "RFC
2: Legal aspects of code contributions". This document will be updated and
revised by the PSC as required.

== Project Management ==

The PSC will share responsibility and make decisions over issues related
to the management of the overall direction of the GRASS project and
external visibility, etc. These include, but are not limited to:
* Release Cycles
* Project infrastructure
* Website Maintenance
* Promotion and Public Relations
* Other issues as they become relevant

It is the responsibility of the PSC to ensure that issues critical to the
future of the GRASS project are adequately attended to. This may involve
delegation to interested helpers.

= Operation of the PSC =

The PSC has its own public [http://grass.itc.it/mailman/listinfo/grass-psc Mailing List].

A dedicated [http://grass.itc.it/mailman/listinfo/grass-psc Mailing List] exists for the purpose of PSC discussions. When a
decision is required of the PSC, it will be presented by any member to the
mailing list in the form of a proposal. A decision will then be achieved
by discussion of the proposal on the mailing list until a consensus is
reached. Voting on issues is also permissable and may be used as a means
to reach a consensus or, only in case of extreme cases of disagreement, to
force a decision. The [[PSC Agenda]] lists all open motions.
Any member may call a vote on any proposal. That member
is then responsible for collating votes and presenting the result to the
PSC. The voting procedure is outlined in a separate document: XXXXXXX

(Copy all the +1/0- stuff in there). -> Can somebody please do that, potentially a link to the docuemnt is enough.

== Issues that must be voted by the PSC ==

The following issue(s) *must* have a vote called before a decision is reached:
* Granting source code repository write access for new developers
* Selection of a committee Chair

== Prevent Consensus Process from Stalement ==

It is recognised that the ultimate arbitration on technical issues
should always lie with consensus on the developers' mailing list.
Specifically, it is not the role of the [[PSC]] to impose technical
solutions. Its role is limited to enforcing the quality control
mechanisms outlined above. In general, once write access has been
granted, developers are allowed to make changes to the codebase as
they see fit. For controversial or complicated changes consensus must
be obtained on the developers' mailing list as far as reasonably
practicable. If consensus fails to emerge naturally, issues can be
referred to the PSC for more structured efforts to build consensus.
As a last resort, if lack of consensus continues, the developer
community can request the PSC to choose options best preserving the
quality of the GRASS project.

== Resolving Deadlock or Break Down ==
The Chair is the ultimate adjudicator in case of deadlock or irretrievable
break down of decision-making, or in case of disputes over voting.

= Composition of the Committee =
''This list could be replace by a link to the [[PSC]] page:''

Michael Barton, Dylan Beaudette, Hamish Bowman, Massimiliano Cannata, Brad
Douglas, Paul Kelly, Helena Mitasova, Scott Mitchell, Markus Neteler, and
Maciej Sieczka are declared to be the founding Project Steering Committee.

Addition and removal of members from the committee, as well as selection
of a Chair is handled as a proposal to the committee as described above.

The Chair is responsible for keeping track of the membership of the [[PSC]].

RFC1

2007-03-09T23:43:02Z

⚠️Smitch: /* RFC 1: Project Steering Committee Guidelines */

''This is a working document with a preliminary proposal, and has not been approved.''

== RFC 1: Project Steering Committee Guidelines ==
: '''Author:''' GRASS Founding PSC
: '''Status:''' Proposed

The GRASS Project Steering Committee ([[PSC]]) is proposed to formalize control
over the GRASS codebase and to facilitate GRASS project management issues.
It is desired to keep the administrative overhead as low as possible.

This document describes how the GRASS Project Steering Committee
determines membership and makes decisions on GRASS project issues.

The Geographic Resources Analysis Support System, commonly referred to as GRASS, is a Geographic Information System (GIS) used for geospatial data management and analysis, image processing, graphics/maps production, spatial modelling, and visualization. "The GRASS Project" is defined as the collection of community-managed source code, documentation, sample data sets, and related intellectual property which has been submitted under the terms of the projects license(s) for shared use.

= Terms of Reference =

The two primary functions of the PSC are:

1) To enforce control over the GRASS codebase. This can be summarised as:
: a) Enforce mechanisms to ensure quality control.
: b) Ensure compliance with all required legal measures.
2) Project Management and responsibility for the "public face" of GRASS.
The PSC is expected to be able to speak and act on behalf of the GRASS
project.

== Codebase Control ==

=== Quality Control Mechanisms ===

The quality control mechanisms, which are the responsibility of the PSC,
currently include:
* Maintaining submitter guidelines and making all developers aware of
them.
* Granting write access to the source code repository for new developers.
* Enforcing the submitter guidelines, with the ultimate sanction against
non-compliance being removal of write access to the source code repository.

In general, once write access has been granted, developers are allowed to
make changes to the codebase as they see fit. For controversial or
complicated changes consensus must be obtained on the developers' mailing
list as far as reasonably practicable. It is recognised that the ultimate
arbitration on technical issues always lies with consensus on the
developers' mailing list. Specifically, it is not the role of the PSC to
impose technical solutions. Its role is limited to enforcing the quality
control mechanisms outlined above.

=== Compliance with Legal Measures ===

Control over the codebase also extends to ensuring that it complies with
all relevant legal requirements. This includes copyright and licensing
amongst other issues. The PSC is resonsible for developing rules and
procedures to cover this. These are outlined in a separate document: "RFC
2: Legal aspects of code contributions". This document will be updated and
revised by the PSC as required.

== Project Management ==

The PSC will share responsibility and make decisions over issues related
to the management of the overall direction of the GRASS project and
external visibility, etc. These include, but are not limited to:
* Release Cycles
* Project infrastructure
* Website Maintenance
* Promotion and Public Relations
* Other issues as they become relevant

It is the responsibility of the PSC to ensure that issues critical to the
future of the GRASS project are adequately attended to. This may involve
delegation to interested helpers.

= Operation of the PSC =

The PSC has its own public [http://grass.itc.it/mailman/listinfo/grass-psc Mailing List].

A dedicated [http://grass.itc.it/mailman/listinfo/grass-psc Mailing List] exists for the purpose of PSC discussions. When a
decision is required of the PSC, it will be presented by any member to the
mailing list in the form of a proposal. A decision will then be achieved
by discussion of the proposal on the mailing list until a consensus is
reached. Voting on issues is also permissable and may be used as a means
to reach a consensus or, only in case of extreme cases of disagreement, to
force a decision. The [[PSC Agenda]] lists all open motions.
Any member may call a vote on any proposal. That member
is then responsible for collating votes and presenting the result to the
PSC. The voting procedure is outlined in a separate document: XXXXXXX

(Copy all the +1/0- stuff in there). -> Can somebody please do that, potentially a link to the docuemnt is enough.

== Issues that must be voted by the PSC ==

The following issue(s) *must* have a vote called before a decision is reached:
* Granting source code repository write access for new developers
* Selection of a committee Chair

== Prevent Consensus Process from Stalement ==

It is recognised that the ultimate arbitration on technical issues
should always lie with consensus on the developers' mailing list.
Specifically, it is not the role of the [[PSC]] to impose technical
solutions. Its role is limited to enforcing the quality control
mechanisms outlined above. In general, once write access has been
granted, developers are allowed to make changes to the codebase as
they see fit. For controversial or complicated changes consensus must
be obtained on the developers' mailing list as far as reasonably
practicable. If consensus fails to emerge naturally, issues can be
referred to the PSC for more structured efforts to build consensus.
As a last resort, if lack of consensus continues, the developer
community can request the PSC to choose options best preserving the
quality of the GRASS project.

== Resolving Deadlock or Break Down ==
The Chair is the ultimate adjudicator in case of deadlock or irretrievable
break down of decision-making, or in case of disputes over voting.

= Composition of the Committee =
''This list could be replace by a link to the [[PSC]] page:''

Michael Barton, Dylan Beaudette, Hamish Bowman, Massimiliano Cannata, Brad
Douglas, Paul Kelly, Helena Mitasova, Scott Mitchell, Markus Neteler, and
Maciej Sieczka are declared to be the founding Project Steering Committee.

Addition and removal of members from the committee, as well as selection
of a Chair is handled as a proposal to the committee as described above.

The Chair is responsible for keeping track of the membership of the [[PSC]].

GRASS 6 Tutorial

2007-02-08T13:43:38Z

⚠️Smitch: /* Getting started in general */

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.itc.it/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][NVIS]] 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==

* [[Introductory Material]] for Linux and GRASS

==Getting started - how to migrate to the new GRASS version==

* [[Grass Six Tutorial Getting Started]]

==Raster data management==

* The raster management works as it did in previous GRASS versions.

==Vector data management==

===[[Grass Six Tutorial Default Settings]]===
- Default settings for vector geometry;
for vector attributes; for db.* modules

===[[Grass Six Tutorial Geometry Management]]===
- 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]]===
- General notes on Attribute
management; Managing the default settings; Examples;
Database Schema

==Usage examples==

===Basic usage examples===

===Complex usage examples===

===Vector network analysis examples===

===Vector overlay/clipping examples===

===Examples from US National Atlas===

===FAQ (Frequently Asked Questions)===

* Grass Six Tutorial Faq

==Troubleshooting==

* 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====

ORDINARY KRIGING IN R WITH GRASS6 DATA

Of all the methods we tried this is the most easy and (I suppose) exact too:

You have to have in your library the packages "gstat" and "spgrass6", you can download this last one directly from R using the command "install.packages".
In GRASS we have a vector file named "giaciture_cat_clean3" and we want to do a prediction on this data...
these are the commmands:

enter R from the GRASS prompt, and type:

<pre>
library(spgrass6)

#get vector points as SpatialPointsDataFrame
giaciture <- getSites6sp("giaciture_cat_clean3")

class(giaciture) #shows the class of "giaciture" (SpatialPointsDataFrame)

G <- gmeta6() #get region from GRASS to R
</pre>

now if you want you can continue to work in R from GRASS or not...

<pre>
#create a grid from the region settings of GRASS, it is very important
# to have square cells, so you can set the region settings of GRASS or
# you can give directly square dimensions using the values:
# e.g."cells.dim=c(50,50)"
grd <- GridTopology(cellcentre.offset=c(G$west+(G$ewres/2)
,G$south+(G$nsres/2))
,cellsize=c(G$ewres, G$nsres)
,cells.dim=c(G$cols, G$rows))

#create a SpatialGridDataFrame
mask_SG <- SpatialGridDataFrame(grd
,data=list(k=rep(1,G$cols*G$rows))
,proj4string=CRS(G$proj4))

class(mask_SG)

library(gstat)

cvgm <- variogram(IMMERSIONE~1,locations=giaciture,width=400,cutoff=4000)
#create variogram, and "IMMERSIONE"
#here is the our variable, the variable on wich we have to do the prediction,
# ~ 1 select the type of kriging, this is the ordinary one

efitted <- fit.variogram(cvgm,vgm(psill=5000,model="Exp",range=1500,nugget=8000))
# choose the model to fit variogram (here is exponential) and give the
# estimated parameters of the variogram (partial sill, range and nugget)

OK_pred <- krige(IMMERSIONE~1,locations=giaciture,newdata=mask_SG,model=efitted)
# make the kriging prediction

names(OK_pred) #show the name of variable kriged

writeRast6sp(OK_pred,"OK_pred",zcol="var1.pred",NODATA=-9999)
#write a raster file and save it in GRASS, now you can open it from there.
</pre>

that's all!

special thanks to Roger Bivand, ever ready to lend a hand!

* GRASS <a href="http://grass.itc.it/gdp/tutorials.php">books and tutorials</a>
* GRASS 6 Tutorial: http://www.gdf-hannover.de/literature
* Translation Portal for GRASS 6 Tutorial http://www.gdf-hannover.de/translation

[[Category:Documentation]]

Project jobs

2006-12-11T13:47:22Z

⚠️Smitch: minor edits + add Scott Mitchell volunteering

== Jobs in the GRASS project ==

- draft -

The growing infrastructure and extended user support requires more efforts to integrate user contributions and to keep things running. This page contains a list of jobs for which we seek volunteers. These jobs descriptions may appear a bit formal, but shall illustrate the needs.

=== Translations manager ===

The translations manager is responsible for maintaining the translation of GRASS messages
([http://grass.itc.it/devel/i18n.php translation page; [http://grass.itc.it/mailman/listinfo/translations mailing list])

Skills:
* knowledge (or willingness to learn use) of translation tools (kbabel, poEDIT)
* familiarity (or willingness to learn use) with CVS (see [[Working with CVS|instructions]])
* no programming skills required
Tasks:
* work with GRASS CVS-Head (latest GRASS)
* merging translation contributions (with 'msgmerge' of .po files or simply use [http://mpa.itc.it/markus/useful/po_merge.sh po_merge.sh])
* invite translators to contribute (ask regularly, find new), make them use recent GRASS
* create template files for new languages ('make pot')
* update existing translations '''after''' having received latest submissions from translators ('make update-po')
* keep headers of .po files intact and up-to-date
* add new translators to AUTHORS file in source code
Estimated workload:
* in average: 1-2h per week or less

=== Web site contributors ===

Several Web site contributors are desired to update pages and to improve the current structure. A future goal could be the move to a CMS system such as Drupal which would be a major effort.

Skills:
* knowledge of standard HTML (a single PHP function is used to construct menus)
* willingness to use plain text editors to write pages (to avoid that HTML cruft creeps in)
* familiarity (or willingness to learn use) with GRASS Web site CVS (see [[Working with CVS|instructions]])
* no programming skills required
Tasks:
* update outdated pages
* think about and implement "user stories" to make site more attractive
* think about and implement translation of important pages
* simplify structure
* add new screenshots with credits/CC license)
* regularly check if mirror sites work
Estimated workload:
* in average: 1-x h per week

=== Public relations manager ===

Despite the continuous growth of the user community, we seek "GRASS GIS awareness" especially for public administration and companies. A multi-language brochure is needed to promote GRASS in a more effective way. Funding for a high quality print is to be defined.

Skills:
* communication and design skills
Tasks:
* find like-minded people to form a GRASS promotion group
* communicate the existence of the GRASS project
* design of a multi-language brochure (both PDF and printed) in collaboration with the [http://wiki.osgeo.org/index.php?title=VisCom OSGeo-VisCom team]
* create material to illustrate the GRASS functionality
* contact public administration and professionals in a non-spammy way
* collect success stories and render them usable for the Web site

=== Wiki manager ===

The GRASS wiki (you are using it at the moment) requires continuous monitoring.

Skills:
* basic knowledge of mediawiki usage
* no programming skills required
Tasks:
* update outdated pages
* simplify structure where needed (merge pages)
* clean up [[:Special:Lonelypages|Orphaned pages]] (link, merge or remove)
* keep [[:Special:Categories|Categories]] up to date (add at bottom of pages where needed)
* keep an eye on spammers
Estimated workload:
* in average: 1h per week

== Interested people ==

While we have to figure out the process, here a list of interested people. Please add yourself:

* Malte Halbey-Martin: Public relations Manager + Web site contributor
* Dylan Beaudette: Web site contributor (familiar with Drupal CMS)
* Scott Mitchell: Web site contributor, could possibly do the translation job, if nobody with translation tool experience volunteers

Time series development

2006-09-18T11:29:05Z

⚠️Smitch: Work towards a time series data standard and utilities in GRASS

This page is born out of discussions in Lausanne. A lot of people seem to be interested in having some standardized, documented format for dealing with time series in GRASS, so that we can deal with data (e.g. climate station, water gauges), link with models, etc., without having to come up with a custom solution each time. This could also lead to modules to help with interpolation to deal with missing values, etc.

There was also discussion of possibly setting up a mailing list. Do we want this?

Development

2006-09-18T11:25:42Z

⚠️Smitch: /* Sandbox (ideas section) */

__TOC__

The GRASS GIS project is developed under the terms of the [http://www.gnu.org/copyleft/gpl.html GNU General Public License] (the GPL) [http://grass.ibiblio.org/devel/index.php in the open] by [http://grass.ibiblio.org/community/index.php volunteers] the [http://mapserver.gdf-hannover.de/grassusers/map.phtml world over].

=== Resources for Developers ===

==== Communication ====
* You can contact GRASS folks in [[How to participate in IRC communication|IRC]]
* [http://grass.itc.it/mailman/listinfo/grass-dev Developers mailing list]

==== Documentation ====
* [http://grass.itc.it/devel/index.php#prog GRASS Programming Manual]
* [[GRASS Programming Howto]] (partially outdated)
* [[Gis Concepts]] and how they are implemented in GRASS
* [[GRASS Debugging]]
* '''Code submission standards''':
** [http://grass.itc.it/grass61/source/SUBMITTING C language coding standards]
** [http://grass.itc.it/grass61/source/SUBMITTING_SCRIPTS Shell script coding standards]
** [http://grass.itc.it/grass61/source/SUBMITTING_TCLTK Tcl/Tk script coding standards]

==== Code ====
* [http://grass.ibiblio.org/devel/cvs.php CVS server] | [http://freegis.org/cgi-bin/viewcvs.cgi/ GRASS WebCVS interface] browsable source code repository
* [http://intevation.de/rt/webrt?q_queue=grass GRASS bug and wish tracking system]
* [[GRASS AddOns]] (User contributions)

==== Source code quality control ====
* [http://cia.navi.cx/stats/project/GRASS CIA commit bot] for realtime monitoring along with [http://grass.itc.it/mailman/listinfo/grass-commit grass-commit] mailing list (showing the diff's)
* [http://grass.itc.it/mailman/listinfo/grass-qa Code Quality Control System]
* [http://web.soccerlab.polymtl.ca/grass-evolution/grass-browsers/grass-index-en.html GRASS Software Evolution code analysis]
* [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/ GRASS Test Suite] a small test suite for GRASS, the current html output is available [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html/ here] and with memory check [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_memcheck/ here]

=== GRASS and QGIS ===

* [http://wiki.qgis.org/qgiswiki/BuildingWindowsBinaryOnLinux Building QGIS/GRASS Windows Binary On Linux] (using MinGW)
* [http://wiki.qgis.org/qgiswiki/Adding_New_Tools_to_the_GRASS_Toolbox Adding New Tools to the GRASS Toolbox]

=== GRASS License ===

* [http://en.wikipedia.org/wiki/Gpl WikiPedia entry discussing the GPL]

=== Plans ===

===== Overview =====

* [[Release Roadmap]]
* [http://grass.ibiblio.org/devel/roadmap.php Development Roadmap] ''(needs freshening)''
* [[GRASS Module Porting List]] (check here if you don't find a certain command in GRASS 6.0)
* [[GRASS ToDo List]] (overview of GRASS related community projects)
* [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS 6-CVS Vector TODO]

===== Sandbox (ideas section) =====

* [[GRASS 7 ideas collection]]
* [[GRASS GUI]] development
* [http://wgbis.ces.iisc.ernet.in/grdss/index.php GRDSS (Geographic Resources Decision Support System)]
* Ideas on a [[replacement raster format]] specification
* add support (at least storage!) of vertical datum and units
* Discussion on [[Development Specs]] for standardized messages
* Discussion on add-on manager repository setup: [[Development GEM|GEM repository]]
* Discussion of support for [[time series in GRASS]], e.g. for linking to data and models

=== Linking GRASS to external languages ===
* [http://mpa.itc.it/markus/grass61progman/swig/ GRASS-SWIG interface]: generic interface to various languages
* [[GRASS and PHP]]
* [[GRASS and Python]]
* [[GRASS and Shell]]: Starting and running GRASS from a script
* [http://grass.itc.it/mailman/listinfo/grass-abm Integration of GRASS with JAVA based agent based modeling (ABM)]
* [http://www.hydrologis.com/html/jgrass/jgrass_en.html JAVAGRASS]

=== Related projects ===

* [http://www.hydrologis.com/html/jgrass/jgrass_en.html JGrass] - Java based frontend for GRASS incuding extended hydrological modelling tools
* [http://www.kergis.com/en/index.html KerGIS] - BSD-like licensed fork of GRASS 4.1.5

* [http://proj.maptools.org PROJ.4] - Cartographic Projections Library
* [http://www.gdal.org GDAL] - Geospatial Data Abstraction Library
* [http://www.qgis.org QGIS]- Quantum GIS

* [http://www.osgeo.org OSGeo]- The Open Source Geospatial Foundation
* [http://freegis.org FreeGIS.org] - Interactive information base for the GIS Free Software world

[[Category:Development]]