I’m not Scaramanga (maybe a little bit of Nick Nack) but anyway, this article could be be a golden bullet for helping you to eliminate a lot of obstacles if you are using QGIS in some kind of class-room setup, networked environment and/or are struggling with the “new versions 3 times a year” policy of QGIS.

My interest for a hassle free and fast installation of QGIS stems from an experience last year: Some colleagues and I was giving a QGIS workshop for attendants from all over the world. We were told that QGIS was installed on all the computers in the “out-of-town” computer lab and indeed, the computers we checked had a working installation of QGIS. Next day, 15 minutes before the workshop should start, we discovered that the QGIS installations was either non-existent or badly mangled on a large portion of the rest of the computers. And no person with “local admin” rights within sight. It would be an understatement to say that the first hour of the workshop was an interesting time for us. Well, all’s well that ends well, and in the end the workshop was a success (Lucky us!)

A couple of months later I stumbled on this article “A QGIS class room setup on Windows ” – thanks to Richard Duivenvoorde – and tried the setup by copying the qgis program directory from the initial install to another “clean” computer. Alas, QGIS did work on some – but not on all of the computers, I tried it on. The QGIS installation had some dependencies to dll’s in the windows/system32 directory. If they already were present, the “copy” installation would work but otherwise it would fail. I discovered a somewhat complicated solution to the problem and publicized it in the article “How to make a ‘QGIS on a stick’ implementation”

Then, some weeks ago at the “QGIS 2015 conference at Nødebo“, I had a chat with QGIS core developer Jürgen E. Fischer about my installation problems and viola! Two days after the chat, the OSGEO4W network installation contained the missing dll’s, Thanks Jürgen.

So now we have two bits of information:

• By using the “–configpath” qualifier we can redirect where QGIS is looking for plugins, user selected values for options, values and files normally saved in the .qgis2 directory or in the registry.
• The OSGeo4W network installation creates QGIS without any dependencies to external dll’s outside the installation directory. You could make an installation by simply copy an existing QGIS program directory to another computer.

This gives us some interesting possibilities:

• Use case I : “QGIS on a stick”
  You can make a QGIS installation located on a memory stick and completely self contained; simply plug in the stick into a Windows computer and start QGIS by double clicking on the QGIS startup file.
• Use case II: “Simple ‘xcopy’ installation of QGIS”
  Make an installation procedure for QGIS that consists of a simple copy of the QGIS program directory to a new computer. Like the answer to: “How the heck am I going to install QGIS on 24 computers in half an hour ?”
• Use case III: “Network install of QGIS with floating profiles”
  Install QGIS on a network file share and put the QGIS setup information into the “Floating profile”. A large part of a user profile including will be cached on a central server in the windows domain. If the user logs on to another computer than the usual, his/her profile will automatically be copied to the new computer, giving the user his “normal” desktop and setups.
• Use case IV: “QGIS on Citrix”
  Normally it ain’t my cup of tea to install any kind of program on a Citrix server where the program has a “canvas” area with fast changing images/pixels. For example: A GIS program like QGIS showing a map with an orthofoto background with millions of pixels – all with a slightly different hues of greens or browns.
  However, many IT departments swears by Citrix, so….
• Use Case V: “Smart installation and update of a large amount of QGIS installations”
  If you have to install QGIS on dozens or hundreds of computers and keep the installation up-to-date, this is the use-case for you.

Step 1: Creating the common template..

First you have to create a common template for your future installation(s) whatever use case you implement afterwards. I use the 32-bit edition of the network installation as a basis for this although it’s perfectly possible to use the 64 bit version.

1. Browse to http://qgis.org/en/site/forusers/download.html and click on OSGeo4W Network installer (32 bit) . This will download the installer.
2. Start the installer and choose “Express Desktop Install”.
3. Check “QGIS” and uncheck everything else.
4. Check “I agree yadda yadda…” to every license message.This will install a default QGIS installation in directory C:\OSGeo4W and create a QGIS user directory in C:\Users\<my username>\.qgis2, i.e. the directory .qgis2 in your home directory. These 2 directories is the basis for the template. You can check the installation by starting QGIS from the “OSGeo4W” program group in “Start” –> “All Programs”. It should work without problems.
5. Copy the C:\Users\<my username>\.qgis2 directory with contents to C:\OSGeo4W, so you’ll have a C:\OSGeo4W\.qgis2 directory.
6. Copy the startup file for QGIS: C:\OSGeo4W\bin\QGIS.bat to C:\OSGeo4W\bin\QGIS.ref. This is insurance ! If you utterly mangle QGIS.bat in the next steps you have this file as a backup. Otherwise you are not going to use it for anything.
7. Edit the file: C:\OSGeo4W\bin\QGIS.bat with a simple text editor like notepad.
   Insert 2 lines between line 2 and 3 in the bat file:

   call “%~dp0\o4w_env.bat”
   call “%OSGEO4W_ROOT%”\apps\grass\grass-6.4.4\etc\env.bat

   so it looks like this:

   call “%~dp0\o4w_env.bat”

   set QGIS_OAS=”%OSGEO4W_ROOT%”\.qgis2
   if exist “%OSGEO4W_ROOT%”\bin\QGIS_OAS.bat call “%OSGEO4W_ROOT%”\bin\QGIS_OAS.bat

   call “%OSGEO4W_ROOT%”\apps\grass\grass-6.4.4\etc\env.bat

   and replace the last line in the bat file:

   start “QGIS” /B “%OSGEO4W_ROOT%”\bin\qgis-bin.exe %*

   with this line:

   start “QGIS” /B “%OSGEO4W_ROOT%”\bin\qgis-bin.exe –configpath %QGIS_OAS% %*

   and save the result.

   What the edits mean:

   • Create an environment variable %QGIS_OAS% which works as a pointer to the location of the .qgis2 directory. Initially it points to the .qgis2 directory inside the OSGeo4W installation directory we created in (5).
   • Execute a command-file “QGIS_OAS.bat” if it exists. This command-file is the basis for all our different use-cases. There will be a different version for each use-case. Initially we don’t use this file.
   • Add the “–configpath %QGIS_OAS% qualifier to the actual start of QGIS. This means, that QGIS will look for all setup information, user-defined options, plugins and whatnot in the directory specified by the %QGIS_OAS% environment variable. And QGIS will not use any settings in the registry.
8. Start QGIS by double clicking the revised C:\OSGeo4W\bin\QGIS.bat file and make all the changes to the initial setup of QGIS that should be included in your future QGIS installation(s). This could be change of language, default projection, extra plugins, snap options, yadda yadda yadda. Come on, make you dream QGIS setup !!

Thanks to the –configpath qualifier now on the start line for QGIS all these changes will be saved in the C:\OSGeo4W\.qgis2 directory. After this, you have a complete setup of QGIS – with your own changes – all located in the C:\OSGeo4W directory. This is the common template for all use cases.

Step 2: Do one of the use cases…

Use case I : “QGIS on a stick “

You have already done this use case. The template made in step 1 is a ready made “QGIS on a stick” installation:

1. Copy the entire C:\OSGeo4W template directory from your computer to the root of your memory stick.
2. Insert the memory stick into any Windows computer and start QGIS by double clicking on \OSGeo4W\bin\qgis.bat on the memory stick.
   QGIS will use \OSGeo4W\.qgis2 on the memory stick as the QGIS user directory.

Use case II : “Simple ‘xcopy’ installation of QGIS “

In this use case we will have to extend the template by creating the QGIS_OAS.bat file. This example will put the QGIS user directory “.qgis2” in the users home directory, just like the normal installation does – with one exception: This installation will not use the registry but save all user options in a ini-file placed in the QGIS user directory.

1. Create the file C:\OSGeo4W\bin\QGIS_OAS.bat with the following content:
   

   set QGIS_OAS=”%USERPROFILE%”\.qgis2
   if exist %QGIS_OAS% exit /B
   xcopy “%OSGEO4W_ROOT%”\.qgis2 %QGIS_OAS% /e /i
   nircmd shortcut “””%OSGEO4W_ROOT%””\bin\qgis.bat” “~$folder.desktop$” “Start QGIS” “” “””%OSGEO4W_ROOT%””\bin\qgis-bin.exe” “0” “min” “””%OSGEO4W_ROOT%””\bin” “”

   (First the pointer to the QGIS user directory is changed to the “users home directory”\.qgis2. Secondly, The command file will check if the QGIS user directory exists in the users home directory. If it doesn’t exist, the command file will create a copy of the QGIS user directory template into the users home directory; create a shortcut to start QGIS and place this shortcut on the user’s desktop.)

2. You can now install QGIS on a new PC by copying the entire C:\OSGeo4W directory to the new pc (using a memory-bird, network drive, zip-copy-unzip, whatever). The directory can be copied to any directory location on the new PC. Please note that some locations will require “local admin” rights for creating the new directory, for example if you copy it to “C:\Program Files”. I usually try the avoid this.

First time use on the new pc:

• Start QGIS by double clicking on C:\OSGeo4W\bin\qgis.bat (or wherever you placed the OSGeo4W directory). When QGIS starts, the combined command files QGIS.BAT and QGIS_OAS.BAT will automatically create the QGIS user directory on the new pc; create a shortcut to QGIS on the user desktop and start QGIS.

After that you can start QGIS by double clicking on the shortcut placed on the desktop.

Use case III: “Network install of QGIS with floating profiles ”

This usage scenario will have the QGIS installation located in a directory on a common network file-share. A normal user need only to have read and execute rights to this directory. The QGIS user directory will be placed in the users “roaming profile” on the client PC, a special region which is cached to a central server.

The computers and users are members of a AD domain. If the user logs on to another pc in the domain, the “roaming profile”, including the desktop and the QGIS user directory, will automatically be copied the new computer and the user will see the usual desktop and applications.

With this setup, there is no dependencies to any particular client pc after the first start of QGIS by the user. If the user logs on any other client PC in the domain it will be possible for her to start QGIS simply by double clicking on the QGIS shortcut on desktop.

There is some requirements: The user has to have access to the common file share (!) and the network connection has to be stable and relatively fast.

In this use case we will do the following:

1. Copy the QGIS directory C:\OSGeo4W to the common share: X:\QGIS\Current (The drive letter X: is arbitrary; it could be any drive letter). I will explain the naming scheme of the directory later.
2. Create the file X:\QGIS\Current\bin\QGIS_OAS.bat with the following content
   

   set QGIS_OAS=”%APPDATA%”\.qgis2
   if exist %QGIS_OAS% exit /B
   xcopy “%OSGEO4W_ROOT%”\.qgis2 %QGIS_OAS% /e /i
   nircmd shortcut “””%OSGEO4W_ROOT%””\bin\qgis.bat” “~$folder.desktop$” “Start QGIS” “” “””%OSGEO4W_ROOT%””\bin\qgis-bin.exe” “0” “min” “””%OSGEO4W_ROOT%””\bin” “”

   (First, The QGIS_OAS environment variable points to the qgis user directory in the roaming profile. Secondly, the command file will check if the QGIS user directory exists. If it doesn’t, the command file will copy the QGIS user directory template to the users roaming profile; create a shortcut to start QGIS and place this shortcut on the user desktop.)

First time use on the new pc:

• Start QGIS by double clicking on X:\QGIS\Current\bin\qgis.bat. When QGIS starts, the combined command files QGIS.BAT and QGIS_OAS.bat will automatically create the QGIS user directory on the new pc, create a shortcut on the user desktop and start QGIS.
• After the first time you start QGIS by double clicking on the shortcut placed on the desktop.

Oh .. and why did I use this particular naming scheme for the directory ? It is used to make it easy to update QGIS:

When you have a new version of QGIS, do the following:

1. Make a template of the new qgis version as described in step 1 and use case III, but in another directory: X:\QGIS\Testing and leave the X:\QGIS\Current unchanged.
2. Test the new installation. You might even let some of your users test it!! You can start the “testing” version of QGIS by double clicking on X:\QGIS\Testing\bin\qgis.bat
3. When you are satisfied with the new installation:
   • Rename the directory X:\QGIS\Current to X:\QGIS\Deprecated
   • Rename the directory X:\QGIS\Testing to X:\QGIS\Current 

After the last rename operation all the networked users will execute the new version using their existing shortcut. This method will probably work with all minor updates (2.8 -> 2.10), but probably not with a major update (2.10 -> 3.0)

Use case IV : “QGIS on Citrix “

If you have a Citrix environment you probably have a personal network-based share for each an every user on the domain. For this use case I call this directory M:\Personal. But the naming convention can be anything.

The idea is to place the QGIS user directory on the personal network share, so there won’t be anything saved or registered on the Citrix server that’s user related:

Do the following:

1. Create a working installation of QGIS on the Citrix sever using the techniques described in Step 1.
2. Create the file C:\OSGeo4W\bin\QGIS_OAS.bat on the Citrix server with the following content:
   

   set QGIS_OAS=M:\Personal\.qgis2
   if exist %QGIS_OAS% exit /B
   xcopy “%OSGEO4W_ROOT%”\.qgis2 %QGIS_OAS% /e /i

   (First, The QGIS_OAS environment variable points to the qgis user directory placed on the users personal network share. In this case “M:\Personal”. Secondly, the command file will check if the QGIS user directory exists. If it doesn’t, the command file will copy the QGIS user directory template to the users personal network share.)

3. Create the usual application startup definition for Citrix pointing to C:\OSGeo4W\bin\QGIS.bat on the Citrix server.

Bingo ! That’s it. I’ll leave the last use case “Smart installation and update of a large amount of QGIS installations” to a separate article, because it is more complicated than any of the previous use cases. I’ll try to publish that article in a week or so, so stay tuned !!

This article has a zip file “QgisOnAStick.zip” attached. It contains the revised QGIS.BAT file plus all the different types of QGIS_OAS bat files described in the article. The suffix is renamed to “.usecase_1”, “.usecase_2” and so on. Download the zip file and rename the suffix to “.bat” on the files you’re going to use.

A final note: I’ve used QGIS 2.8.2 in my tests. So the use cases works for this version of QGIS and will probably work for other QGIS 2.x versions.

Regards

Bo Victor Thomsen

[email protected]
AestasGIS
Denmark

Sometimes, we developers get reports via mailing list that this & that would not work on whatever operating system. Now what? Should we be so kind and install the operating system in question in order to reproduce the problem? Too much work… but nowadays it has become much easier to perform such tests without having the need to install a full virtual machine – thanks to docker.

Disclaimer: I don’t know much about docker yet, so take the code below with a grain of salt!

In my case I usually work on Fedora or Scientific Linux based systems. In order to quickly (i.e. roughly 10 min of automated installation on my slow laptop) try out issues of GRASS GIS 7 on e.g., Ubuntu, I can run all my tests in docker installed on my Fedora box:

# we need to run stuff as root user
su
# Fedora 21: install docker 
yum -y docker-io

# Fedora 22: install docker
dnf -y install docker

# enable service
systemctl start docker
systemctl enable docker

Now we have a running docker environment. Since we want to exchange data (e.g. GIS data) with the docker container later, we prepare a shared directory beforehand:

# we'll later map /home/neteler/data/docker_tmp to /tmp within the docker container
mkdir /home/neteler/data/docker_tmp

Now we can start to install a Ubuntu docker image (may be “any” image, here we use “Ubuntu trusty” in our example). We will share the X11 display in order to be able to use the GUI as well:

# enable X11 forwarding
xhost +local:docker

# search for available docker images
docker search trusty

# fetch docker image from internet, establish shared directory and display redirect
# and launch the container along with a shell
docker run -v /data/docker_tmp:/tmp:rw -v /tmp/.X11-unix:/tmp/.X11-unix \
       -e uid=$(id -u) -e gid=$(id -g) -e DISPLAY=unix$DISPLAY \
       --name grass70trusty -i -t corbinu/docker-trusty /bin/bash

In almost no time we reach the command line of this minimalistic Ubuntu container which will carry the name “grass70trusty” in our case (btw: read more about Working with Docker Images):

root@8e0f233c3d68:/# 
# now we register the Ubuntu-GIS repos and get GRASS GIS 7.0
add-apt-repository ppa:ubuntugis/ubuntugis-unstable
add-apt-repository ppa:grass/grass-stable
apt-get update
apt-get install grass7

This will take a while (the remaining 9 minutes or so of the overall 10 minutes).

Since I like cursor support on the command line, I launch (again?) the bash in the container session:

root@8e0f233c3d68:/# bash
# yes, we are in Ubuntu here
root@8e0f233c3d68:/# cat /etc/issue

Now we can start to use GRASS GIS 7, even with its graphical user interface from inside the docker container:

# create a directory for our data, it is mapped to /home/neteler/data/docker_tmp/
# on the host machine 
root@8e0f233c3d68:/# mkdir /tmp/grassdata
# create a new LatLong location from EPSG code
# (or copy a location into /home/neteler/data/docker_tmp/)
root@8e0f233c3d68:/# grass70 -c epsg:4326 ~/grassdata/latlong_wgs84
# generate some data to play with
root@8e0f233c3d68:/# v.random n=30 output=random30
# start the GUI manually (since we didn't start GRASS GIS right away with it before)
root@8e0f233c3d68:/# g.gui

Indeed, the GUI comes up as expected!

GRASS GIS 7 GUI in docker container

You may now perform all tests, bugfixes, whatever you like and leave the GRASS GIS session as usual.
To get out of the docker session:

root@8e0f233c3d68:/# exit    # leave the extra bash shell
root@8e0f233c3d68:/# exit    # leave docker session

# disable docker connections to the X server
[root@oboe neteler]# xhost -local:docker

To restart this session later again, you will call it with the name which we have earlier assigned:

[root@oboe neteler]# docker ps -a
# ... you should see "grass70trusty" in the output in the right column

# we are lazy and automate the start a bit
[root@oboe neteler]# GRASSDOCKER_ID=`docker ps -a | grep grass70trusty | cut -d' ' -f1`
[root@oboe neteler]# echo $GRASSDOCKER_ID 
[root@oboe neteler]# xhost +local:docker
[root@oboe neteler]# docker start -a -i $GRASSDOCKER_ID

### ... and so on as described above.

Enjoy.

The post Fun with docker and GRASS GIS software appeared first on GFOSS Blog | GRASS GIS Courses.

The post GRASS GIS 6.4.5RC1 released appeared first on GFOSS Blog | GRASS GIS Courses.

# EPEL7:
yum -y install epel-release
yum -y install wget
# https://copr.fedoraproject.org/coprs/neteler/python-OWSLib/
wget -O /etc/yum.repos.d/neteler-python-OWSLib-epel-7.repo https://copr.fedoraproject.org/coprs/neteler/python-OWSLib/repo/epel-7/neteler-python-OWSLib-epel-7.repo
yum -y update
yum -y install python-OWSLib
wget -O /etc/yum.repos.d/qgis-epel-7.repo https://copr.fedoraproject.org/coprs/neteler/QGIS-2.8-Wien/repo/epel-7/neteler-QGIS-2.8-Wien-epel-7.repo
yum update
yum install qgis qgis-grass qgis-python qgis-server

# Fedora 20:
wget -O /etc/yum.repos.d/qgis-epel-7.repo https://copr.fedoraproject.org/coprs/neteler/QGIS-2.8-Wien/repo/fedora-20/neteler-QGIS-2.8-Wien-fedora-20.repo
yum update
yum install qgis qgis-grass qgis-python qgis-server

# Fedora 21:
wget -O /etc/yum.repos.d/qgis-epel-7.repo https://copr.fedoraproject.org/coprs/neteler/QGIS-2.8-Wien/repo/fedora-21/neteler-QGIS-2.8-Wien-fedora-21.repo
yum update
yum install qgis qgis-grass qgis-python qgis-server

The post Inofficial QGIS 2.8 RPMs for EPEL 7: Fedora 20, Fedora 21, Centos 7, Scientific Linux 7 appeared first on GFOSS Blog | GRASS GIS Courses.

# configure GDAL
./configure \
 --without-libtool \
 --with-geotiff=internal --with-libtiff=internal \
 --with-rename-internal-libtiff-symbols=yes \
 --with-rename-internal-libgeotiff-symbols=yes \
...
make
make install

OTB-4.4.0/
|-- build/
`-- OTB-SRC/
    |-- Applications/
    |-- CMake/
    |-- CMakeFiles/
    |-- Code/
    |-- Copyright/
    |-- Examples/
    |-- Testing/
    `-- Utilities/

#!/bin/sh

OTBVER=4.4.0
(
mkdir -p build
cd build

cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr/local/otb-$OTBVER \
      -DOTB_USE_EXTERNAL_ITK=OFF -DOTB_USE_EXTERNAL_OSSIM=OFF \
      -DOTB_USE_EXTERNAL_EXPAT=OFF -DOTB_USE_EXTERNAL_BOOST=OFF \
      -DOTB_USE_EXTERNAL_TINYXML=OFF -DOTB_USE_EXTERNAL_LIBKML=OFF \
      -DOTB_USE_EXTERNAL_MUPARSER=OFF \
       ../OTB-SRC/

make -j4
# note: we assume to have write permission in /usr/local/otb-$OTBVER
make install
)

export PATH=$PATH:/usr/local/bin:/usr/local/otb-4.4.0/bin
export LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64/:/usr/local/otb-4.4.0/lib/otb/

The post Compiling OTB Orfeo ToolBox software on Centos/Scientific Linux appeared first on GFOSS Blog | GRASS GIS Courses.

The post New stable release of GRASS GIS 7.0.0! appeared first on GFOSS Blog | GRASS GIS Courses.

The post Happy 9th Birthday, OSGeo! appeared first on GFOSS Blog | GRASS GIS Courses.

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:
v.in.region box_latlong_10deg
exit

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.

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).

The post GRASS GIS 7: Vector data reprojection with automated vertex densification appeared first on GFOSS Blog | GRASS GIS Courses.

The post Landsat 8 captures Trentino in November 2014 appeared first on GFOSS Blog | GRASS GIS Courses.

The post QGIS 2.6 ‘Brighton’ released appeared first on GFOSS Blog | GRASS GIS Courses.

# 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

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)"

# 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

The post Selective data removal in an elevation map by means of floodfilling appeared first on GFOSS Blog | GRASS GIS Courses.

The post Rendering a brain CT scan in 3D with GRASS GIS 7 appeared first on GFOSS Blog | GRASS GIS Courses.

In order to explore all the new interfaces to PostGIS (from QGIS, GDAL, GRASS GIS 7 and others) I decided to install PostGIS 2.1 on my Fedora 20 Linux box. Eventually it is an easy job but I had to visit a series of blogs to refresh my dark memories from past PostGIS installations done some years ago… So, here the few steps:

# become root
su -
# grab the PostgreSQL 9.3 server and PostGIS 2.1
yum install postgresql-server postgresql-contrib postgis

Now the server is installed but yet inactive and not configured. The next step is to initialize, configure and start the PostgreSQL server:

# initialize DB:
postgresql-setup initdb
# start at boot time:
chkconfig postgresql on
# fire up the daemon:
service postgresql start

A test connection will show that we need to configure TCP/IP connections:

# this will fail
psql -l
psql: could not connect to server: No such file or directory
    Is the server running locally and accepting
    connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

So we enable TCP/IP connections listening on port 5432:

# edit "postgresql.conf" with editor of choice (nano, vim, ...),
# add line "listen_addresses = '*'":
vim /var/lib/pgsql/data/postgresql.conf
...
listen_addresses = '*'
#listen_addresses = 'localhost'         # what IP address(es) to listen on;
...

Now restart the PostgreSQL daemon:

# restart to re-read configuration
service postgresql restart

Check if the server is now listening on TCP/IP:

# check network connections:
netstat -l | grep postgres
tcp        0      0 0.0.0.0:postgres        0.0.0.0:*               LISTEN     
tcp6       0      0 [::]:postgres           [::]:*                  LISTEN     
unix  2      [ ACC ]     STREAM     LISTENING     2236495  /var/run/postgresql/.s.PGSQL.543

So far so nice. Still PostGIS is not yet active, and we need a database user “gisuser” with password:

# switch from root user to postgres user:
su - postgres
# create new DB user with password (will prompt you for it, choose a strong one):
createuser --pwprompt --encrypted gisuser

Finally we create a first database “gis”:

# create new DB
createdb --encoding=UTF8 --owner=gisuser gis

We enable it for PostGIS 2.1:

# insert PostGIS SQL magic (it should finish with a "COMMIT"):
psql -d gis -f /usr/share/pgsql/contrib/postgis-64.sql

That’s it! Now exit from the “postgres” user account a the “root” account:

# exit from PG user account (back to "root" account level):
exit

In case you want to reach the PostgreSQL/PostGIS server from outside your machine (i.e. from the network), you need to enable PostgreSQL for that:

# enable the network in pg_hba.conf (replace host line; perhaps comment IP6 line):
vim /var/lib/pgsql/data/pg_hba.conf

...
host    all             all             all                     md5
...

# save and restart the daemon:
service postgresql restart

Time for another connection test:

# we try our new DB user account on the new database (hostname is the 
# name of the server in the network):
psql --user gisuser -h hostname -l
Password for user gisuser: xxxxxx

Wonderful, we are connected!

# exit from root account:
exit
[neteler@oboe ] $

Now have our PostGIS database ready!

What’s left? Get some spatial data in as a normal user:

# nice tool
shp2pgsql-gui

Using the shp2pgsql-gui

Next pick a SHAPE file and upload it to PostGIS with “Import”.

Now connect to your PostGIS database with QGIS or GRASS GIS and enjoy!

See also: https://fedoraproject.org/wiki/PostgreSQL

The post Installing PostGIS on Fedora 20 appeared first on GFOSS Blog | GRASS GIS Courses.

The post GDAL/OGR 1.11.0 released appeared first on GFOSS Blog | GRASS GIS Courses.

The post Workshop at FOSS4G 2014: Spatio-temporal data handling and visualization in GRASS GIS 7 appeared first on GFOSS Blog | GRASS GIS Courses.

Recently, in order to nicely plan ahead for a birthday lunch at the agritur 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 a nice walk?“

[well, the weather was close to clear sky conditions but mountains are high here and casting long shadows in the 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
349

# 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 \
      nprocs=4

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
done

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 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):

(click to enlarge)

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

Sunlight 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:

(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.

Direct 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:

• Shaded maps produced using Copernicus data and information funded by the European Union – EU-DEM layers
• © OpenStreetMap contributors

The post Will the sun shine on us? appeared first on GFOSS Blog | GRASS GIS Courses.

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
http://grass.osgeo.org/home/history/releases/

THANKS TO ALL CONTRIBUTORS!
http://grass.osgeo.org/development/

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

Music:
Le bruit peut rendre sourd – Track 6/18 Album “Sensation electronique” by Saelynh (CC-BY-NC-ND) http://www.jamendo.com/en/track/1236/le-bruit-peut-rendre-sourd

Software used:
Gource software: http://code.google.com/p/gource/ (GPL)
OpenShot video editor: http://www.openshotvideo.com/ (GPL

The post Video: GRASS GIS development visualization from 1999 to 2013 appeared first on GFOSS Blog | GRASS GIS Courses.

Inspired by Václav Petráš posting about “Did you know that you can see streets of downtown Raleigh in elevation data from NC sample dataset?” I wanted to try the new GRASS GIS 7 Addon r.shaded.pca which creates shades from various directions and combines then into RGB composites just to see what happens when using the new EU-DEM at 25m.

To warm up, I registered the “normally” shaded DEM (previously generated with gdaldem) with r.external in a GRASS GIS 7 location (EPSG 3035, LAEA) and overlayed the OpenStreetMap layer using WMS with GRASS 7′s r.in.wms. An easy task thanks to University of Heidelberg’s www.osm-wms.de. Indeed, they offer a similar shading via WMS, however, in the screenshot below you see the new EU data being used for controlling the light on our own:

OpenStreetMap shaded with EU DEM 25m (click to enlarge)

Next item: trying r.shaded.pca… It supports multi-core calculation and the possibility to strengthen the effects through z-rescaling. In my example, I used:

r.shaded.pca input=eu_dem_25 output=eu_dem_25_shaded_pca nproc=3 zmult=50

The leads to a colorized hillshading map, again with the OSM data on top (50% transparency):

OpenStreetMap shaded with r.shaded.pca using EU DEM 25m (click to enlarge)

Yes, fun – I like it

Data sources:

• Shaded maps produced using Copernicus data and information funded by the European Union – EU-DEM layers
• © OpenStreetMap contributors

The post Using the 25m EU-DEM for shading OpenStreetMap layers appeared first on GFOSS Blog | GRASS GIS Courses.

EU DEM 25m upper Garda Lake area with Riva del Garda and Arco (Italy). 3D view in wxNVIZ – GRASS GIS 7

The 25m European Digital Elevation Model (EU-DEM, Version 1) is a Digital Surface Model (DSM) representing the first surface as illuminated by the sensors:

EU DEM Rotaliana with Mezzocorona and S. Michele (Italy). Produced using Copernicus data and information funded by the European Union – EU-DEM layers.

Its elevations were captured at 1 arc second postings (2.78E-4 degrees). The tiles are provided at 25m resolution in EU-LAEA (EPSG. 3035) projection, temporal coverage: 2000, published in Oct 2013. It is a realisation of the Copernicus programme, managed by the European Commission, DG Enterprise and Industry. Metadata are provided here. According to their “Methodology” page it is a hybrid product based on SRTM and ASTER GDEM data fused by a weighted averaging approach and it has been generated as a contiguous dataset divided into 1 degree by 1 degree tiles, corresponding to the SRTM naming convention. In addition to the DEM data, a colour shaded relief image over Europe is provided.

From the metadata page: “The EU-DEM data are provided as is, i.e. without a formal validation yet. An independent statistical validation is scheduled as part of the GIO land monitoring service activities, and will be made available in the course of 2014.”

1. Data download

Note that the GeoTIFF files are of major size, up to 5 GB:

• Download GeoTIFF tiles by file name
• Download GeoTIFF tiles by map based selection

Hint for GRASS GIS users: instead of importing the data, you can use r.external to simply register the GeoTIFF file within a EU LAEA projected location.

The post EU-DEM: new Digital Surface Model at 25m appeared first on GFOSS Blog | GRASS GIS Courses.

GRASS GIS, commonly referred to as GRASS (Geographic Resources Analysis Support System), is the free Geographic Information System (GIS) software with the longest record of development as FOSS4G community project. The increasing demand for a robust and modern analytical free GIS led to the start of GRASS GIS 7 development in April 2008. Since GRASS 6 more than 10,000 changes have been implemented with a series of new modules for vector network analysis, image processing, voxel analysis, time series management and improved graphical user interface. The core system offers a new Python API and large file support for massive data analysis. Many modules have been undergone major optimization also in terms of speed. The presentation will highlight the advantages for users to migrate to the upcoming GRASS GIS 7 release.

The post News in GRASS GIS 7 appeared first on GFOSS Blog | GRASS GIS Courses.