Software und Methodik 1. Software Das hier von mir verwendete Geographische Informationssystem GRASS (Geographical Resources Analysis Support System) ist ein GIS, welches ab 1982 vom U.S. Army Corps of Engineers/CERL (Construction Engineering Research Lab) für militärische Planungszwecke entwickelt wurde. Ende der 80er Jahre stellte das CERL das gesamte Softwarepaket der zivilen Öffentlichkeit zur Verfügung. Seit 1997 haben das sogenannte GRASS Development Team an der Baylor University in Texas und der Universität Hannover sowie Experten aus aller Welt die Weiterentwicklung übernommen. Die regelmäßig aktualisierten Versionen von GRASS sind kostenlos über das Internet zu erhalten. Ich habe in erster Linie mit der Version GRASS5.0beta gearbeitet und Ergänzungen mit der nachfolgenden Version GRASS5.0 vorgenommen. Bei GRASS handelt es sich um ein kombiniertes Raster-/Vektor-GIS mit einem integrierten Bildverarbeitungs- und Visualisierungssystem. Es enthält inzwischen über 300 Programme und Hilfsmittel, um Raster-, Vektor- und Punktdaten zu bearbeiten, Karten zu erzeugen, Multispektralbilddaten zu prozessieren und räumliche Daten zu erstellen (3D-Visualisierung). Neben einer graphischen Benutzeroberfläche gibt es auch eine kommandozeilenorientierte Befehleingabemöglichkeit. Die bearbeiteten Objekte lassen sich auf sogenannten Monitoren (X0 bis X10) darstellen, welche separat aufgerufen werden müssen und alle nebeneinander laufen können. Es ist möglich, mit dem Modul g.region die Größe des "aktiven Ausschnitts" eines Monitors zu variieren, um Rechenprozesse der Kapazität des Computers anzupassen oder beispielsweise lediglich einzelne Teile eines DGM für die Berechnung zu selektieren. Eine solche findet im Hintergrund statt, so daß gleichzeitig andere Arbeitsschritte vorgenommen werden können. GRASS kann auf externe Datenbanken zum Berechnen neuer oder Speichern bereits vorhandener Daten zugreifen, Karten und Daten vieler kommerzieller GIS-Pakete importieren, und es erlaubt die eigene Programmierung neuer Module. (NETELER, M., 2000) 2. Methodik Der Weg zum DGM und seiner Reliefierung DGM Lhasa DGM Ringsee (Yamco Yumco) Zur Bearbeitung der eingangs erwähnten Kartenkopien habe ich sie im von Dr. K.-H. Müller geleiteten GIS-Labor des Fachbereichs Geographie der Universität Marburg durch einen DIN A0-Scanner laufen lassen und nebst der ebenfalls gescannten Dias auf CD gebrannt. Da die gescannten DIN A3-Karten eine Größe von je ca. 50 MB aufwiesen, konnte ich sie trotz Erweiterung meines Arbeitsspeichers von 64 auf 196 MB nur abschnittsweise aufbereiten. Die GIS-Daten werden bei GRASS in einer Verzeichnisstruktur gespeichert. Bevor mit der Arbeit begonnen werden kann, muß dafür ein "Standardunterverzeichnis" (als GRASS-Database bezeichnet) nutzerseitig erzeugt und später in GRASS angegeben werden. Darin organisiert GRASS selbsttätig seine Daten in Form von weiteren Unterverzeichnissen. Ein Projektgebiet wird als location bezeichnet. Sie wird über ihre geographischen Ränder mit Koordinatenangaben und zusätzliche Projektionsangaben wie Koordinatensystem und Bezugsellipsoid definiert. Innerhalb dieser location können Arbeitsgebiete, sogenannte mapsets, festgelegt werden. Häufig reicht aber die Erzeugung einer mapset, die so groß wie die location ist. Es besteht die Möglichkeit, Karten zunächst ohne Projektionsangaben in einer entsprechend groß eingestellten xy-location abzulegen. Solange beispielsweise das Koordiantensystem nicht bekannt ist, können diese Karten dort weiterbearbeitet und erst später georeferenziert werden. Ich habe letzteren Weg wählen müssen. GRASS besitzt gegenüber den mir bekannten kommerziellen GIS wie MapInfo einen entscheidenden Vorteil, was das Digitalisieren von Linien angeht, nämlich die Möglichkeit der automatischen Vektorisierung. Linien, welche im Rasterformat vorliegen, werden zunächst mit dem Modul r.thin verdünnt und anschließend mit r.line in das Vektorformat umgewandelt. Jetzt liegen die entsprechenden Linien digitalisiert vor und können nach Eingabe des Befehls v.digit mit Höheninformationen besetzt werden. Das extrem aufwendige Digitalisieren per Maus oder am Digitalisierbrett bei ständigem Setzen sogenannter Paßpunkte bleibt einem damit erspart. Stattdessen ruft man unter LINUX ein Paint-Programm auf, liest die gescannten Karten ein, legt einen neuen Layer darüber und zeichnet die Höhenlinien sauber ab. Dieser Layer wird später gesondert abgespeichert, von GRASS importiert und dort unter einem bestimmten Namen als Rasterdatei verwaltet. Letztere wird nach der Vektorisierung durch r.line parallel als Vektordatei geführt. Mit Hilfe des Moduls v.digit ordnet man jeder Linie der Vektordatei x eine Höhe zu. Die aus der topographischen Grundlagenkarte hervorgehende Differenz zwischen den einzelnen Höhenlinien kann in der entsprechenden Zeile eingegeben werden, so daß GRASS fehlende Intervalle eigenständig rechnet und ausfüllt. Liegen schließlich alle Werte vor, wird die Vektordatei mit v.to.rast in das Rasterformat zurücktransformiert, damit GRASS nach dem Aufruf von r.surf.contour eine geschlossene Oberfläche daraus interpolieren kann. Zuvor muß eine neue Rasterdatei benannt werden, welche nach langwierigen Rechenprozessen das DGM (Digitales Geländemodell) beinhaltet. Per Modul d.what.rast lassen sich jetzt genaue Höheninformationen an beliebiger Stelle abfragen. Verschiedene Farben und deren Sättigungsgrad geben zu erkennen, wie Gebirgszüge und Talschaften verteilt sind. Um ein vollständiges Reliefbild mit Hangneigungen und -expositionen zu erhalten, muß das Modul r.slope.aspect gestartet werden: "r.slope.aspect el=DGM as=Hangexpositionskarte" (el=Karteneingabe, as=neue Kartenausgabe). In kürzester Zeit berechnet es eine plastische, nach unterschiedlichen Grautönen abgestufte Oberflächenstruktur der Landschaft. Die Besonnung ist dabei jedoch nicht variabel. Will man sie verändern, muß das Modul shade.rel.sh letztere Rechenprozesse übernehmen. Es ist etwas langsamer und lieferte mir unter GRASS5.0beta nicht immer die gewünschten Ergebnisse, da die Auflösung geringer war als bei r.slope.aspect. Dafür kann man den Sonnenstand genau einstellen, und Täler kommen realistischer zur Geltung. Es besteht aber die Möglichkeit, beide Ergebnisse miteinander zu verschneiden. Das Modul r.mask erlaubt die Ausmaskierung zuvor eingegrenzter Gebiete. Man nimmt also beispielsweise über die entsprechende Höhendeterminierung sämtliche Talschaften aus dem DGM heraus und läßt nur diese von shade.rel.sh rechnen. Mit r.patch kann man sie anschließend über die mit r.slope.aspect erzeugte Karte legen. Wichtig dabei ist allerdings, daß die Bereiche rund um die isolierten Talschaften "no data" entsprechen, weil sie ansonsten die erste Karte nivellieren würden. Besitzen sie also einen bestimmten Wert, so muß dieser unter Zuhilfenahme von r.mapcalc, einem Modul für Kartenalgebra, annulliert werden: "Neue Karte = if(Karte x==1, null(), Karte x)" In Worten: Der Wert "1" von Karte x soll unter Beibehaltung der übrigen Werte in "no data" umgewandelt werden. Das Ergebnis lautet "Neue Karte". Manchmal kommt es vor, daß in den Reliefkarten Datenlöcher auftreten. Solche machen sich als schwarze Bereiche bemerkbar. Das Modul r.surf.contour schließt diese Löcher durch die Bildung eines gewichteten Durchschnitts. Gewisse Abweichungen von der Realität lassen sich nicht vermeiden. Diverse Bereiche der topographischen Karten sind aufgrund des Qualitätsverlustes durch Kopieren und Scannen nicht mehr eindeutig identifizierbar und mußten von mir deshalb generalisiert werden. Zur besseren Orientierung ist es notwendig, Isohypsen (Höhenlinien) über das DGM zu legen. Da ich topographische Karten im Maßstab 1:100.000 digitalisiert hatte, wiesen die Höhenlinien einen Abstand von 40 m auf. Bei den Ausschnitten im Maßstab 1:500.000 waren es entsprechend 200 m. Als Kompromißlösung habe ich einen Abstand von 100 m gewählt. So ist gewährleistet, daß das DGM gut erkennbar bleibt und man gleichzeitig die Höhe jedes beliebigen Punktes relativ genau ablesen kann. Leider haben sich allerdings durch die Umrechnung Fehler verstärkt oder neu eingeschlichen. Insbesondere an den Nahtstellen der einzelnen Kartenteile und in den Bereichen, welche ich aufgrund mangelnder Erkennbarkeit generalisieren mußte, laufen Höhenlinien zusammen oder enden im "Nichts". Probleme gab es diesbezüglich auch durch die Verschneidung von Karten im Maßstab 1:100.000 und 1:500.000 im "Yamco Yumco-Areal". Die Umrechnung läuft nun folgendermaßen ab: Mit g.region wird zunächst die Größe des zu bearbeitenden DGM eingestellt: "g.region rast=DGM". Das Modul d.erase informiert anschließend durch einfachen Aufruf die Grafikausgabe von den vorgenommenen Änderungen. Ein einziger Rechenschritt genügt, um das ausgewählte DGM in Vektorlinien (Höhenlinien) beliebigen Abstands umzuwandeln: "r.contour input=DGM step=Schrittweite (Abstand in m) output=Höhenliniendatei" In Worten: Das Modul r.contour wandelt die Rasterdaten des DGM unter Angabe des gewünschten Abstandes in Vektordaten um, welche man zwecks leichterer Handhabe bei der Verschneidung mit v.to.rast wieder in das Rasterformat transformieren kann. Die abschließende Georeferenzierung der DGM ist notwendig, um sie zu entzerren und auf diese Weise eine möglichst maßstabsgerechte Abbildung im Gauß-Krüger-Koordinatensystem zu erreichen. Zunächst müssen die DGM mit Hilfe des Moduls i.group in sogenannten "Bildgruppen" eingetragen werden. Letztere enthalten dann die zu bearbeitenden Rasterdaten. i.target ermöglicht anschließend die Angabe eines Transformationsziels, welches in diesem Fall der Gauß-Krüger-location entspricht. Nun ist es erforderlich, geographische Referenzen zu setzen, um dem Transformationsmodul anzugeben, welche neuen Koordinaten die einzelnen Pixel in der Gauß-Krüger-location bekommen sollen. Dazu werden den Eckpunkten der DGM in der xy-location nach dem Aufruf von i.points die entsprechenden geographischen Koordinaten zugewiesen. Das Modul i.rectify übernimmt nachfolgend die Transformation. Die Erstellung der Vegetationskarten Auch hierbei dienen die DGM als Informationsgrundlage, wobei zwischen den reinen DGM und den mit r.slope.aspect erzeugten Reliefbildern zu unterscheiden ist. Die reinen DGM enthalten nur die Höhenwerte, dargestellt anhand verschiedener Farbtöne, die Reliefbilder hingegen zeigen die unterschiedlichen Hangexpositionen durch abgestufte Grautöne. Jedem dieser Grautöne ist ein Wert zwischen 0 und 360 zugeordnet. Um zu verdeutlichen, welcher Wert welche Hangexposition darstellt, habe ich mit Microsoft Excel 97 folgende Grafik entworfen: In GRASS definierte Hangexpositionswerte (eigener Entwurf) Die Grafik besteht aus einem Kreisdiagramm ("Kuchendiagramm"). In Rot sind die Haupthangexpositionen Norden, Osten, Süden und Westen markiert, in Schwarz die restlichen (Nordosten, Südosten, Südwesten und Nordwesten). Hinter den Hangexpositionen stehen die stellvertretenden Werte (90, 360, 270, 180 usw.). Wie nun gelangt die potenzielle Vegetation auf die DGM (Reliefkarten)? Dazu ist eine Verschneidung zwischen Höhenmodell (reines DGM), Reliefbild und den Informationen aus den vier Diagrammen notwendig. In letzteren ist die potenzielle Verbreitung von Juniperus convallium und Juniperus tibetica aufgrund unterschiedlicher klimatischer Faktoren in Haupttaltyp (HTT), Seitentaltyp (STT) und Yamco Yumco-Typ (YYT) eingeteilt worden. Für jede Hangexposition wurde jeweils ein bestimmter Höhenbereich festgelegt, der für eine mögliche Besiedlung durch die gerade genannten Wacholderarten in Frage kommt. Nähere Erläuterungen zu diesen Sachverhalten finden sich auch in Kap.4 Auswertung. Da die Abgrenzungen zwischen den einzelnen Klassifikationstypen nicht höhenlinienparallel verlaufen, mußte ich sie in Paint Shop Pro per Hand auf den Reliefkarten einzeichnen und sämtliche Berechnungen zunächst für die gesamten Areale durchführen. Anschließend habe ich die potenziellen Waldflächen als png-Rasterdateien exportiert und in Paint Shop Pro als Layer über die Reliefkarten gelegt. Nun war es mir möglich, ebenfalls per Hand die jeweiligen potenziellen Waldflächen auf die eingegrenzten Bereiche zu reduzieren. Rechenbeispiel für die potenzielle Verbreitung von Juniperus tibetica im Einflußbereich der Haupttäler (HTT): "HTT = eval( if((Lhasa-DGM>4100 && Lhasa-DGM<4250),1,null()) + if((Lhasa-Hangexpositionskarte<135 && Lhasa-Hangexpositionskarte>45),1,null()) ) || eval( if((Lhasa-DGM>4200 && Lhasa-DGM<4550),2,null()) + if((Lhasa-Hangexpositionskarte>315 && Lhasa-Hangexpositionskarte>45 || Lhasa-Hangexpositionskarte<45),2,null()) ) || eval( if((Lhasa-DGM>4600 && Lhasa-DGM<4850),3,null()) + if((Lhasa-Hangexpostionskarte>225 && Lhasa-Hangexpositionskarte<315),3,null()) ) || eval( if((Lhasa-DGM>4150 && Lhasa-DGM<4650),4,null()) + if((Lhasa-Hangexpostionskarte>135 && Lhasahangexpositionskarte<225),4,null()) )" Ich habe diese Formel durch Kombination verschiedener Funktionen und Rechenterme von r.mapcalc speziell auf meine Ziele zugeschnitten und versucht, möglichst viele Schritte einzubringen, um den Arbeitsaufwand zu minimieren. Trotzdem war der Zeitaufwand nicht unerheblich, ganz abgesehen von der anschließenden Berechnungsdauer meines PC. Die Formel in Worten: Wenn (if) das Lhasa-DGM einen Höhenbereich von 4100-4250 m über NN aufweist, so soll es den Wert "1" bekommen und alle anderen Werte sind zu annullieren (null()) plus (+) wenn (if) die Lhasa-Hangexpositionskarte Werte zwischen 135 und 45 aufweist (Nordwesten-Nordosten), so soll sie den Wert "1" bekommen und alle anderen Werte sind zu annullieren (null()). Das verschnittene Ergebnis soll als Zwischenwert gespeichert (eval) und mit dem Ergebnis des nächsten Rechenterms verknüpft werden (||) usw. Das Gesamtergebnis ist schließlich unter dem Dateinamen HTT (Haupttaltyp) zu verwalten. Die Zahlen 1-4 repräsentieren die einzelnen Höhenbereiche, welche den entsprechenden Hangexpostionen zugewiesen wurden. Zu sehen ist nun ein grünes Farbmosaik (die Farben sind frei wählbar), welches in einem Layer alle Ergebnisse der Formel beinhaltet. Entsprechendes ist für STT (Seitentaltyp) und YYT (Yamco-Yumco-Typ) durchzuführen, wobei natürlich noch zwischen Juniperus convallium und Juniperus tibetica unterschieden werden muß. Deren reliktische Standorte habe ich mit Hilfe des Moduls s.in.ascii (verarbeitet Punktdaten, sogenanntes "sites-Format") innerhalb des ausgewählten Areals (g.region rast=DGM) per Koordinaten- und Höheneingaben fixiert, anschließend mit s.to.rast in das Rasterformat zurücktransformiert und als Layer über die entsprechenden Karten gelegt.