Category Archives: Linux

Fun with docker and GRASS GIS software

GRASS GIS and dockerSometimes, 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
# 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):

# 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

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.


Compiling OTB Orfeo ToolBox software on Centos/Scientific Linux

The Orfeo ToolBox (OTB), an open-source C++ library for remote sensing images processing, is offering a wealth of algorithms to perform Image manipulation, Data pre-processing, Features extraction, Image Segmentation and Classification, Change detection, Hyperspectral processing, and SAR processing.

Since there is no (fresh) RPM package available for Centos or Scientific Linux, here some quick hints (no full tutorial, though) how to get OTB easily locally compiled. We are following the Installation Chapter.

Importantly, you need to have some libraries installed including GDAL. Be sure that it has been compiled with the “–with-rename-internal-libtiff-symbols” and ” –with-rename-internal-libgeotiff-symbols” flags to avoid namespace collision a.k.a segmentation fault of OTB as per “2.2.4 Building your own qualified Gdal“. We’ll configure and build with the GDAL-internal Tiff and Geotiff libraries that supports BigTiff files

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

The compilation of the OTB source code requires “cmake” and some other requirements which you can install via “yum install …”. Be sure to have the following structure for compiling OTB, i.e. store the source code in a subdirectory. The binaries will then be compiled in a “build” directory parallel to the OTB-SRC directory:

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

Now it is time to configure everything for OTB. Since I didn’t want to bother with “ccmake”, below the magic lines to compile and install OTB into its own subdirectory within /usr/local/. We’ll use as many internal libraries as possible according to the table in the installation guide. The best way is to save the following lines as a text script “” for easier (re-)use, then run it:


mkdir -p build
cd build

cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr/local/otb-$OTBVER \

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

That’s it!

In order to use the freshly compiled OTB, be sure to add the new directories for the binaries and the libraries to your PATH and LD_LIBRARY_PATH variables, e.g. in $HOME/.bashrc:

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/

Enjoy OTB! And thanks to the OTB developers for making it available.

Compiling QGIS 2.0.1 for Fedora 19 in a few steps

Thanks to Volker Fröhlich’s efforts, a source code RPM package (SRPM) of QGIS 2.0.1 is now available for Fedora. If you are not yet F20 user (like me), you can just take the F20 package and compile it for F19 (or even F18) since there will be no backport of QGIS 2 to F19 (it comes with QGIS 1.8). But: we do want QGIS 2 on Fedora19!

Solution: compile it yourself.

1. 1. Preparations

The best way is  to use “mock” which is used to recompile SRPMS in a separate local environment (“chroot”) without cluttering the system with extra packages needed for the compilation (run as “root”):

yum install mock

2. 2. Get the source code

Next download the SRPM package from the Koji  server:
QGIS: (–> src – download) or check here for more recent versions.

3. 3. Compile it locally as RPM package

The general compilation command (“mock”) would be:

mock -r my_fedora_version_config --rebuild my_source_rpm.src.rpm

So, check for Fedora version config name which is suitable for your system (“my_fedora_version_config“)

ls /etc/mock/

In my case of a 64bit machine, it is “fedora-19-x86_64”. Hence we can compile QGIS 2.0.1 directly from the SRPM file:

mock -r fedora-19-x86_64 --rebuild qgis-2.0.1-2.fc20.src.rpm

Note: the compilation takes 40min on my tiny core i3 laptop (ASUS X202). Use the time to donate some coins to the QGIS project 🙂

4. 4. Install and enjoy

Once the compilation job is done, i.e. the binary RPM files are available for installation. To install the freshly compiled QGIS 2.0.1 RPMs, run:

cd /var/lib/mock/fedora-19-x86_64/result/

# an existing QGIS1.8 installation will be replaced: 
yum localinstall qgis-2.0.1-2.fc19.x86_64.rpm \
qgis-grass-2.0.1-2.fc19.x86_64.rpm qgis-python-2.0.1-2.fc19.x86_64.rpm

# consider to cleanup (or keep it for the next update, it is about 1.5GB):
rm -rf /var/lib/mock/fedora-19-x86_64/
# leave the "root" shell

Now we can happily use QGIS 2.0.1 on Fedora 19!



Scaling up globally: 30 years of FOSS4G development

Scaling up globally: 30 years of FOSS4G development. Keynote at FOSS4G-CEE 2013, Romania

In my presentation I briefly review 3 decades of Open Source GIS development, from the ’80th to the present.

City of Munich administration switches to OpenDocument Format

In Munich, Germany, the OpenDocument Format (ODF) has become the main document exchange standard, along with the PDF format for non-editable files. This is a milestone in the ongoing migration project to Open Source (LiMux project) and a major improvement for the long-term interoperability. In 2012, 80% of the totally 14,000 computers in in the administration will be migrated to Linux.

Also the German Federal Foreign Office and the Federal Office for Information Security (BSI) are migrating to Open Source.

Read more here.