Archiv für ‘GIS’

Oktober 28th, 2016

Solving the Shortest Path Problem (5) – Benchmarks

This article of 2012 at shows, that the type of the priority queue of a shortest path solver is crucial for the solving time.
You have to agree with that, but there is another point to mention: the choice of the graph representation.
I wanted to spend some more time on the comparison of the graph libraries LEMON and BGL and so I modified some of the code and ran the following tests on it.

The code was compiled using GCC 4.8.4 with the the following switches: -O2 -m64 -std=c++11. My test machine is a laptop with an Intel 4-Core i3@2,4 Ghz. You can download the graph instances from the DIMACS site.

BGL’s Dijkstra d-ary Heap (d=4)
Boost’s Graph Library offers two variants of a Dijkstra shortest path solver implementation. A regular one dijkstra_shortest_path and a variant that does not use an internal color map of nodes (dijkstra_shortest_path_no_color_map). Both of them use by default a d-ary Heap with d=4 which is actually a quad heap queue. Unfortunately there is no easy way to change the heap in the dijkstra implementation.

There is no significant difference comparing the solving time of each of them, if you do not change the graph structure.
Using the BGL with street networks you have two flavours of a graph: the widely known adjacency_list and a representation that you should look at if you’re dealing with sparse graphs as street networks are: the compressed_sparse_row_graph.

Here are the results.

weiterlesen »

Be the first to like.

Oktober 28th, 2016

Solving the Shortest Path Problem (4) – Comparison of LEMON and BGL

In the previous articles I explained the usage of the APIs of LEMON and Boost Graph Library (BGL). Now I want to sum up the differences of them. Of course this is very opinion-based.

1. Simplicity

LEMON has despite its template mechanism a clean and realtively simple interface. A few algorithms have predefined default template parameters which cover standard use cases. For example the Dijkstra Shortest Path solver uses a binary heap as priority queue.  The map concept of storing additional data on graphs is not very friendly regarding usability but is a guarantee for performance, because the core component only has to look after its internal IDs and not after some additional graph data.

By contrast you cannot say that the Boost BGL looks simple at first glance. I found it harder to understand, but it has flexibility to adapt changes. Especially the property map concept may be familiar to regular Boost users, but if you are new to this it’s not really clear.

2. Flexibility

The API of LEMON is flexible enough to change the many parameters of graphs, algorithms or internal structures like the heap type. Unfortunately there is little documentation on these advanced operations.

What I liked working with the BGL was the bundled property mechanism where you can „inject“ your custom class and convert that to some node or arc property. I missed in BGL the ability to change the heap type for the shortest path dijkstra. A big plus in my opinion is the so called visitor concept in the BGL. You are able to specify a visitor that allows custom functions in a standard algorithm, e.g. stopping the execution of the dijkstra algorithm at a certain total distance. But again implementing this is not an easy task.

So this time it’s a draw.

3. Algorithms

Both of the two libraries offer a huge list of graph algorithms if you are not only interested in shortest path algorithms.

Again the score is even in my opinion.

So to sum these things up, I enjoy using LEMON more. But what about the performance? I will write an extra article about this.


1 andere Person mag diesen Artikel.

Oktober 27th, 2016

Solving the Shortest Path Problem (3) – Boost Graph Library

Boost Graph Library
The Boost Graph library (BGL) is a part of the famous Boost library.

C++ Boost
The BGL graph interface and graph components are generic, in the same sense as the Standard Template Library (STL).

As LEMON the BGL also relies on C++ templates and thus is a header-only library.

The list of provided graph algorithms is impressive. Its latest version 1.6.2 was updated in September 2016.

So we want to have a look into the API using the same agenda as in the previous article about the LEMON Graph Library:

  1. Prerequisites
  2. Populate a graph
  3. Setup a shortest path solver
  4. Solve it, get the cost and the path

weiterlesen »

Be the first to like.

Oktober 18th, 2016

Neue ArcGIS Javascript WebApp „WKS Online“

Unter hat die LWF am Freitag 14.10.16 wkseine neue WebApp zur Anzeige der Witterungsdaten von Waldklimastationen aus ganz Bayern veröffentlicht. Die App wurde mit der ArcGIS Javascript API entwickelt und ist nun neben dem Borkenkäfermonitoring die zweite WebApp der Bayerischen Forstverwaltung auf der Basis ihrer ArcGIS Server Plattform.

Hier gehts zur offiziellen Pressemitteilung.

Be the first to like.

September 24th, 2016

Solving the Shortest Path Problem (1) – Intro

Shortest Path Problem

3 years later I’m back with a new article in my blog – time flies..

The Shortest Path Problem is a common problem to nearly anyone nowadays. Anyone who used a navigation system or Google Maps for finding the best route for the weekend trip has already sucessfully solved the shortest path problem.
A solution to the shortest path (in terms of distance, time or any arbitrary cost) is to find the best route from one point of a network (maybe a street network) to another.

In graph theory, the shortest path problem is the problem of finding a path between two vertices (or nodes) in a graph such that the sum of the weights of its constituent edges is minimized.

There are several tools for solving this problem – even free of charge and on any platform. In the following article series I want to explore the usage and the performance of various graph libraries that offer a shortest path solver.

List of the packages I want to explore:

  • Google OR-Tools
  • LEMON Graph Library
  • Boost Graph Library (BGL)

Note: I deleted Google OR-Tools from the list, because anything with Google OR-Tools was a mess:

  • Installation first failed
    (recent Ubuntu installation package does not work – „make third_party“ gives a „no rule defined for ‚third_party'“)
  • the API is too complicated (I found callbacks hard to understand in Javascript – I really don’t want to program with callbacks in C++
  • Be the first to like.

Oktober 24th, 2012

GRASS GIS v.out.ogr vs ogr2ogr

In der aktuellen stabilen Version von GRASS GIS 64bit (6.4.2) ist der Export von Geodaten per v.out.ogr extrem langsam. Zum Glück gibts dafür eine schnelle Lösung: die OGR Tools.

Mit der Installation von OGR wird auch das Werkzeug ogr2ogr mitgeliefert. Und das kann sehr schnell auch Daten im GRASS GIS Format lesen und ein anderes Geodatenformat schreiben. Leider ist der Zugriff mit diesem Werkzeug auf die GRASS GISBASE nicht sehr umfangreich dokumentiert.

Dabei gilt folgendes Format des Exportbefehls:


Hier ein Beispiel, wie ein GRASS Layer in ein ESRI Shapefile vom Typ Multipolygon geschrieben wird.

ogr2ogr /home/GISDATA/shp/lakes.shp /home/GISDATA/GRASS/Bayern/testdata/vector/lakes/head 1 -nlt MULTIPOLYGON


Be the first to like.

März 9th, 2012

Geoprocessing mit Open Source GIS Tools

Die Gewissheit

Im letzten Artikel habe ich einen Schnelldurchlauf durch die gängigsten FOSSGIS Werkzeuge vorgenommen um zu dem Schluss zu kommen, dass GRASS GIS bei rauhen Datenmengen einfach am besten abschneidet was die Performance angeht. Bei Verschneidungen mit kleinen Polygonen, wo sich PostGIS mit Hilfe des Räumlichen Index auf die relevanten Features konzentrieren kann ist die Leistung von PostGIS auch ganz gut. Mit dem Zerstückeln von großen Datensätzen durch die Verwendung von Vektorgittern kann man solche Verschneidungen auch um einiges beschleunigen. Allerdings hat man bei folgendem Fall wenig Chancen durch dieses Vorgehen Performance zu gewinnen: Wenn ST_Difference ins Spiel kommt.

Kurze Klärung: Nicht nur Verschneidungen sind in der GIS-Welt häufig, bei denen die Schnittmenge von zwei Ebenen berechnet wird – nein auch das Ausschneiden von Ausschlussgebieten kommt des öfteren vor. Dies entspricht dem Werkzeug „Erase“ in ArcGIS bzw. dem Tool „v.overlay operator=’not'“ in GRASS GIS. In PostGIS kann man solche Schweinereien auch durchführen. Wer allerdings jetzt unbedacht zu ST_Difference greift, der sei gewarnt! Um das erwartete Ergebnis zu erhalten, sollte man die Differenz-Ebene zuerst mit ST_Union vereinigen, weil SQL eben Feature per Feature anfrägt und damit auf den ersten Blick „fehlerhafte“ Ergebnisse liefert. Die Leistung ist jedoch in beiden Fällen eher dünn.

Das nachfolgende Zitat aus einem Beitrag in der PostGIS Mailing-Liste erklärt warum:

By it’s nature, using SQL for spatial computation is most efficient for
operations which can be carried out in a feature-wise manner.
Unfortunately, overlay does not fall into this category (since there is
a large amount of interaction between features.
Implementing a more efficient overlay algorithm in PostGIS is a nice challenge for the future… [1]

Soll heissen: Große Datenmengen und „Erase“ gehen bei PostGIS nur mit seeeehr viel Geduld. Ich bin spätestens an dieser Stelle zu GRASS GIS gewechselt. Nicht nur ArcGIS nützt nämlich effiziente Algorithmen zum Verschneiden von kompletten Ebenen. Übrigens: seit Mitte Februar gibts jetzt GRASS GIS in der stabilen Version 6.4.2. Was? Und 64Bit? Aber sicher.. Wann kommt nochmal ArcGIS 64Bit?

5 Leute mögen diesen Artikel.

Januar 20th, 2012

Geoprocessing mit Open Source GIS Tools und Python


Momentan soll ich eine ganze Menge an Geodaten für einen wissenschaftlichen Auftraggeber verarbeiten. Dabei geht es um die Potentialabschätzung der Wuchsleistung von schnellwachsenden Baumarten. Ich freute mich riesig auf den professionellen Einsatz von Open Source GIS Tools unter etwas anspruchsvolleren Bedingungen – denn  in letzter Zeit hatte ich beruflich wenig mit dem OS GIS Universum zu tun.

Große Datensätze

Anspruchsvoll? Oh ja – es handelt sich um eine bayernweite Analyse und da kommt schnell einiges zusammen…
Hier eine kleine Übersicht:

  • 4 Sachdatenbanken (MS Access)
  • 9 vektorielle Geodatensätze in insgesamt über 750 einzelnen ESRI Shapefiles (ca. 6,8 GB)
  • 3 Rasterdatensätze als ESRI ASCII bzw. Binary GRID (ca. 4,6 GB)

Nicht übel. Diese Menge von rund 11 GB sollte also mit Open Source GIS Tools verarbeitet werden. Das war im Auftrag natürlich nicht gefordert, da dieser softwareunabhängig formuliert war – aber für mich war es klar, dass ich FOSSGIS-Tools einsetze.

Ehrlich gesagt habe ich bislang mit FOSSGIS-Werkzeugen keine aufwendigen GIS-Analysen durchgeführt, sondern eher ausprobiert, was damit alles geht. Nun also eine vollständige Analyse. Dass das spannend wird, dachte ich mir schon…

Welche Werkzeuge?

Nun gut – welches Werkzeug solls denn nun sein? Da die Daten – vor allem die Shapefiles – ziemlich zerhackstückelt über ganz Bayern daher kamen (Schönen Gruß ans LfU und das LVG), mussten diese erstmal zu bayernweiten Datensätzen zusammengeführt werden. Das war vor Angebotsabgabe leider nicht bekannt – aber gut, ich nahm die Herausforderung an.

QGIS – fTools

Bei QGIS gibts eine Erweiterung, welche auch Shapefiles zusammenführen kann. Die sog. fTools können dies und auch noch viel mehr (z.B. Intersection, Dissolve, Multipart to single part etc.). Dabei basiert fTools auf QGIS und GDAL/OGR, um die Geoprocessing-Funktionen anbieten zu können. Außerdem ist es in Python geschrieben.
Die Variante der fTools in QGIS kam aufgrund der doch langen Laufzeiten nicht in Frage. Die GUI von QGIS frisst da anscheinend doch einiges an Performance — außerdem muss fTools dann als Plugin von QGIS mit dem Mutterprozess hin und her kommunizieren. Das wollt ich mir ersparen.
Man muss aber sagen, dass die fTools für kleinere Batch-Arbeiten gut geignet sind. Das Pythonskript, das ich mit der Vorlage der fTools geschrieben habe liest sich einfach. Das QGIS-Objektmodell folgt dem üblichen „Feature – Geometry – Attributtable“-Schema und ist somit leicht nachzuvollziehen.
Bis die QGIS-Pythonbindings dann aber mal ansprechbar sind kann ne Zeit vergehen. Gary Sherman hat dazu eine ausführliche Anleitung hier. Dazu mal an anderer Stelle mehr.

GDAL/OGR – kennste eine – kennste alle?

GDAL/OGR ist ja das ETL (Extract-Transform-Load) Werkzeug schlechthin. Sagt man. Ist auch so sag ich jetzt, aber noch vor ein paar Wochen hatte ich noch nicht viel Ahnung, wie man die Bibliothek einsetzt.
Ich hatte GDAL/OGR schon immer unbedacht benutzt, wenn ich z.B. mit QGIS oder GRASS arbeitete, da viele Desktop-GIS diese Bibliothek unter der Haube haben – allerdings eben immer „nur“ als Datenprovider für Desktop GIS.

Nun war klar, dass ich die Python-Bindings von GDAL/OGR genauer anschauen muss. Also erstmal recherchieren und viel ausprobieren (die Python-Doku für GDAL/OGR ist derzeit noch sehr spärlich) und irgendwann klappts dann aber auch. Das grundsätzliche Modell bei Geoprocessing-Bibliotheken ist ja immer relativ ähnlich: es gibt ein Feature-Objekt mit Sachdaten und ner Geometrie und man hat ein paar GIS-Methoden (welche im FOSSGIS-Universum ja eigentlich fast immer auf GEOS und somit der JTS basieren) zur Verfügung (Intersection, Buffer, etc.). Wie soll es auch mordsmäßig verschieden sein?
Genau so ists auch bei den Python-Bindings von GDAL/OGR. Die Extract und Load-Komponente kommt von GDAL/OGR selbst. Die geometrischen Verschneidungsoperatoren werden bei GDAL/OGR mit GEOS bewerkstelligt, während Transformationen mit PROJ4 behandelt werden.

Wer – wie ich – eher aus der ESRI-Ecke mit dem ArcGIS Geoprocessor kommt, wird sich bei GDAL/OGR in Python auch recht schnell zurecht finden. Die FDO API in C# war da schon ne andere (weil abstraktere) Nuss.

Interessante Links für GDAL/OGR mit Python:

Letztlich konnten die Daten dann mit einem  Pythonskript und der GDAL/OGR-Bibliothek zu bayernweiten Datensätzen zusammengeführt werden. Und wie schnell das geht! Da ist GDAL/OGR wirklich in ihrem Element. Wahnsinn, was die Bibliothek wegschreibt:

  • rund 100 Shapefiles mit insgesamt 2,1 Mio Features in 20 Minuten (800MB)
  • rund 100 Shapefiles mit insgesamt 3,1 Mio Features in 35 Minuten (4,2 GB)

Diese Zahlen überzeugen.


Auch PostGIS fällt nicht aus der Reihe der FOSSGIS-Tools und basiert auf GEOS und der PROJ4-Bibliothek. Die Kombination von SQL als Datenabfragesprache mit geometrischen Funktionen (Spatial SQL) fand ich immer spannend. Nachdem die Shapefiles also zusammengeführt waren, wollte ich einfach alle Vektordaten in eine PostGIS-DB importieren und die Aufbereitung in PostGIS machen. Auch dass mit PL/Python meine Lieblingssprache Python in einer Datenbank als prozedurale Sprache zur Verfügung steht find ich klasse (ich denke hier an die Lesbarkeit von PL/SQL Code vs. Python…).
Allerdings kam ich nicht weit. PostGIS hat definitiv als professionelle Geodatenhaltung seine Stärken und einige Anfragen an Daten kann es auch schnell beantworten, aber PostGIS ist nicht „post GIS“ (im Sinne von „nach GIS“) wie es im Vorwort des Buchs „PostGIS in Action“ hies. Man braucht bei solchen Datenmengen anscheinend schon noch ein extra Analysewerkzeug. Vielleicht liegts auch an meiner Rechenpower oder meinen PostGIS/SQL-Kenntnissen, aber GIS-Analysen mit dieser Datenmenge klappt nach meiner Erfahrung nicht in PostGIS.  Nach Laufzeiten von 2 Tagen habe ich die aufwendigen Verschneidungen (bayernweit) sein gelassen. Schade eigentlich. Ich hätte irgendwie mehr Performance von PostGIS erwartet.


Raster? Nimm SAGA GIS. Eben – für Rasterdaten ist SAGA GIS spitze. Performant, gut bedienbar, sogar per Python oder Kommandozeile ansprechbar für Batchabläufe. Bei Vektordaten hat SAGA aber so seine Macken. Außerdem werden nicht viele Möglichkeiten in der Vektoranalyse angeboten. Diejenigen, die dabei sind basieren interessanterweise jedoch nicht auf GEOS, sondern auf CGAL.
Aber gut, SAGA GIS ist eben vor allem ein Raster-GIS. In Ordnung.

GRASS GIS – hat so nen Bart?

Allerdings. GRASS GIS hat schon einige Jahre auf dem Buckel (30+?) – wird aber laufend fortentwickelt. Seit geraumer Zeit sieht auch die GUI etwas ansprechender aus. Von den Analysemöglichkeiten her ist GRASS GIS im FOSSGIS-Universum meiner Meinung nach einsame spitze.

Nimm GRASS GIS – wenn Du nicht ewig Zeit hast. Im Zusammenhang mit Scripting ist das Werkzeug ein verdammt performantes Analyse-Tool. Natürlich sollte man an dieser Stelle die etwas höhere Lernkurve bei GRASS ggü. anderen Werkzeugen berücksichtigen. Aber die Zeitinvestition lohnt sich!

Ich bin in den o.g. Ausführungen immer auf die Geometriebibliothek der Tools eingegangen. Da fast alle OS GIS Werkzeuge letztlich die geometrischen Funktionen an die GEOS-Bibliothek weiterreichen, ist auch die Performance bei großen Datenmengen vergleichbar.
Damit ist es relativ egal, ob man GDAL/OGR oder die fTools von QGIS oder PostGIS verwendet. Alle basieren auf GEOS. GEOS ist ja ein C++ Port der JTS (Java Topology Suite). Und diese ist wiederum in anderen FOSSGIS-Tools verbaut wie gvSIG, OpenJUMP, uDIG oder Kosmo. GIS-Analysen mit derartigen Datenmengen in Java-Tools durchzuführen hatte bei mir leider regelmäßig einen „Out of heap space“ Fehler zur Folge. Deshalb schied auch die JTS aus.

Die GRASS GIS Overlay-Operatoren sind jedoch als C-Algorithmen anscheinend richtig speicheroptimiert geschrieben. Trotzdem bleibt ein kleiner Wermutstropfen: Auch in GRASS GIS konnte ich die Datenmengen nicht bayernweit importieren bzw. verschneiden. Mit einem 64bit System und mehr RAM wäre das vielleicht schon gegangen. So aber blieb mir nur ein „Tiled Processing“, in dem ich die bayernweiten Datensätze in 16 Kacheln aufgeteilt habe. Mit GRASS GIS hats dann im Batch-Modus per Pythonbindings allerdings recht flott (rund 1,5 Std. für einen bayernweiten Verschneidungsdurchlauf) geklappt. Vielleicht mach ich demnächst auch nochmal nen Vergleich mit einem Tiled Processing der Daten in PostGIS, aber ich habe wenig Hoffnung, dass dies ähnlich performant ist wie GRASS GIS.

Und ne kleine GRASS Python Utility Klasse ist auch noch herausgekommen:

# -*- coding: latin-1 -*-
#  Helper for GRASS GIS Python Scripting
#  Johannes Sommer, 18.01.2012

class utility():
	import core as grass
	''' Utility-Class for GRASS GIS Python Scripting.
		Copyright by Johannes Sommer 2012.

		- doAddColumn
		- doCalcColumnValue
		- doRenameColumn
		- doIntersection
		- doDifference
		- getMapsets
		- getVectorLayers
		- getRasterLayers
		- getVectorLayersFromMapset
		- getRasterLayersFromMapset
		- getColumnList
		- doFilterLayerList 

		import grass.utils as utils
		gUtil = util.utility()
		gUtil.dodifference('forest', lakes')

	def doAddColumn(self, _lyrA, _colName, _colType):
		''' Adds a column to the input vector layer with the given type.

			GRASS datatypes depend on underlying database, but all
			- varchar (length)
			- double precision
			- integer
			- date

			doAddColumn('lakes', 'width', 'double precision')	'''
		retVal = grass.run_command('v.db.addcol', map=_lyrA,
								   columns='%s %s' % (_colName, _colType) )
		return retVal

	def doCalcColumnValue(self, _lyrA, _colName, _newVal):
		''' Updates a column of the input vector layer with the passed value.
			@_newVal can be a certain value or a calculation of existing columns.

			doCalcColumnValue('lakes', 'width', 'length/2')		'''
		retVal = grass.run_command('v.db.update', map=_lyrA,
								   column=_colName, value=_newVal)
		return retVal

	def doRenameColumn(self, _lyrA, _colNameA, _colNameB):
		''' Renames a column of the input vector layer.

			doRenameColumn('lakes', 'width', 'width_old')		'''
		retVal = grass.run_command('v.db.renamecol', map=_lyrA,
								   column='%s,%s' %(_colNameA,_colNameB))
		return retVal

	def doIntersection(self, _lyrA, _lyrB, OVERWRITE_OUTPUT==False):
		''' Performs a geometric intersection ('AND'-Operator) of two vector layers
			and writes the output to a layer called 'layerNameA_X_layerNameB'.

			@OVERWRITE_OUTPUT can be set to 'Y' or 'N'
			doIntersection('lakes', 'forest')	'''
		outputLyr = _lyrA.split('@')[0] + '_X_' + _lyrB.split('@')[0]

		optArg = ''
			optArg = '--overwrite'
		retVal = grass.run_command('v.overlay %s' % optArg, ainput=_lyrA,
								   binput=_lyrB, output=outputLyr,
		return retVal

	def doDifference(self, _lyrA, _lyrB, OVERWRITE_OUTPUT==False):
		''' Performs a geometric difference ('NOT'-Operator) of two vector layers
			and writes the output to a layer called 'layerNameA_DIFF_layerNameB'.

			@OVERWRITE_OUTPUT can be set to 'Y' or 'N'
			doDifference('lakes', 'forest')	'''
		outputLyr = _lyrA.split('@')[0] + '_DIFF_' + _lyrB.split('@')[0]

		optArg = ''
			optArg = '--overwrite'
		retVal = grass.run_command('v.overlay %s' % optArg, ainput=_lyrA,
								   binput=_lyrB, output=outputLyr,
		return retVal

	def getMapsets(self):
		''' Returns all GRASS mapsets in current GRASS location as list.'''
		return grass.mapsets()

	def getVectorLayers(self):
		''' Returns all vector layers in current GRASS location as list.'''
		return grass.list_strings('vect')

	def getRasterLayers(self):
		''' Returns all raster layers in current GRASS location as list.'''
		return grass.list_strings('rast')

	def getVectorLayersFromMapset(self, _mapset):
		''' Returns all vector layers in given mapset as list.'''
		vLyrList = getVectorLayers()
		# Filter List by MAPSET
		vLyrListFiltered = []
		for item in vLyrList:
			if _mapset in item:
		return vLyrListFiltered

	def getRasterLayersFromMapset(self, _mapset):
		''' Returns all raster layers in given mapset as list.'''
		rLyrList = getRasterLayers()
		# Filter List by MAPSET
		rLyrListFiltered = []
		for item in rLyrList:
			if _mapset in item:
		return rLyrListFiltered

	def getColumnList(self, _vLyr):
		''' Returns all column names of a vector layer as list.'''
		# Import vector wrapper from %GISBASE%\etc\python\script
		import vector as vector
		out_colList = []
		out_colList = vector.vector_columns(_vLyr, getDict = False)
		return out_colList

	def doFilterLayerList(self, _lyrList, _lyrkey):
		''' Filters input layer list per _lyrkey and returns filtered list.'''
		out_lyrList = []
		for item in _lyrList:
			if _lyrkey in item:
		return out_lyrList

8 Leute mögen diesen Artikel.

Dezember 22nd, 2011

UNIGIS MSc – ein Resumee

Ungefähr vor einer Woche war es soweit: Ich erhielt das Abschlusszeugnis vom UNIGIS-Team und darf mich von jetzt an offiziell einen „Master of Science“ (GIS) nennen. Nach drei Jahren Fernstudium tut es gut, das angestrebte Ziel endlich abgeschlossen zu wissen.
Zeit für ein Resumee in Sachen UNIGIS!

1. Kosten
Zunächst ist es einmal so, dass dieses Fernstudium eine Menge Geld kostet. Rund 8000 Euro werden da für die Weiterbildung verbraten. Wer einen Arbeitgeber hat, der ihm was zuschießt kann sich glücklich schätzen. Wer das privat finanziert sollte bei der steuerlichen Absetzbarkeit der Kosten aufpassen. Bei UNIGIS kann man die Kosten in zwei Raten oder in einer Rate zahlen. Ich dachte, ich nehm die eine Rate – dadurch spart man sich ein paar hundert Euro ggü. UNIGIS. Allerdings kann man dann bei der Steuererklärung den Betrag als Werbungskosten auch nur in einem Jahr absetzen. Da dieser Betrag mit ca. 8000 Euro den überhaupt möglichen absetzbaren Maximalbetrag von 4000 Euro übersteigt, „verpuffen“ 4000 Euro und wirken nicht steuermindernd. Deshalb würde ich aus heutiger Sicht die Zweimal-Rate in Anspruch nehmen, um die tatsächlichen Kosten steuerwirksam zu halten.
Aber: ich bin kein Steuerexperte und übernehme keinerlei Gewähr für diesen Hinweis.

2. Inhalte
Die Inhalte der Module waren insgesamt sehr spannend und haben einen vollständigen Einblick in das Thema GIS vermittelt. Je nach Vorkenntnissen ist man in einigen Modulen schneller oder etwas langsamer unterwegs, aber die 6 Wochen Bearbeitungszeit hatten bis auf ein Modul immer ausgereicht. Super waren die Module zur Datenmodellierung, Geodatenbanksysteme und zur Räumlichen Analyse. Was mir im Angebot der optionalen Module ein bisschen gefehlt hat  war GIS-Programmierung in .NET. Mittlerweilen gibts allerdings ein Modul dazu mit ArcObjects und VB.NET. Trotzdem würde ich mir zusätzliche Angebote dazu wünschen. Auch mehr Open Source Module könnten das Angebot der optionalen Module noch verbessern (z.B. PostGIS, DotSpatial oder SharpMap, QGIS und Anpassungen mit Python). Hier ist man sehr proprietär unterwegs.

3. Betreuung
Die Betreuung ließ in manchen Modulen zu wünschen übrig. Da hatte ich bei zwei Modulen schon das Gefühl, dass jemand nen ziemlichen lockeren Job als Lehrbeauftragter hat. Mit einer Beurteilung war ich auch überhaupt nicht einverstanden, da mir die Leistungserwartung des Modulbetreuers (Modul 3) nicht ausreichend genau formuliert war. Da gingen unsere Vorstellung von der Bearbeitung des Moduls etwas auseinander. Auch nach heftiger Diskussion – letztlich mit der Lehrgangsleitung – hat sich nichts an der Beurteilung geändert. Insgesamt war die Betreuung in den Pflichtmodulen jedoch gut.
Während der gesamten Studienzeit war die Betreuung durch eine Tutorin eine wichtige Unterstützung. Unsere Jahrgangstutorin des MSc 2009 war dabei sehr aktiv und motivierend. Vielen Dank an Julia Moser dafür!

4. Master Thesis
Die Phase „Master Thesis“ dauerte bei mir (auch durch einen Arbeitgeberwechsel in der Fernstudiumszeit) insgesamt etwas länger. Nachdem ich die Module alle hinter mich gebracht hatte, gingen noch 1,5 Jahre ins Land bis die Masterarbeit fertig war. Die eigentliche Bearbeitung lag bei einem Jahr. Ursprünglich hatte ich 6 Monate im Kopf, aber das ging einfach nicht.
Ich hatte ein betriebliches Thema gewählt und hatte auch mit meinem Arbeitgeber vereinbaren können, Arbeitszeit für die Master Thesis zu verwenden, da es ja auch einen betrieblichen Nutzen hatte. Dieses Vorgehen hat Vorteile:

  • Man lernt das Unternehmen und Prozesse besser kennen
  • Man macht das meiste in der Arbeitszeit und nicht noch abends oder am Wochenende
  • Man bearbeitet etwas, was im Idealfall auch umgesetzt wird

Allerdings ist man dann auch abhängig von der Zuarbeit und Informationen von Mitarbeitern, muss auf Termine warten, muss nebenher auch noch das reguläre Tagesgeschäft erledigen und oft auch andere Arbeiten höher priorisieren.
Zum Schluss hatte ich mit meinem Vorgesetzten vereinbart, 14 Tage nur die Master Thesis zu bearbeiten, weil es sich sonst noch länger hingezogen hätte.
Insgesamt haben mich mein Arbeitgeber und meine Kollegen sehr gut bei der Master Thesis unterstützt. Außerdem möchte ich die extrem kurzen Antwortzeiten per email und die gute Betreuung durch Prof. Strobl herausheben – das war wirklich klasse!

Wer ein Interesse an GIS mitbringt und dieses auch über längere Zeit aufrecht erhalten kann schafft das Fernstudium auch. Allerdings gibts natürlich auch Durststrecken in Modulen, die einem nicht so liegen. Bei mir war dies das Modul zum Thema Projektmanagement. Dieses Fernstudium bedeutet definitiv eine Herausforderung mit weniger Zeit für Hobbies, Freunde und Familie. Aber wenn einen das Thema GIS wirklich juckt und wer gleichzeitig im Beruf noch nebenher Geld verdienen möchte (muss), dann gibts meiner Meinung nach derzeit keine Alternative zu UNIGIS.

7 Leute mögen diesen Artikel.

November 20th, 2011

UNIGIS MSc: Master Thesis abgeschlossen!

Nach einem Jahr Bearbeitungszeit war es am Freitag nun soweit: ich habe meine Master Thesis abgegeben. Hurra!

Gefordert war neben der Master Thesis in zweifacher, gedruckter und gebundener Ausfertigung auch ein Extended Abstract (8 Seiten) und eine Präsentation (ca. 20 Seiten) abzuliefern. Die Thesis selbst, der Extended Abstract und die Präsentation mussten dann auch digital nach Salzburg geschickt werden.

Der Titel der Master Thesis ist:

Konzeption eines Wegeinformationssystems und Aspekte der

am Beispiel der Bayerischen Staatsforsten

Die Master Thesis kann hier bezogen werden und – wer es etwas knapper bevorzugt – einen Auszug der Arbeit in Form des Extended Abstract findet man dort auch. Dem eiligen Leser würde ich nach dem Genuss des Abstracts aber auf jeden Fall Kap. 5, 6 und 7 der gesamten Arbeit (insgesamt 10 Seiten) ans Herz legen.

Es war vor allem in den letzten 2 Wochen eine heftige Zeit, denn bekanntlich kommt in diesen heiklen Momenten dann vieles zusammen (Kind und Partnerin krank, wichtige Termine in der Arbeit). Dennoch hab ich es geschafft, meinen im Oktober gesetzten Abgabetermin einzuhalten. Das war auch nötig, da sich der Zeitplan durch mehrere Ereignisse immer wieder erweitert hatte.

Ursprünglich hatte ich vor, die Thesis in 6 Monaten abzuhandeln – was auch von UNIGIS so vorgegeben wird. Dieser Zeitrahmen hatte sich dann aber bald als nicht vereinbar mit einem regulären Vollzeit-Job und Familie herausgestellt. Sei es wie es ist – mein Sohn würde sagen:

„Fertig bin!“


3 Leute mögen diesen Artikel.