Der perfekte Gipfel

Problemlösung dokumentieren: von der Idee zum nachvollziehbaren GIS-Workflow

Chris Reudenbach

Worum es hier geht

Der „perfekte Gipfel“ ist ein gutes Beispiel für ein kleines GIS-Projekt, weil die Frage zunächst unscharf ist.

Aus einer Idee wird erst dann ein Projekt, wenn dokumentiert ist, wie sie in Kriterien, Daten, Operationen und Ergebnisgrenzen übersetzt wurde.

Die Folien sind deshalb nicht als Programmierbeispiel gedacht, sondern als Beispiel für Problemklärung und Workflow-Dokumentation.

Dokumentationsrahmen

Für jedes GIS-Projekt muss die gleiche Kette lesbar bleiben:

Problem → Projektfrage → Kriterium → Datenbasis → Operation → Ergebnislayer → Aussagegrenze

Die Dokumentation beschreibt nicht jede Mausbewegung. Sie beschreibt die fachlich entscheidenden Übersetzungsschritte.

Ausgangspunkt: Was ist ein „perfekter Gipfel“?

Dokumentationspunkt: Die Ausgangsidee ist ein Qualitätsurteil. Vor der GIS-Umsetzung muss geklärt werden, welche räumlichen Eigenschaften dieses Urteil tragen sollen.

Von der Idee zur Projektfrage

Aus „perfekter Gipfel“ wird keine GIS-Analyse. Eine bearbeitbare Frage braucht eine messbare Zielrichtung.

Welche Gipfel sind nach Höhe, Dominanz, Prominenz und Eigenständigkeit besonders ausgeprägt?

Das ist der erste dokumentierbare Schritt: Die Alltagsformulierung wird in eine räumliche Analysefrage übersetzt.

Kriterien statt Bauchgefühl

Aus dem Begriff entstehen Kriterien:

Höhe / Position
Dominanz
Prominenz / Schartenhöhe
Eigenständigkeit

Nicht alle Kriterien sind direkt im DGM gespeichert. Einige müssen abgeleitet werden.

Dokumentationspunkt: Für jedes Kriterium muss festgehalten werden, welche Datenbasis und welche Ableitungslogik verwendet wird.

Formale Definition als Entscheidung

Eine Formel ist keine neutrale Wahrheit. Sie dokumentiert, welche Eigenschaften in die Bewertung eingehen und wie sie gewichtet bzw. verrechnet werden.

Modellbildung dokumentieren

Für die Methodennotiz reicht die technische Formel nicht.

Dokumentiert werden muss:

Objekte: Gipfelpunkte
Fläche: Höhenmodell
Beziehungen: Distanz, Trennung, Verbindung
Produkt: Prominenz / Eigenständigkeit

Problemlösung als Arbeitsprotokoll

Diese Folie wird im Kurs als Dokumentationsfolie gelesen: Welche Teilprobleme entstehen, welche Entscheidungen werden getroffen, welche Zwischenergebnisse müssen gesichert werden?

Vom Problem zu Arbeitspaketen

Nicht alles muss automatisiert werden. Wichtig ist, dass die relevanten Arbeitspakete benannt werden: Datenprüfung, Kriteriendefinition, Operation, Kontrolle, Ergebnisinterpretation.

Umsetzung dokumentieren: interaktiv

Interaktive Arbeit ist zulässig. Dokumentiert werden aber die stabilen Schritte: Werkzeug, Eingangsdaten, zentrale Parameter, Ausgabe und fachlicher Zweck.

Umsetzung dokumentieren: reproduzierbare Befehle

Kommandozeilen oder kopierte Processing-Aufrufe sind hier kein Programmierziel. Sie sind ein Mittel, um Parameter und Dateipfade eindeutig zu sichern.

Umsetzung dokumentieren: Ablauf statt Code

Wenn Skripte verwendet werden, dann als dokumentierte Ablaufbeschreibung. Entscheidend bleibt: Welche Entscheidung wird umgesetzt und welcher Ergebnislayer entsteht?

Übersetzung in GIS-Anforderungen

Hier liegt der Kern der Dokumentation: Fachliche Begriffe werden in Datenstrukturen, Raster-/Vektoroperationen, Parameter und Zwischenergebnisse übersetzt.

Dokumentationsschema für einen Hauptschritt

Ein Hauptschritt sollte knapp, aber vollständig dokumentiert werden.

Zweck
Welches Kriterium oder Teilproblem wird bearbeitet?

Datenbasis
Welche Eingangsdaten werden verwendet?

Operation
Welche GIS-Operation wird eingesetzt?

Parameter
Welche Schwellenwerte, Toleranzen oder Abbruchkriterien gelten?

Ausgabe
Welcher Layer oder Wert entsteht?

Grenze
Wovon hängt die Aussagekraft ab?

Wie soll das gehen?

Ein komplexes Problem wird dokumentierbar, wenn es in prüfbare Zwischenschritte zerlegt wird. Die Dokumentation folgt dieser Zerlegung.

Beispiel: Prominenz durch Fluten denken

Dokumentationspunkt: Die fachliche Idee lautet nicht „wir benutzen ein Tool“, sondern: Wir variieren ein Flutniveau und prüfen, wann der aktuelle Gipfel mit anderen Gipfeln verbunden wird.

Suchstrategie festhalten

Der naive Weg wäre schrittweises Fluten. Die dokumentierte Verbesserung ist eine Suchstrategie, die den relevanten Höhenbereich systematisch eingrenzt.

Abbruchkriterium dokumentieren

Für die Aussagekraft ist nicht nur das Ergebnis wichtig, sondern auch: Wann wurde die Suche beendet und welche Genauigkeit wurde akzeptiert?

Beispiel einer Methodennotiz

Fragestellung:
Wie eigenständig ist ein Gipfel im Verhältnis zu benachbarten Gipfeln?

Kriterium:
Prominenz / Schartenhöhe.

Datenbasis:
Digitales Höhenmodell und Gipfelpunkte.

Operationelle Idee:
Flutniveau variieren und Verbindung der Gipfeleinheiten prüfen.

Suchstrategie:
Höhenbereich durch binäre Suche eingrenzen.

Abbruchkriterium:
Suche endet bei definierter Höhentoleranz.

Aussagegrenze:
DEM-Auflösung, Gipfelerkennung und Toleranz beeinflussen den Wert.

Was davon ins eigene Projekt gehört

Projektfrage schärfen → Kriterien ableiten → Daten wählen → Hauptschritte planen → Parameter begründen → Ergebnislayer sichern → Aussagegrenze benennen

Das Gipfelbeispiel ist nur komplexer als viele Kursprojekte. Die Dokumentationslogik ist dieselbe.

Nicht dokumentieren: vollständige History

Eine Workflow-Dokumentation ist kein Mitschnitt jeder Bedienhandlung.

Dokumentiert werden nur Hauptschritte, die das Ergebnis fachlich verändern.

nicht: Layer verschoben, Stil getestet, Ansicht gezoomt
sondern: Distanz berechnet, reklassifiziert, gewichtet, maskiert, kombiniert

Die Leitfrage lautet: Könnte eine andere Person den methodischen Weg fachlich nachvollziehen?

Übertrag auf einfache GIS-Projekte

Siedlungsferne
→ Distanz zur Siedlung
→ Reklassifikation
→ Störungskriterium
→ Beitrag zur Eignungskarte

Hangneigung
→ DGM-Ableitung
→ Klassenbildung
→ Reliefkriterium
→ Beitrag zur Eignungskarte

Auch einfache Projekte brauchen keine lange History, sondern eine begründete Kette zwischen Frage, Kriterium, Operation und Ergebnis.

Prüfregel für die Dokumentation

Für jeden Hauptschritt sollte eine fremde Person erkennen können:

Warum dieser Schritt?
Welche Daten?
Welche Operation?
Welche Parameter?
Welcher Ergebnislayer?
Welche Aussagegrenze?

Das Ziel ist nicht Programmierung. Das Ziel ist nachvollziehbare GIS-Arbeit.