<< , >> , Titelseite , Inhaltsverzeichnis

Bearbeitung großer Datensätze


Die Bereitstellung der MilGeo-Datensätze im Rahmen des SPP lenkt die Arbeit aller Arbeitsgruppen in Einzugsgebiete größerer Dimensionen (Neckar- bzw. Weser-Einzugsgebiet). Die bisherige Modellierung unserer Arbeitsgruppe wurde auf Einzugsgebietsgrößen bis maximal ca. 500 km2 durchgeführt (siehe Kapitel 1.4). Die mit der Lieferung des MilGeo-Datensatzes auftretenden großen Datenmengen führen zu Problemen bzgl. des Datenhandling, aber auch der Modellierung. Wir haben uns deshalb entschlossen die Bearbeitung dieser großen Datensätze in einem gesonderten Kapitel aufzuführen, um auf die erweiterte Qualität der Arbeit hinzuweisen, die die hinzukommende Aspekte (wie z.B. Rechenzeiten, Datenmanagement und Rasterausdünnung) betont.

Import von MilGeo-Datensätze in GRASS

Das uns zur Verfügung stehende Höhenmodell der Einzugsgebiete von Weser und Neckar besteht zur Zeit aus 180 MilGeo-Datensätzen. Jeder dieser Datensätze deckt eine Fläche von 20' x 12' ab und hat eine räumliche Auflösung von 1', was im betrachteten Gebiet einer Entfernung von etwa 30m entspricht.

Um die Daten für eine Analyse verfügbar zu machen, wurden sämtliche Datensätze in einer Datei zusammengeführt und anschließend in ein metrisches Koordinatensystem (Gauß-Krüger) projiziert. Das Zusammenführen der Datensätze wurde durch das UNIX-Shellscript mil2grass weitgehend automatisch durchgeführt. Da aber einige der MilGeo-Datensätze, wie beispielsweise l2926.dhm fehlerhafte Koordinaten im Header haben (hier 52:66:79N), ist im Einzelfall eine manuelle Korrektur der Koordinaten notwendig. Zentraler Bestandteil des Scripts ist das Programm r.read, das eine modifizierte Version des Programms read von T. Hügel, Neubiberg (Arbeitsgruppe Prof. Kleeberg) ist. Das Programm r.read erzeugt direkt binäre GRASS-Layer. Wie im Originalprogramm werden beim Import auch jeweils zwei Dateien erzeugt, die Informationen aus dem Data Set Identification (DSI) Record und dem Accuracy Description (ACC) Record des MilGeo-Datensatzes enthalten. Aus beiden Dateien, wurde mit Hilfe eines Perl-Scripts ein GRASS-Vektorlayer generiert, der den absoluten vertikalen Fehler des Kartenschnitts darstellt. Dieser Fehler ist in der Formatbeschreibung für die MilGeo-Datensätze definiert und beschreibt die Unsicherheit der Höhe in einem Punkt in Bezug auf NN, hervorgerufen durch systematische und zufällige Fehler. Die einzelnen Werte stellen den linearen Fehler dar, der mit einer Genauigkeit von 90% bestimmt wurde (siehe Graphik 55).

Der Import der Datensätze in GRASS wird in 9 Einzelschritten vollzogen:

  1. Einrichten einer Latitute/Longitude Location in GRASS
  2. Konvertierung der MilGeo-Datensätze in GRASS-Layer.
  3. Verknüpfen der Einzellayer zu einem großen Layer.
  4. Export des Layers im ARC/INFO ASCII-Format.
  5. Import des Layers in ARC/INFO.
  6. Projektion der Daten.
  7. Export der projizieren Daten im ARC/INFO ASCII-Format.
  8. Einrichten einer geeigneten Location in GRASS.
  9. Import der Daten.

Benötigte Programme:

ARC/INFO:
asciigrid
gridascii
project

GRASS:
r.out.arc (nicht Standard)
r.in.arc (nicht Standard)
r.read (nicht Standard)
Sonstiges:
mil2grass (Shellscript)

Anmerkung: Die von uns entwickelten Programme und Scripts stehen über unseren FTP-Gastzugang zur Verfügung.

zu Schritt 2 + 3:

Das Ausführen dieser Schritte muß von der GRASS-Ebene aus in einer geeigneten LL-Location stattfinden.

Die Schritte werden über das UNIX-Shellscript mil2grass weitgehend automatisiert ausgeführt. Vor der ersten Ausführung muß in dieses Script der Name des Layers eingetragen werden, der erzeugt werden soll. (Bsp.: DATA=weser_neckar.dem)

Der Systemvariablen DEMS werden anfangs die MilGeo Datensätze zugewiesen, die importiert werden sollen. Im Beispielscript wird hierzu die Datei FLIST eingelesen. In FLIST stehen Dateinamen in einer Form, wie sie beispielsweise ein 'ls' liefert.

Den INIT_? Variablen werden Startkoordinaten zugewiesen. Dabei ist auf eine exakte Angabe der nördlichen und westlichen Begrenzung zu achten. Die südliche soll etwas kleiner sein wie die nördliche, die östliche etwas größer wie die westliche. Hier genaue Werte einzugeben ist nicht sinnvoll, da sie im Script mit den passenden Werten überschrieben werden.

Die Einzeldatensätze werden dann jeweils, durch das Programm r.read, in einen temporären GRASS-Layer (tmp.dem) konvertiert.

(Bei uns hatten einige MilGeo Datensätze falsche und sinnlose Koordinaten im Header. r.read meldet in diesem Fall einen Fehler und die Ausführung des Shellscripts wird abgebrochen. Wir haben in dann die falschen Koordinaten beim Einlesen des Datensatzes abgefangen und durch die richtigen Werte ersetzt.)

Der temporäre Layer wird mit r.mapcalc mit dem oder den schon bestehenden Layern zusammengeführt.

zu Schritt 4:

Der Export des erzeugten Layers wird mit dem Programm r.out.arc vorgenommen.

	r.out.arc -1 NEU.DAT >NEU.ASC

zu Schritt 5:

Der Import in ARC/INFO wird mit dem Befehl asciigrid vorgenommen.

	asciigrid NEU.ASC NEU_ARC

zu Schritt 6:

Projektion der Daten nach Gauss-Krüger

	project GRID NEU_ARC NEU_GK_ARC projection_file CUBIC

Der projection_file ist folgendermaßen aufgebaut (Kommentare sind kursiv geschrieben. Sie dürfen nicht im File erscheinen):

INPUT
PROJECTION geographic
UNITS dd
PARAMETERS
OUTPUT
PROJECTION transverse
UNITS METERS
SPHEROID bessel
PARAMETERS
1.0
9 00 00 Mittelmeridian
0 00 00 3500000 Die erste Zahl gibt den Mittelmeridian/3 wieder 0
END
Siehe auch Handbuch zu ARC-Command-References.

zu Schritt 7:

Export mit gridascii

	gridascii GAUSSK_ARC GAUSSK_ASC

zu Schritt 8:

Wird mit Gauß-Krüger Koordinaten gearbeitet, ist in GRASS bei der Erstellung der Location die Transverse Mercator Projektion (tmerc) zu wählen. Der Ellipsoid für das Weser- bzw. Neckareinzugsgebiet ist bessel. Der Wert für den Nullmeridian ist gebietsabhängig. Die Standardparallele ist 0.0. (Siehe auch Schritt 6).

zu Schritt 9:

Import mit r.in.arc

	r.in.arc i=GAUSSK_ASC o=GESCHAFFT.DEM

Rechenzeiten bei der Ableitung primärer Objekte

Die Ableitung primärer Parameter im Sinne des GPM führte bei der Bearbeitung der MilGeo-Datensätze zu enormen Rechenzeiten. Für den hydrologischen Prozeß relevante Parameter, z.B. die Einzugsgebietsgröße oberhalb eines Pixels, sind für die Datensätze bei Orginalauflösung (30 m) in absehbaren Zeiträumen nicht mehr berechenbar (siehe unten). Um eine Abschätzung für die notwendigen Rechenzeiten bei der Ableitung einfacher Parameter zu erhalten wurde der Neckar-Datensatz in Teilgebiete zerlegt und für diese jeweils die Subeinzugsgebiete bestimmt. Nach einer Überlagerung der Ergebnisdateien erhält man die Subeinzugsgebiete für den gesamten Neckar in der Orginalauflösung (diese Ergebnisse bildeten außerdem die Basis für eine Fehlerabschätzung bei Rasterausdünnung). Im folgenden werden Arbeitschritte und Ergebnisse dargestellt.

Zerlegung des Neckar-Datensatzes

Um realisierbare Rechenzeiten bei der Berechnung von Subeinzugsgebieten zu erreichen mußten

Wegen der an den Teilgebietsrändern auftretenden Differenzen bei der Berechnung von Subeinzugsgebieten wurden große Überlappungsbereiche festgelegt.

Subeinzugsgebiets-Berechnung

Für jedes der festgelegten Gebiete wurde die GRASS-Routine r.watershed mit einem Schwellenwert von 10000 Pixeln und der Option 'basin' aufgerufen. Die entsprechenden Datensätze mußten hierzu zwischen den Rechnern des Geographischen Institutes und den Anlagen des Rechenzentrums transferiert werden. Außerdem mußten die Prozesse bzw. Daten ständig kontrolliert werden, da am Rechenzentrum eine Zeitbeschränkung bezüglich der Lagerung von Daten auf den leistungsfähigen Rechnern (5 Tage) besteht. Die Erfahrungen mit dem entstehenden hohen Arbeitsaufwand motivierte uns zur Einrichtung des AFS auf unseren Rechnern, mit dem das beschriebene Datenhandling vollständig entfällt (siehe Kapitel 5.6). Da im Rechenzentrum ebenfalls eine Beschränkung bezüglich der Laufzeiten der Prozesse besteht (4 Wochen) mußten unsere Ausgangsdatenätze entsprechend limitiert werden (dies führte nach einigen Vorversuchen auf die genannten 17 Teilgebiete).

Ergebnisse

Die Ergebnisse der 17 Teilberechnungen wurden zusammengefügt, sodaß schließlich eine Subeinzugsgebietsmodellierung des Neckar mit einem Schwellenwert von 10000 Pixeln (9 km2) in der Orginalauflösung (30m) vorlag (siehe Graphik 56).

Die Rechenzeiten wurden ausgewertet um eine Abschätzung für die Gesamtmodellierung des Neckar bzw. der Weser zu erhalten. Insgesamt ergab sich eine reale Rechenzeit von über 100 Tagen bzw. eine effektive CPU-Zeit von ca. 15 Tagen. In Graphik 57 ist die Abhängigkeit der CPU-Zeit von der Datenmenge dargestellt. Interpoliert man die Ergebnisse auf die Gesamtdatenmengen des Neckar bzw. der Weser (siehe Graphik 58) werden folgende CPU-Zeiten erreicht:

Gesamtmodellierung Neckar: 200-300 CPU-Stunden

Gesamtmodellierung Weser: 800-900 CPU-Stunden

Diese grobe Abschätzung zeigt, daß eine Modellierung der Gesamtgebiete in der gegebenen Auflösung für wichtige Parameter nicht realistisch ist. Eine Rastervergröberung erscheint uns deshalb als unumgänglich, um Rechenzeiten in akzeptablen Rahmen zu halten.

Rasterausdünnung

Wie im vorigen Kapitel ausgeführt, wird bei großen Datensätzen wegen der enormen Datenmengen eine Rasterausdünnung und eine damit verbundene Datenreduzierung notwendig. Damit geht allerdings ein Informationsverlust einher, der einen Einfluß auf die folgende Modellierung hat. Diesen Einfluß abzuzschätzen war entsprechend der nächste Arbeitsschritt. Hierzu wurden auf Teilgebieten der Weser und des Neckars Rastervergröberungen vorgenommen und der Einfluß auf die Bestimmung primärer Parameter unter dem GRASS-Modul r.watershed untersucht.

Vorgehensweise:

Es wurde ein Teilgebiet der Weser mit einer Fläche von 30x30 km2 nördlich des Harzes ausgewählt (Koordinaten: Nord 5766200, Süd 5736200, Ost 3601300, West 3572500). Dies entspricht etwa 1000x1000 Datenpunkten, so daß keine der folgenden Berechnungen länger als 5 Stunden dauert.

Aus der Konvertierung des Datensatzes in die metrischen Gauss Krüger Koordinaten folgte, daß die Daten in einem Gitter mit "unrunden" Koordinaten (31.15535812m) vorliegen. Um Folgefehler auszuschliessen, wurde deshalb der zu bearbeitende Ausschnitt mit r.resample.tps auf ein Gitter mit 30m Abstand umgerechnet ("Interpolation durch Spline"). Dieser neue Datensatz lag den folgenden Berechnungen zugrunde. Dabei wurden für 5 verschiedene Vielfache dieser Auflösung (60, 150, 300, 600 und 1200m) mittels r.watershed Einzugsgebiete (basins), Tiefenlinien (streams) sowie Gefälle (slope) und acc -Wert berechnet.

Die Berechnung der Einzugsgebiete und Tiefenlinien unterliegt einem weiteren Parameter, 'threshold', der dem Modul r.watershed angegeben werden muß. Er beschreibt die Größe des von r.watershed berechneten acc-Wertes, ab der Tiefenlinien ausgewiesen werden. Entsprechend variiert mit dem 'threshold' auch die mittlere Größe der Einzugsgebiete. Der Parameter 'threshold' läßt sich in km2 umrechnen, generisch muß er dem Modul r.watershed allerdings als Pixelanzahl angegeben werden. Wenn sich also die Auflösung halbiert z.B. von 30m auf 60m, so muß für den 'threshold' Parameter ein Viertel der bisherigen Anzahl Pixel angegeben werden, um den in km2 äquivalenten Schwellenwert zu erhalten, also 400 Pixel anstatt 1600. Da die Verwertbarkeit der Modellierungen stark von diesem Parameter abhängt, wurde der 'threshold' ebenfalls um 4 Werte variiert. Die entsprechenden Flächenmaße sind 46.08, 23.04, 5.76 und 1.44 km2. Ein Teil dieser Ergebnisse ist in Graphiken 62, 63 visualisiert. An der Treppenform der Umrisslinien lässt sich die durch die Rasterausdünnung wachsende Pixelgröße erkennen. Die Rasterausdünnung erfolgte zunächst nach der nearest-neighbor-Methode, wie sie in GRASS Standard ist. In einem weiteren Schritt wurden die oben beschriebenen Berechnungen wiederholt, wobei die Rasterausdünnung mittels r.resample.tps, also durch Interpolation mit splines und tension, vorgenommen wurde. Bei der Interpolation mußte leider beobachtet werden, daß die Rechenzeit mit Vergröberung des Ergebnisgitters anstieg! Ein resampling auf ein 10 mal gröberes Gitter war nicht mehr möglich, weil die temporären Dateien zu groß wurden.

Als nächstes ging es darum, die - wie beschrieben erzeugten - Dateien sinnvoll zu vergleichen. Als besonders geeignet erschienen zu diesem Zweck die von r.watershed erzeugten Subeinzugsgebiete ('basins'). Ein Grund dafür ist, daß die Einzugsgebiete für viele hydrologische Fragestellungen eine wichtige Rolle spielen, ein anderer, daß es sich im Vergleich zu etwa 1 Million acc-Werten um eine überschaubare Anzahl klassifizierter Objekte handelt. Ein visueller Vergleich der errechneten basin Rasterlayers ist bereits sehr informativ. Zur "Quantifizierung der Ähnlichkeit" wurde folgendes Verfahren angewendet: Separat für jeden 'threshold' wurden als bestes Ergebnis die jeweils in der 30m Auflösung gerechneten basin-Daten gesetzt. Mit dem bei uns entwickelten GRASS-Tool r.statistics (option: distribution) wurde die Kreuzkorrelation zwischen dem besten Ergebnis und den in gröberen Auflösungen gerechneten Layern berechnet. Als Ergebnis liegt eine Tabelle vor, aus der hervorgeht, wie groß der Anteil verschiedener Kategorien der zweiten Karte ist, die im Bereich einer bestimmten Kategorie, der als besten gesetzten ersten Karte liegen. Für jedes Einzugsgebiet auf dem 30m Layer erhält man also auch eine Kategorie aus dem zu vergleichenden Layer, die am meisten überlappt - typisch 50 -99%. Der Mittelwert des Überlappungsgrades dieser jeweils am stärksten überlappenden Kategorien wurde als Maß für die Ähnlichkeit zweier Layer verwendet. Für jeden 'threshold' wurde dieser Ähnlichkeitswert in Abhängigkeit von der region aufgetragen (Graphiken 60, 61).

Ergebnisse:

Die Ergebnisse zeigen die erwarteten Tendenzen: 1) Die Übereinstimmung nimmt mit Zunahme der Gitterausdünnung ab. 2) Die Übereinstimmung nimmt mit Zunahme des 'thresholds' zu (Graphik 59). Augenfällig ist zunächst der einem exponentiellen Zerfallsgesetz folgende Abfall der Ähnlichkeit mit wachsender Rasterbreite. Die Abweichung nimmt also proportional zur bereits bestehenden Abweichung ab. Da das Modul r.watershed zunächst den acc-Wert für jedes Pixel, also die Anzahl Pixel, die durch ein gegebenes Pixel drainieren, berechnet, liegt folgende Vorstellung nahe: Eine relevante Abweichung des acc-Wertes entsteht nur, falls durch die Ausdünnung ein Pixel, das auf einer lokalen Wasserscheide liegt (="kritischer Punkt"), entfernt wird. Dann nämlich ändert sich der acc-Wert für alle folgenden Pixel. Für ein Layer existiert also immer nur eine relativ kleine Zahl "kritischer Punkte", deren Entfernung zu kaskadenförmigen weiteren Veränderungen des acc-Wertes führen kann. Der Wegfall eines Gitterpunktes in der Talsohle ändert den Strömungsverlauf nicht. Der Wegfall bestimmter Kammpunkte oder von Kuppen auf konvexen Hängen führt zu frappanten Änderungen des Strömungsverlaufs.

Für die Erklärung des reziprok exponentiellen Kurvenverlaufs kommen verschiedene Überlegungen in Frage. Vorausgesetzt wird dabei, daß signifikante Abweichungen im Strömungsverlauf nur durch den Wegfall von kritischen Punkten entstehen. Die einfachste Annahme wäre, daß beim Wegfall von kritischen Punkten keine weiteren kritischen Punkte entstehen. Dann hätte man ein dem radioaktiven Kernzerfall analoges Modell. Da es aber plausibel ist, daß beim Wegfall exponierter Pixel andere Pixel die Funktion von Wasserscheiden übernehmen, muß diese Idee wohl ergänzt werden mit der Überlegung, daß die " Kritizität " dieser neuen kritischen Punkte geringer ist, ihr Wegfall bei weiterer Rasterausdünnung also weniger folgenreich ist. Dafür spricht, daß erstens die neuen Wasserscheiden tiefer liegen und zweitens eine Zahl Pixel beim Wegfall eines kritischen Punktes auch die Wasserscheidenfunktion verliert, so daß die Gesamtzahl kritischer Punkte nicht zwangsweise zunehmen muß.

Über den folgenden steilen Abfall der Kurven wird angenommen, daß statistische Gründe eine Rolle spielen. Die Anzahl der Pixel in den Layern weicht dann schon um den Faktor 20 bis 40 voneinander ab. Sicher ist, daß statistisch ein Mindestwert existiert, da ja auch ein Zufallslayer mit der gleichen Flächenstreuung eine gewisse kleinste Überdeckung zeigen würde, die wohl kaum weit von 50% entfernt sein dürfte. Diese erwartete Sigmoidal Form der Kurve trat bereits auf, wenn die Kreuzkorrelation zwischen den Layern entlang dem jeweils gröberen Raster und nicht, wie hier vorgestellt, entlang dem genauesten Raster gebildet wurde.

Die Abhängigkeit der Kurven vom Parameter 'threshold' lässt sich weniger einfach auf den Ansatz mit kritischen Punkten zurückführen. Das r.watershed Modul weist Pixel mit einem acc-Wert oberhalb des thresholds als "streams" aus. Die Einzugsgebiete ('basins') werden dann für die einzelnen stream-Abschnitte zurrückgerechnet. Wenn nun ein kritischer Punkt entfällt, ändert sich der acc-Wert bei einer Zahl abhängiger anderer Pixel. Die streams werden also erst dann vom Wegfall eines kritischen Punktes berührt, wenn die Auswirkungen so groß sind, daß Pixel mit dem acc-Wert über dem 'threshold' diesen unterschreiten, oder andere Pixel den 'threshold' überschreiten. Es ist aber klar, daß sich die Einzugsgebiete - also die Menge Pixel die in ein bestimmtes stream segment drainieren - schon lange verschoben haben können, wenn bei den streams selbst noch keine Änderung eingetreten ist. Die Überlegung zeigt, daß die Berechnung von streams unempfindlicher gegen Rasterausdünnung ist, als die Berechnung von basins, was durch den visuellen Vergleich der Ergebnisse bestätigt wird (Graphik 63). Die Rolle des 'threshold' Parameters in den Plots ist nicht quantifizierbar. In einer ersten ersten naiven Näherung würde man den 'threshold' im Nenner des Arguments der Exponentialfunktion erwarten, sozusagen als Maß für die Konzentration relevanter kritischer Punkte. Für den größten 'threshold' wird die Statistik schlecht, weil nur noch wenige basins in dem ausgewählten Teilgebiet entstehen. Über die Größe der zu wählenden thresholds ist zu sagen, daß erst ein threshold der acht mal kleiner ist, als der hier vorliegende kleinste Wert ( 1.44 qkm ) für streams Ergebnisse liefert, die den Gewässerläufen von topographischen Karten im Maßstab 1:25.000 entsprechen.


<< , >> , Titelseite , Inhaltsverzeichnis