Category Archives: GRASS

GRASS GIS 6.4.5RC1 released

GRASS GIS logoAfter months of development a first release candidate of GRASS GIS 6.4.5 is now available. This is a stability release of the GRASS GIS 6 line.

Source code download:

Binaries download:

To get the GRASS GIS 6.4.5RC1 source code directly from SVN:
svn checkout

Key improvements:
Key improvements of the GRASS GIS 6.4.5RC1 release include stability fixes (esp. vector library), some fixes for wxPython3 support, some module fixes, and more message translations.

See also our detailed announcement:

First time users should explore the first steps tutorial after installation:

Release candidate management at

Please join us in testing this release candidate for the final release.

Consider to donate pizza or beer for the next GRASS GIS Community Sprint (following the FOSS4G Europe 2015 in Como):

Thanks to all contributors!


The Geographic Resources Analysis Support System (, commonly referred to as GRASS GIS, is an Open Source Geographic Information System providing powerful raster, vector and geospatial processing capabilities in a single integrated software suite. GRASS GIS includes tools for spatial modeling, visualization of raster and vector data, management and analysis of geospatial data, and the processing of satellite and aerial imagery. It also provides the capability to produce sophisticated presentation graphics and hardcopy maps. GRASS GIS has been translated into about twenty languages and supports a huge array of data formats. It can be used either as a stand-alone application or as backend for other software packages such as QGIS and R geostatistics. It is distributed freely under the terms of the GNU General Public License (GPL). GRASS GIS is a founding member of the Open Source Geospatial Foundation (OSGeo).

The GRASS Development Team, April 2015

New stable release of GRASS GIS 7.0.0!

The GRASS GIS Development team has announced the release of the new major version GRASS GIS 7.0.0. This version provides many new functionalities including spatio-temporal database support, image segmentation, estimation of evapotranspiration and emissivity from satellite imagery, automatic line vertex densification during reprojection, more LIDAR support and a strongly improved graphical user interface experience. GRASS GIS 7.0.0 also offers significantly improved performance for many raster and vector modules: “Many processes that would take hours now take less than a minute, even on my small laptop!” explains Markus Neteler, the coordinator of the development team composed of academics and GIS professionals from around the world. The software is available for Linux, MS-Windows, Mac OSX and other operating systems.

Detailed announcement and software download:

The Geographic Resources Analysis Support System (, commonly referred to as GRASS GIS, is an open source Geographic Information System providing powerful raster, vector and geospatial processing capabilities in a single integrated software suite. GRASS GIS includes tools for spatial modeling, visualization of raster and vector data, management and analysis of geospatial data, and the processing of satellite and aerial imagery. It also provides the capability to produce sophisticated presentation graphics and hardcopy maps. GRASS GIS has been translated into about twenty languages and supports a huge array of data formats. It can be used either as a stand-alone application or as backend for other software packages such as QGIS and R geostatistics. It is distributed freely under the terms of the GNU General Public License (GPL). GRASS GIS is a founding member of the Open Source Geospatial Foundation (OSGeo).

GRASS GIS 7: Vector data reprojection with automated vertex densification

GRASS GIS 7 just got better: When reprojecting vector data, now automated vertex densification is applied. This reduces the reprojection error for long lines (or polygon boundaries). The needed improvement has been kindly added in v.proj by Markus Metz.

1. Example

As an (extreme?) example, we generate a box in LatLong/WGS84 (EPSG: 4326) which is of 10 degree side length (see below for screenshot and at bottom for SHAPE file download of this “box” map):

[neteler@oboe ~]$ grass70 ~/grassdata/latlong/grass7/
# for the ease of generating the box, set computational region:
g.region n=60 s=40 w=0 e=30 res=10 -p
projection: 3 (Latitude-Longitude)
zone:       0
datum:      wgs84
ellipsoid:  wgs84
north:      60N
south:      40N
west:       0
east:       30E
nsres:      10
ewres:      10
rows:       2
cols:       3
cells:      6
# generate the box according to current computational region: box_latlong_10deg

Next we start GRASS GIS in a metric projection, here the EU LAEA:

# EPSG 3035, metric EU LAEA:
grass70 ~/grassdata/europe_laea/user1/
GRASS 7.0.0svn (europe_laea): >

Now we first reproject the map the “traditional way” (no vertex densification as in most GIS, here enforced by smax=0):

v.proj box_latlong_10deg out=box_latlong_10deg_no_densification
location=latlong mapset=grass7 smax=0

Then we do a second reprojection with new automated vertex densification (here we use the default values for smax which is a 10km vertex distance in the reprojected map by default):

v.proj box_latlong_10deg out=box_latlong_10deg_yes_densification
location=latlong mapset=grass7

Eventually we can compare both reprojected maps:

g.region vect=box_latlong_10deg_no_densification

# compare:
d.mon wx0
d.vect box_latlong_10deg_no_densification color=red
d.vect box_latlong_10deg_yes_densification color=green fill_color=none
Comparison of the reprojection of a 10 degree large LatLong box to the metric EU LAEA (EPSG 3035): before in red and new in green. The grid is based on WGS84 at 5 degree spacing.

Comparison of the reprojection of a 10 degree large LatLong box to the metric EU LAEA (EPSG 3035): before in red and new in green. The grid is based on WGS84 at 5 degree spacing.

The result shows how nicely the projection is now performed in GRASS GIS 7: the red line output is old, the green color line is the new output (its area filling is not shown).

Consider to benchmark this with other GIS… the reprojected map should not become a simple trapezoid.

2. Sample dataset download

Download of box_latlong_10deg.shp for own tests (1kB).

Landsat 8 captures Trentino in November 2014

The beautiful days in early November 2014 allowed to get some nice views of the Trentino (Northern Italy) – thanks to Landsat 8 and NASA’s open data policy:

Landsat 8: Northern Italy 1 Nov 2014
Landsat 8: Northern Italy 1 Nov 2014

Trento captured by Landsat8
Trento captured by Landsat8

Landsat 8: San Michele - 1 Nov 2014
Landsat 8: San Michele – 1 Nov 2014

The beauty of the landscape but also the human impact (landscape and condensation trails of airplanes) are clearly visible.

All data were processed in GRASS GIS 7 and pansharpened with i.fusion.hpf written by Nikos Alexandris.

Selective data removal in an elevation map by means of floodfilling

Do you also sometimes get maps which contain zero (0) rather than NULL (no data) in some parts of the map? This can be easily solved with “floodfilling”, even in a GIS.

My original map looks like this (here, Trentino elevation model):

The light blue parts should be no data (NULL) rather than zero (0)...

Now what? In a paint software we would simply use bucket fill but what about GIS data? Well, we can do something similar using “clumping”. It requires a bit of computational time but works perfectly, even for large DEMs, e.g., all Italy at 20m resolution. Using the open source software GRASS GIS 7, we can compute all “clumps” (that are many for a floating point DEM!):

# first we set the computational region to the raster map:
g.region rast=pat_DTM_2008_derived_2m -p
r.clump pat_DTM_2008_derived_2m out=pat_DTM_2008_derived_2m_clump

The resulting clump map produced by r.clump is nicely colorized:

Clumped map derived from DEM (generated with r.clump)

As we can see, the area of interest (province) is now surrounded by three clumps. With a simple map algebra statement (r.mapcalc or GUI calculator) we can create a MASK by assigning these outer boundary clumps to NULL and the other “good” clumps to 1:

r.mapcalc "no_data_mask = if(pat_DTM_2008_derived_2m_clump == 264485050 || \
  pat_DTM_2008_derived_2m_clump == 197926480 || \
  pat_DTM_2008_derived_2m_clump == 3, null(), 1)"

This mask map looks like this:

Mask map from all clumps except for the large outer clumps

We now activate this MASK and generate a copy of the original map into a new map name by using map algebra again (this just keeps the data matched by the MASK). Eventually we remove the MASK and verify the result:

# apply the mask
r.mask no_data_mask
# generate a copy of the DEM, filter on the fly
r.mapcalc "pat_DTM_2008_derived_2m_fixed = pat_DTM_2008_derived_2m"
# assign a nice color table
r.colors pat_DTM_2008_derived_2m_fixed color=srtmplus
# remove the MASK
r.mask -r

And the final DEM is now properly cleaned up in terms of NULL values (no data):

DEM cleaned up for no data


Rendering a brain CT scan in 3D with GRASS GIS 7

brainscan1Last year (2013) I “enjoyed” a brain CT scan in order to identify a post-surgery issue – luckily nothing found. Being in Italy, like all patients I received a CD-ROM with the scan data on it: so, something to play with! In this article I’ll show how to easily turn 2D scan data into a volumetric (voxel) visualization.

The CT scan data come in a DICOM format which ImageMagick is able to read and convert. Knowing that, we furthermore need the open source software packages GRASS GIS 7 and Paraview to get the job done.

First of all, we create a new XY (unprojected) GRASS location to import the data into:

# create a new, empty location (or use the Location wizard):
grass70 -c ~/grassdata/brain_ct

We now start GRASS GIS 7 with that location. After mounting the CD-ROM we navigate into the image directory therein. The directory name depends on the type of CT scanner which was used in the hospital. The file name suffix may be .IMA.

Now we count the number of images, convert and import them into GRASS GIS:

# list and count
LIST=`ls -1 *.IMA`
MAX=`echo $LIST | wc -w`

# import into XY location:
for i in $LIST ; do

# pretty print the numbers to 000X for easier looping:
curr=`echo $curr | awk ‘{printf “%04d\n”, $1}’`
convert “$i” brain.$curr.png in=brain.$curr.png out=brain.$curr
r.null brain.$curr setnull=0
rm -f brain.$curr.png
curr=`expr $curr + 1`


At this point all CT slices are imported in an ordered way. For extra fun, we can animate the 2D slices in g.gui.animation:

Animation of brain scan slices
(click to enlarge)

# enter in one line:
g.gui.animation rast=`g.mlist -e rast separator=comma pattern=”brain*”`

The tool allows to export as animated GIF or AVI:

Animation of brain scan slices (click to enlarge)

Now it is time to generate a volume:

# first count number of available layers
g.mlist rast pat=”brain*” | wc -l

# now set 3D region to number of available layers (as number of depths)
g.region rast=brain.0003 b=1 t=$MAX -p3

At this point the computational region is properly defined to our 3D raster space. Time to convert the 2D slices into voxels by stacking them on top of each other:

# convert 2D slices to 3D slices: `g.mlist rast pat=”brain*” sep=,` out=brain_vol

We can now look at the volume with GRASS GIS’ wxNVIZ or preferably the extremely powerful Paraview. The latter requires an export of the volume to VTK format:

# fetch some environment variables
eval `g.gisenv -s`
# export GRASS voxels to VTK 3D as 3D points, with scaled z values:
g.message “Exporting to VTK format, scale factor: $SCALE”
r3.out.vtk brain_vol dp=2 elevscale=$SCALE \
output=${PREFIX}_${MAPSET}_brain_vol_scaled${SCALE}.vtk -p

Eventually we can open this new VTK file in Paraview for visual exploration:

# show as volume
# In Paraview: Properties: Apply; Display Repres: volume; etc.
paraview –data=brain_s1_vol_scaled2.vtk

markus_brain_ct_scan3 markus_brain_ct_scan4 markus_brain_ct_scan2













Fairly easy!

BTW: I have a scan of my non-smoker lungs as well :-)

Workshop at FOSS4G 2014: Spatio-temporal data handling and visualization in GRASS GIS 7

Drowning in too many maps? Have some fun exploring fascinating geometries of changing landscapes in Space Time Cube and creating 2D and 3D animations from time series of geospatial data. Learn about the new capabilities for spatio-temporal data handling in GRASS GIS 7 ( and explore various techniques for dynamic visualizations.

First, we will introduce you to GRASS GIS 7, including its spatio-temporal capabilities and you will learn how to manage and analyze geospatial data time series. Then, we will explore new tools for visualization of spatio-temporal data. You will create both 2D and 3D dynamic visualizations directly in GRASS GIS 7. Additionally, we will explain the Space Time Cube concept using various applications based on raster and vector data time series. You will learn to manage and visualize data in space time cubes (voxel models). No prior knowledge of GRASS GIS is necessary, we will cover the basics needed for the workshop. All relevant material including an overview of the tools and hands-on practical instructions along with the sample data sets will be available on-line. And, by the way, GRASS GIS is a free and open source geographic information system (GIS) used for geospatial data management, analysis, modeling, image processing, and visualization which runs on Linux, MS Windows, Mac OS X and other systems.

Presenters: Vaclav Petras, Anna Petrasova, Helena Mitasova, Markus Neteler

When: FOSS4G 2014, Sept 8th-13th 2014, Portland, OR, USA

Register at:

Importing and visualizing LAS LiDAR files in GRASS GIS 7:


LiDAR point cloud data are commonly delivered in the ASPRS LAS format. The format is supported by libLAS, a BSD-licensed C++ library for reading/writing these data. GRASS GIS 7 supports the LAS format directly when built against libLAS (as the case for most binary packages being available for download).

In this exercise we will import a sample LAS data set covering a tiny area close to Raleigh, NC (USA), belonging to the North Carolina sample data set. Sample LAS data download:  (25MB).

For a full exercise, we will, however, assume that no GRASS GIS location is ready so far (so: newbies are welcome!) and create a new one initially.

1. 1. Having the LAS file: now what?

In the first place, check the metadata of the LAS file using the lasinfo command (comes with libLAS; here only parts of the output shown):

lasinfo points.las
  Header Summary
  Version:  1.2
  Source ID:  0
  Reserved:  0
  Project ID/GUID:  '00000000-0000-0000-0000-000000000000'
  System ID:  'libLAS'
  Generating Software:  'libLAS 1.2'
  Spatial Reference:
  Point Inspection Summary
  Header Point Count: 1287775
  Actual Point Count: 1287775

  Minimum and Maximum Attributes (min,max)
  Min X, Y, Z:   6066629.86, 2190053.45, -3.60
  Max X, Y, Z:   6070237.92, 2193507.74, 906.00
  Bounding Box:  6066629.86, 2190053.45, 6070237.92, 2193507.74
  Time:  0.000000, 0.000000
  Return Number:  1, 3
  Return Count:  1, 7
  Flightline Edge:  0, 0
  Intensity:  0, 256
  Scan Direction Flag:  0, 0
  Scan Angle Rank:  0, 0
  Classification:  2, 7
  Point Source Id:  0, 0
  User Data:  0, 0
  Minimum Color (RGB):  0 0 0 
  Maximum Color (RGB):  0 0 0 

  Number of Points by Return
  (1) 1225886  (2) 61430  (3) 459

  Number of Returns by Pulse
  (1) 30877  (2) 153  (5) 1225886  (6) 30706  (7) 153

  Point Classifications
  647337 Ground (2) 
  639673 Low Vegetation (3) 
  740 Building (6) 
  25 Low Point (noise) (7) 
  0 withheld
  0 keypoint
  0 synthetic

We see: no spatial reference system indicated!
Luckily we know from here that the projection is  NAD83(HARN) / North Carolina, LCC 2SP metric, EPSG code 3358). Furthermore we see:

  • Number of Points by Return: 3 (i.e., first, mid, last)
  • Point Classifications: the points are already classified as “Ground” (class 2),  “Low Vegetation” (3),  “Building” (6), and Low Point (noise) (class 7). Something to play with later.

Time to create a GRASS GIS location and import the LAS file.

2. 2. Creating a GRASS GIS location for the LAS file

Since we know the EPSG code of the projection, that’s an easy task. Please note that GRASS GIS can generate locations directly from SHAPE files (with .prj file), GeoTIFF and more.

We fire up GRASS GIS 7 and open the Location Wizard:


In the Location Wizard, we first define a name for the new location:


We select the “EPSG code” method for creating a new location:


You can search for “North Carolina” and select the EPSG code 3358 from the list:


Next summary should show up as follows (be sure to have the metric projection shown!):


With “Finish” you reach this notification (indeed, nothing to change! It is already fine):


Since we want to import the LAS file, no need to manually define any region extent here – just say “No”:


While we could import the data also into the PERMANENT mapset, we prefer to create an own mapset “lasdata” for our LAS data (once you reach hundreds of maps to manage, you will be happy about the concept of mapsets):


Voilà, we get back to the initial startup screen and can now start our GRASS GIS session with our “nc_nad83_lcc” location and “lasdata” mapset within the location: “Start GRASS”!


3. 3. Import of the LAS file

When creating a new location from a GeoTIFF or SHAPE file (or other GDAL supported format), then the data set is imported right away. This is not the case for LAS files, also due to the fact that we can directly apply binning statistics during import of the LAS file (e.g. percentiles, min or max) and create a raster surface from the points right away rather than importing them as vector points.

3. a) Creating a raster surface from LAS during import

The LAS import into a raster surface is available through


First the LAS file needs to be selected and an output file name specified (in this example, we want to extract the 95th percentile as binning method, hence a reasonable map name):


In the “Statistic” tab, we select the “percentile” method along with 95 as value:


In the “Optional” tab we activate to extend the computational region from the LAS file and, since the spatial reference system metadata are lacking from the LAS file, also “override dataset projection” to use that predefined in the location. Finally, we define 5m as desired raster resolution for the resulting raster map:


Upon conpletion of the import/binning, the new raster elevation map is shown after zooming to the map ( -e … restores upon completion the previous region settings, hence we may have to zoom):


Now we can start to analyze or visually explore the imported LAS file.

4. 4. Visual LiDAR data exploration

Using the wxNVIZ 3D viewer, we can easily fly through the new DEM. Switch in the Map Display to “3D view” (1). Note that the default rendering is initially done at low visual resolution for speed reasons. You can switch to “Rotate mode” as well to easily navigate with the mouse. In the “Data” tab (2) you can increase the visual resolution (3) to obtain a crisp view:



Now all kinds of analysis steps may follow.

5. Outlook

For true LiDAR processing as points, see the following GRASS GIS 7 modules: (for point import), v.lidar.correction, v.lidar.edgedetection, v.lidar.growing, v.outlier, and

Will the sun shine on us?

Recently, in order to nicely plan ahead for a birthday lunch at the agriturismo Malga Brigolina (a farm-restaurant near Sopramonte di Trento, Italy, at 1,000m a.s.l. in the Southern Alps), friends of mine asked me the day before:

Will the place be sunny at lunch time for making a nice walk?

[well, the weather was close to clear sky conditions but mountains are high here and cast long shadows in winter time].


A rather easy task I thought, so I got my tools ready since that was an occasion to verify the predictions with some photos! Thanks to the new EU-DEM at 25m I was able to perform the computations right away in a metric system rather than dealing with degree in LatLong.

Direct sunlight can be assessed from the beam radiation map of GRASS GIS’ r.sun when running it for a specific day and time. But even easier, there is a new Addon for GRASS GIS 7 which calculates right away time series of insolation maps given start/stop timestamps and a time step: r.sun.hourly. This shrinks the overall effort to almost nothing.

1. Creating the direct sunlight maps

The first step is to calculate where direct sunlight reaches the ground. Here the input elevation map is the European “eu_dem_25”, while the output is the beam radiation for a certain day (15 Dec 2013 is DOY 349).

Important hint: the computational region must be large enough to east/south/west to capure the cast shadow effects of all relevant surrounding mountains.

I let calculations start at 8am and finish at 5pm which an hourly time step. The authors have kindly parallelized r.sun.hourly, so I let it run on four processors simultaneously to speed up:

# calculate DOY (day-of-year) from given date:
date -d 2013-12-15 +%j

# calculate beam radiation maps for a given time period
# (note: minutes are to be given in decimal time: 30min = 0.5)
r.sun.hourly elev_in=eu_dem_25 beam_rad=trento_beam_doy349 \
      start_time=8 end_time=17 time_step=1 day=349 year=2013 \

The ten resulting maps contain the beam radiation for each pixel considering the cast shadow effects of the pixel-surrounding mountains. However, the question was not to calculate irradiance raster maps in Wh/m^2 but simply “sun-yes” or “sun-no”. So a subsequent filtering had to be applied. Each beam radiation map was filtered: if pixel value equal to 0 then “sun-no”, otherwise “sun-yes” (what my friends wanted to achieve; effectively a conversion into a binary map).
Best done in a simple shell script loop:

[Edit 30 Dec 2013: thanks to Anna you can simplify below loop to the r.colors call thanks to the new -b flag for binary output in r.sun.hourly!]

for map in `g.mlist rast pattern="trento_beam_doy349*"` ; do
    # rename current map to tmp
    g.rename rast=$map,$map.tmp
    # filter and save with original name
    r.mapcalc "$map = if($map.tmp == 0, null(), 1)"
    # colorize the binary map
    echo "1 yellow" | r.colors $map rules=-
    # remove cruft
    g.remove rast=$map.tmp

As a result we got ten binary maps, ideal for using them as overlay with shaded DEMs or OpenStreetMap layers. The areas exposed to direct sunlight are shown in yellow.

Trento direct sunlight 15 Dec 2013 Animation

Trento, direct sunlight, 15 Dec 2013 between 10am and 5pm (See here for creating an animated GIF). Quality reduced for this blog.

2. Time to look at some details: So, is Malga Brigolina in sunlight at lunch time?

Situation at 12pm (noon): predicted that the restaurant is still in shadow – confirmed in the photo:


(click to enlarge)

Situation at 1:30/2:00pm: sun is getting closer to the Malga, as confirmed in photo (note that the left photo is 20min ahead of the map). The small street in the right photo is still in the shadow as predicted in the map):

malga_brigolina_direct_sunlight_15dec2013_14pm_foto(click to enlarge)

Situation at 3:00pm: sun here and there at Malga Brigolina:

malga_brigolina_direct_sunlight_15dec2013_15pm_3DSunlight map blended with OpenStreetmap layer (r.blend + r.composite) and draped over DEM in wxNVIZ of GRASS GIS 7 (click to enlarge). The sunday walk path around Malga Brigolina is the blue/red vector line shown in the view center.

Situation at 4:00pm: we are close to sunset in Trentino… view towards the Rotaliana (Mezzocorona, S. Michele all’Adige), last sunlit summits also seen in photo:

rotaliana_direct_sunlight_15dec2013_16pm_foto(click to enlarge)

3. Outcome

The resulting sunlight/shadow map appear to match nicely realty. Perhaps r.sun.hourly should get an additional flag to generate the binary “sun-yes” – “sun-no” maps directly.

trento_direct_sunlight_15dec2013_15pm_3DDirect sunlight zones (yellow, 15 Dec 2013, 3pm): Trento with Monte Bondone, Paganella, Marzolan, Lago di Caldonazzo, Lago di Levico and surroundings (click to enlarge)

4. GRASS GIS usage note

The wxGUI settings were as simple as this (note the transparency values for the various layers):


Data sources:

Video: GRASS GIS development visualization from 1999 to 2013

Watch how the community based GRASS GIS 6.4 software development evolved! You can see how the individual contributors modify and expand the source code:

  • Dec 29, 1999: GRASS GIS 5.0 is being stored in an online source code repository in December 1999…
  • Dec 02, 2000: The developers work on all parts of the code…
  • Jan 15, 2002: Working on the future GRASS GIS 5.1 release
  • Nov 25, 2002: Starting GRASS 5.1 development with code restructuring
  • Jun 14, 2004: GRASS GIS 5.7 released in June 2004
  • Nov 09, 2004: Source code restructuring to get a better directory layout (all other developers waiting…)
  • Nov 09, 2004: … thousands of files are modified in this operation …
  • Nov 10, 2004: All developers resume their activities after the restructuring
  • Jan 10, 2005: Preparing the GRASS GIS 6.0.0 release…
  • Apr 09, 2005: GRASS GIS 6.0.0 published, release branch being split off from trunk for easier maintenance
  • Feb 22, 2006: Release of GRASS GIS 6.0.2 and new source code refactoring startedApr 05, 2006: Heavy development activity in trunk (development branch) …
  • Oct 25, 2006: GRASS GIS 6.2.0 released in October 2006
  • Apr 10, 2007: Preparing the GRASS GIS 6.2.2 release…
  • Jun 16, 2007: GRASS GIS 6.2.2 released in June 2007
  • Nov 01, 2007: Raster and vector modules being actively maintained…
  • Apr 02, 2007: New graphical user interface development speeding up (wxGUI)
  • Feb 20, 2008: Copyright statements prettified in many files
  • May 31, 2008: New GRASS 6 development branch being split off from trunk (which becomes GRASS 7)
  • Jun 10, 2008: Developers moving over to new branch
  • Feb 23, 2009: GRASS 6.4 release branch split off from GRASS 6 development branch
  • Apr 03, 2009: GRASS GIS 6.4 preparations starting…
  • Feb 24, 2010: Intense maintenance in GRASS 6.4 release branch
  • Sep 15, 2010: GRASS GIS 6.4.0 released in September 2010
  • Apr 12, 2011: GRASS GIS 6.4.1 released in April 2011
  • Jun 27, 2011: GRASS GIS 6.4.svn matures for the upcoming 6.4.2 release
  • Aug 16, 2011: Intense maintenance in GRASS 6.4 release branch (GRASS GIS 7 development not shown here)…
  • Feb 19, 2012: GRASS GIS 6.4.2 released in February 2012
  • Nov 13, 2012: Backporting graphical user interface bugfixes from GRASS GIS 7 to GRASS GIS 6.4
  • Apr 17, 2013: Further maintenance in GRASS 6.4 release branch
  • Jul 10, 2013: Fixing odds ‘n ends for the new stable release
  • Jul 27, 2013: GRASS GIS 6.4.3 released in July 2013

The corresponding timeline is also available at


Rendering: Markus Neteler
Audio track editing: Duccio Rocchini & Antonio Galea

Le bruit peut rendre sourd – Track 6/18 Album “Sensation electronique” by Saelynh (CC-BY-NC-ND)

Software used:
Gource software: (GPL)
OpenShot video editor: (GPL