Dokumentation beginnt nicht erst bei QGIS. Sie setzt eine Projektfrage voraus. Ohne Projektfrage bleibt eine Werkzeugliste fachlich leer: Man sieht dann vielleicht, dass ein Distanzraster berechnet, ein Layer reklassifiziert oder ein Rasterrechner-Ausdruck ausgeführt wurde, aber nicht, warum dieser Schritt für das Projekt notwendig war.
Die Projektentwicklung klärt daher zuerst:
Welche räumliche Frage soll bearbeitet werden?
Die QGIS-Dokumentation klärt danach:
Wie wurde diese Frage in Daten, Kriterien, Werkzeuge, Parameter und Ergebnislayer übersetzt?
Beide Seiten gehören zusammen. Die Projektseite entwickelt die fachliche Logik. Diese Seite zeigt, wie die technische Umsetzung und die methodischen Entscheidungen nachvollziehbar festgehalten werden.
Warum Dokumentation in QGIS wichtig ist
Bei einer GIS-Analyse entsteht das Ergebnis selten durch einen einzelnen Arbeitsschritt. Eine Eignungskarte, eine Kostenoberfläche oder eine Konfliktkarte ist das Ergebnis vieler Entscheidungen: Welche Eingangsdaten wurden verwendet? Wie wurden sie zugeschnitten, rasterisiert, reklassifiziert, gewichtet und miteinander verrechnet? Welche Zellgröße wurde gewählt? Welche Flächen wurden ausgeschlossen? Welche Schwellenwerte wurden gesetzt?
Deshalb reicht es nicht, am Ende nur die fertige Karte abzugeben. Fachlich nachvollziehbar ist eine Analyse erst dann, wenn auch der Weg zur Karte dokumentiert ist.
Dokumentation bedeutet dabei nicht nur, die verwendeten Werkzeuge aufzuschreiben. Entscheidend ist, welche fachlichen Entscheidungen in den GIS-Workflow eingebaut wurden. Bei einer Multikriterienanalyse betrifft das vor allem Kriterienauswahl, Reklassifikation, Gewichtung, Einschränkungen und Interpretation.
Was dokumentiert werden muss
Eine QGIS-Analyse besteht aus zwei Ebenen. Die erste Ebene ist technisch: Welche Werkzeuge wurden mit welchen Parametern ausgeführt? Die zweite Ebene ist fachlich: Warum wurden genau diese Daten, Kriterien, Schwellenwerte und Gewichtungen gewählt?
Beide Ebenen müssen zusammen dokumentiert werden. Ein Verarbeitungsverlauf zeigt, was technisch passiert ist. Er erklärt aber nicht automatisch, warum ein bestimmter Schwellenwert sinnvoll ist oder warum ein Kriterium höher gewichtet wurde als ein anderes.
Für eine dokumentierte Analyse sind deshalb drei Bausteine wichtig:
- Verarbeitungsverlauf: Welche Werkzeuge wurden ausgeführt?
- Modell, Skript oder Projektstruktur: Wie lässt sich der Ablauf wiederholen?
- Methodennotiz: Welche fachlichen Entscheidungen wurden getroffen und warum?
Von der Projektfrage zum Werkzeugschritt
Auch ein kleines GIS-Projekt besteht fast nie aus einem einzelnen Werkzeug. Schon eine einfache Eignungsanalyse verbindet mehrere Schritte: Daten werden zugeschnitten, vereinheitlicht, in Raster überführt, reklassifiziert, gewichtet, maskiert und schließlich dargestellt. Jeder dieser Schritte verändert die Daten und damit auch die Aussage der späteren Karte.
Ob ein Schritt sinnvoll ist, lässt sich aber nicht allein am Werkzeug erkennen. Entscheidend ist die Projektfrage. Ohne sie bleibt unklar, warum ein Abstand berechnet, eine Hangneigung klassifiziert, eine Fläche ausgeschlossen oder ein Kriterium stärker gewichtet wurde.
Ein Beispiel: Das Werkzeug Nähe / Rasterdistanz erzeugt zunächst nur eine Distanzfläche. Fachlich bedeutsam wird diese Distanzfläche erst durch die Fragestellung. In einer Habitatmodellierung kann große Siedlungsferne als günstiger Standortfaktor interpretiert werden. In einer Erreichbarkeitsanalyse kann dieselbe Entfernung dagegen als Nachteil gelten. Das Werkzeug ist identisch, aber die fachliche Bedeutung ist eine andere.
Dokumentation muss deshalb nicht nur die Werkzeugfolge beschreiben, sondern die Verbindung zwischen Projektfrage und Verarbeitungsschritt sichtbar machen:
Projektfrage → Kriterium → GIS-Operation → Parameter → Ergebnislayer → InterpretationVerarbeitungsverlauf
Der QGIS-Verarbeitungsverlauf protokolliert Werkzeuge, die über die Processing-Werkzeuge ausgeführt wurden. Dazu gehören zum Beispiel Rasterisieren, Hangneigung, Rasterrechner, Reklassifizieren nach Tabelle oder Nähe / Rasterdistanz.
Der Verlauf ist besonders nützlich, wenn einzelne Schritte nachvollzogen oder wiederholt werden sollen. Viele Einträge lassen sich erneut öffnen, sodass die verwendeten Parameter sichtbar werden. Außerdem können Verarbeitungsschritte als Python-Befehl oder als qgis_process-Befehl kopiert werden.
Für ein Methodenprotokoll sollten aus dem Verlauf vor allem diese Informationen übernommen werden:
- Werkzeugname,
- Eingangsdaten,
- zentrale Parameter,
- Ausgabedatei,
- Zweck des Schritts,
- fachliche Annahme hinter dem Schritt.
Der Verarbeitungsverlauf ersetzt aber kein vollständiges Methodenprotokoll. Manuelle Entscheidungen wie Layerauswahl, visuelle Kontrolle, Umbenennungen, Symbolisierung oder die Begründung von Schwellenwerten müssen zusätzlich beschrieben werden.
Grafischer Modellierer und Skripte
Der grafische Modellierer ist sinnvoll, wenn mehrere Verarbeitungsschritte immer wieder in derselben Reihenfolge ausgeführt werden sollen. Aus einzelnen Werkzeugen wird ein Modell gebaut. Dieses Modell kann gespeichert, erneut ausgeführt und auf andere Eingangsdaten angewendet werden.
Für eine Multikriterienanalyse könnte ein Modell zum Beispiel folgende Schritte enthalten:
- Eingangsdaten zuschneiden.
- Rasterdaten auf gemeinsame Zellgröße bringen.
- Kriterien berechnen.
- Kriterien reklassifizieren.
- Kriterien gewichten und verrechnen.
- Einschränkungsmaske anwenden.
- Ergebnisraster speichern.
Der Vorteil liegt darin, dass die Verarbeitungskette sichtbar wird. Die Karte erscheint dann nicht als fertiges Bild, sondern als Ergebnis eines nachvollziehbaren Ablaufs.
Skripte gehen einen Schritt weiter. Sie beschreiben den Ablauf nicht grafisch, sondern als Code. Das ist besonders stark, wenn ein Workflow mehrfach mit anderen Daten, anderen Gebieten oder anderen Gewichtungen ausgeführt werden soll.
Ein einzelner Verarbeitungsschritt kann zum Beispiel so dokumentiert werden:
processing.run(
"gdal:slope",
{
"INPUT": "dgm.tif",
"BAND": 1,
"SCALE": 1,
"AS_PERCENT": False,
"OUTPUT": "hangneigung.tif"
}
)Für den Einstieg ist es nicht notwendig, einen vollständigen Workflow selbst zu programmieren. Ein praktikabler Zwischenweg ist, Werkzeuge zunächst normal in QGIS auszuführen, den Befehl aus dem Verarbeitungsverlauf zu kopieren und die wichtigsten Schritte in einem kurzen Skript oder Methodenprotokoll zu sichern.
Projektdatei und Datenstruktur
Die QGIS-Projektdatei dokumentiert einen anderen Teil des Workflows. Sie speichert, welche Layer eingebunden sind, wie sie dargestellt werden, welche Layouts angelegt wurden und auf welche Datenquellen verwiesen wird.
Für eine Abgabe sollte die Projektdatei deshalb bewusst organisiert werden. Rohdaten sollten unverändert bleiben. Zwischenergebnisse und finale Ergebnisse sollten mit sprechenden Namen gespeichert werden. Temporäre Layer sollten vermieden werden, wenn sie für die Analyse wichtig sind. Kartenlayouts brauchen Titel, Legende, Maßstab, Quellenangabe und Datum.
Eine saubere Projektstruktur ist kein formaler Zusatz. Sie entscheidet darüber, ob eine Analyse später noch verstanden, geprüft oder verändert werden kann.
Methodennotiz
Die Methodennotiz erklärt die fachlichen Entscheidungen. Sie sollte knapp sein, aber die zentralen Annahmen offenlegen.
Für eine Multikriterienanalyse gehören dazu:
- Fragestellung,
- Eingangsdaten,
- Raumbezug, Projektion, Zellgröße und Ausdehnung,
- verwendete Kriterien,
- Reklassifikationsregeln,
- Gewichtungen,
- Ausschluss- oder Einschränkungsflächen,
- verwendete Werkzeuge,
- Ergebnisdateien,
- Grenzen der Interpretation.
Wichtig ist nicht, jede Mausbewegung zu protokollieren. Wichtig ist, dass eine andere Person nachvollziehen kann, warum aus den Eingangsdaten genau dieses Ergebnis entstanden ist.
Beispiel: Reklassifikation dokumentieren
Ein Reklassifikationsschritt sollte nicht nur als Werkzeugaufruf erscheinen. Er braucht eine kurze fachliche Begründung.
Beispiel:
Ziel: Standardisierung der Siedlungsnähe
Eingangsdaten: siedlungsdistanz.tif
Werkzeug: Reklassifizieren nach Tabelle
Regel: 0–100 m = 0; 100–300 m = 0.3; 300–600 m = 0.6; > 600 m = 1
Ausgabe: siedlungsdistanz_idx.tif
Begründung: Siedlungsnahe Bereiche werden wegen höherer Störung geringer bewertet.
Unsicherheit: Die Schwellenwerte sind didaktisch gesetzt und nicht lokal validiert.Damit ist der Schritt technisch und fachlich lesbar. Man sieht nicht nur, was gerechnet wurde, sondern auch, welche Annahme in die Analyse eingegangen ist.
Beispiel: Rasterrechner-Ausdruck dokumentieren
Auch ein Rasterrechner-Ausdruck sollte nicht nur ausgeführt, sondern gesichert und erklärt werden:
(
"walddichte_idx@1" * 0.40 +
"siedlungsdistanz_idx@1" * 0.30 +
"hangneigung_idx@1" * 0.20 +
"exposition_idx@1" * 0.10
)
*
"einschraenkung_mask@1"Der Ausdruck kombiniert standardisierte Kriterien zu einer Eignungsfläche. Die Gewichte drücken aus, welche Kriterien in diesem Modell stärker oder schwächer zählen. Die Einschränkungsmaske sorgt dafür, dass ungeeignete Flächen ausgeschlossen oder abgewertet werden.
Eine Dokumentation muss daher nicht nur den Ausdruck enthalten, sondern auch erklären, warum diese Kriterien und Gewichte verwendet wurden.
Empfohlener Workflow für die Übung
Für die Kursübung reicht ein kompakter Dokumentationsstandard:
- Projektordner anlegen.
- Rohdaten unverändert speichern.
- QGIS-Projekt früh speichern.
- Zwischenergebnisse mit sprechenden Namen speichern.
- Verarbeitungsschritte über den Verlauf kontrollieren.
- Wiederkehrende Abläufe im Modellierer oder Skript sichern.
- Rasterrechner-Ausdrücke in das Methodenprotokoll kopieren.
- Kriterien, Schwellenwerte und Gewichte kurz begründen.
- Ergebnislayout erstellen.
- Grenzen der Analyse benennen.
Reproduzierbarkeit entsteht nicht automatisch durch QGIS. Sie entsteht durch die Verbindung aus gespeicherten Daten, nachvollziehbaren Werkzeugparametern, sauber benannten Ausgaben und einer kurzen fachlichen Begründung.