WebGIS-gestützte Kooperationsplattform zur Datenspeicherung und -Analyse im Umfeld einer Grundwasserkontamination mit regionaler Verbreitung Tilmann STEINMETZ Dieser Beitrag wurde nach Begutachtung durch das Programmkomitee als reviewed paper angenommen. Zusammenfassung Vorgestellt wird ein browsergestütztes GIS als Frontend für ein Content Management System zur Zusammenarbeit bei der Bearbeitung räumlich basierter Datensätze von verteilten Arbeitsplätzen. Dieses dient nicht nur zur Speicherung und Abfrage sowie Visualisierung räumlicher Datensätze und damit ihrem leichteren Auffinden und ihrer Dokumentation, sondern übernimmt auch teilautomatisierte Analysefunktionen der Attributdaten und ermöglicht das Preprocessing der Datensätze zur Weiterverwendung in Software zur Risiko- Analyse und Interpolation von Grundwasserdaten. Mit den fertig gestellten Ergebnissen können serverseitig Berichte, z.b. in pdf-form erzeugt und von dort anderen Benutzern bzw. Entscheidern zur Verfügung gestellt werden. Auf diese Weise soll zum ersten eine beschleunigte Bearbeitung von Raumdaten ermöglicht werden, deren Vorbereitung zur Analyse und grundsätzliche Kontrolle mittels explorativer Datenanalyse sonst einen großen Teil der Zeit im Arbeitsablauf in Anspruch nimmt. Andererseits werden Bearbeiter, die mit statistischen Methoden nicht sehr tief reichend vertraut sind, in Art eines Expertensystems von der Last der Datenvorbereitung befreit und bei der Bearbeitung und Analyse mit statistisch-analytischen Methoden unterstützt. Letztendlich trägt das System zur Entscheidungsunterstützung bei der risikobasierten Bearbeitung eines Standortes mit regionaler Grundwasserkontamination bei. 1 Einleitung Für die Speicherung und Beurteilung faktischer und analytischer Informationen im Projektraum einer Chemie-Altlast mit regionaler Verteilung sind umfangreiche, räumlich und zeitlich referenzierte Messdaten sowie toxikologische Referenzwerte zu speichern. Vor dem Hintergrund der Landnutzung und unter zusätzlicher Berücksichtigung der Grundwasserströmungsverhältnisse dargestellt, dienen sie als Werkzeug zur Risikoabschätzung und als Planungsunterstützungssystem. Das projektierte System vereinigt unterschiedliche Open Source Projekte als wissensbasiertes System mit Raum- und Zeitbezug. Dazu werden die unterschiedlichen Softwaremodule in einem Content Management System (ZOPE i ) unter einer einheitlichen Oberfläche verbunden. Für den Benutzer transparent wird die Fülle der bisher isoliert gehaltenen Daten übersichtlicher präsentiert. Für den auswertenden Bearbeiter wird durch verbessere Übersichtlichkeit und schnelleren Zugang die Beurteilung verein-
624 T. Steinmetz facht, indem er sich eher auf die Durchführung von Analysen und deren Ergebnisse als auf die Ausgangsdaten konzentrieren kann. 2 Datenlage und Problemstellung Die strukturierte Speicherung und Auswertung der Messdaten aus einem über 10 Jahre andauernden Grundwasser-Monitoringprogramm von über 300 Stoff- und anderen Parametern stellt schon für sich allein kein triviales Problem dar. Sind diese Daten im Hinblick auf eine Expositions- bzw. Risikoabschätzung zudem vor dem Hintergrund der Landnutzung zu betrachten, ergibt sich aus der Fülle der Daten eine gewissermaßen immanente Unübersichtlichkeit, die bei der Nutzung und Auswertung zwangsweise hinderlich sein wird (BMBF-Projekte Ad-Hoc FKZ PTJ 0330492, SAFIRA BMBF-FKZ: 02WT0412, WYCISK et al. 2002, 2003, 2005). Außer den reinen Messwerten müssen bei den Auswertungen der geologisch-sedimentologische Aufbau des Untergrundes, die Grundwasserströmung sowie die gesetzlichen bzw. normativen Vorgaben zur Altlastenbearbeitung berücksichtigt und nach Möglichkeit dargestellt werden. Hinzu kommt die Schwierigkeit, dass verschiedenen Nutzern, im Sinne von Projektbeteiligten, welche unterschiedliche Rollen bei der Verarbeitung einnehmen, die ihrer Rolle entsprechenden Arbeitsabläufe ermöglicht bzw. zugewiesen werden müssen. So muss z. B. nicht jeder der Beteiligten in der Lage sein, neue Daten in das System einzupflegen und nicht alle Ergebnisse der Regionalisierung und der Risikoabschätzung müssen per se jedem Bearbeiter auf gleiche Weise zur Verfügung stehen. Das vorgestellte System verfolgt daher das Ziel als browsergestütztes System durch zentralisierte Datenhaltung und auch eine zentralisierte Bereitstellung vorgefertigter statistischanalytischer Methodik den Beteiligten in der Arbeitsgruppe und zugelassenen externen Beratern eine Kooperationsplattform an die Hand zu geben. Zudem soll das System das Auslesen der Ausgangsdaten in verschiedenen generischen Formaten für spezialisierte Software zum Risk Assessment oder der räumlichen Interpolation ermöglichen. Es ergibt sich demzufolge ein System, welches logisch zwei Teile beinhaltet: ein Backend als Datenspeicher und Applikationsserver sowie ein Frontend als Bedienelement für die Benutzer. Dadurch ergeben sich auch zwei Bedienerkreise: Im Hintergrund agieren Administratoren zur Pflege des eigentlichen Systems und der Ausgangsdaten, während die eigentlichen Benutzer browserbasiert auf diese Daten zugreifen und Analysen durchführen. Die Grenzen zwischen diesen beiden sind naturgemäß in der Praxis fließend. Die folgende Beschreibung der Aufgaben des Systems orientiert sich an diesen unterschiedlichen Aufgaben, ausgehend vom Backend, in dem ein Administrator Daten und Algorithmen zur Verfügung stellt, hin zum Frontend, in dem der avisierte Nutzer Analysen an diesen durchführt und Ergebnisse in Berichten erzeugt. 2.1 Backend: Datenspeicherung Bei den zu verarbeitenden Daten handelt es sich zum um Daten mit oder ohne Raumbezug. Für Daten wie z. B. Bohrdaten oder Grundwasser-Messdaten liegt aufgrund ihres Raumbezugs die Speicherung, Abfrage und Analyse in einem Geoinformationssystem nahe, während für die nicht raumbezogenen Daten eine Speicherung im Dateisystem oder einer relati-
WebGIS-gestützte Kooperationsplattform zur Datenspeicherung und -Analyse 625 onalen Datenbank gewählt wird. Zur Verbesserung der Datenintegration ist die Vereinigung beider Datenarten unter dem Dach eines Content Management Systems wünschenswert. Im vorliegenden Fall handelt es sich bei den implizit raumbezogenen Daten um Messdaten der Grundwasserkontamination aus einem über 10 Jahre währenden Monitoringprogramm, sowie die daraus erzeugten Interpolationsdaten für ihre flächendeckende räumliche Verteilung in Form unterschiedlicher Rasterformate. Die beim Anlegen der Messpunkte gewonnenen geologischen Bohrdaten waren ursprünglich in Bohrprotokollen und -profilen zunächst in Papierform, dann digital und schließlich in spezieller Software zu einem detaillierten 3D-Untergrundmodell verarbeitet worden. Mit hydrogeologischer Standardsoftware sind Grundwasserströmungsmodelle erstellt worden, als deren Ergebnis Bahnliniendarstellungen in ESRI-Shapefiles vorliegen. Zur Vereinheitlichung des Zugangs sind letztere in einer PostgreSQL-Datenbank mit Postgis-Aufsatz abgelegt worden. Aus Interoperabilitätsgründen wird diese mit einer ArcSDE (Spatial Database Engine) basierend auf einer Oracle-Datenbank synchron gehalten. Formulare in Zope ermöglichen intuitiven Zugriff auf die Datenbankobjekte. Der Export der Daten in vorgegeben Formaten lässt sich mit Templates auf diese Weise so standardisieren, dass Nutzer nur noch die benötigten Ausgangsdaten und das benötigte Zielformat auswählen müssen Abb. 1: Verbindung zur PostgreSQL-DB im Zope Management Interface mit den enthaltenen Tabellen 2.2 Frontend: Datenanalyse Die zugrunde liegenden Daten, insbesondere die Attributdaten der Grundwasseranalysen, sind großteils stark rechtsschief verteilt und zensoriert, d.h. viele Werte liegen unterhalb der
626 T. Steinmetz Nachweisgrenzen und müssen daher vor ihrer Regionalisierung, also ihrer räumlichen Interpolation mit geostatistischen Verfahren, insbesondere Kriging, einer eingehenden räumlich-statistischen Analyse unterzogen werden. Auch ist die Beprobung nicht auf einem regelmäßigen Gitternetz von Messpunkten, sondern unregelmäßig entlang der kontaminierten Bereiche, bzw. zur Abstromsicherung vorgenommen worden. Als Maß zur Optimierung der Beprobungsdichte kann die Unsicherheit beim Kriging durch Hinzufügen theoretischer Beprobungspunkte verwendet werden. Teile dieser Prozedur soll das vorgestellte System durch vorprogrammierte statistische Algorithmen automatisieren. Ebenso sollen Interpolationsverfahren durch mehr oder weniger standardisierte Vorgaben bei der Parametrisierung vereinfacht werden. Häufige Aufgaben umfassen z.b. nach explorative räumlicher Datenanalyse und Punktmusteruntersuchung die Interpolation und Kartendarstellung, die sich hiermit automatisiert durchführen lassen. 3 Funktionelle Bestandteile des Systems 3.1 Content management und Workflow-Steuerung Zur Speicherung der Inhalte kommt das System Plone, dem ZOPE zum Aufbau von Content Management Systemen (CMS) zugrunde liegt, zum Einsatz. Es basiert auf der Programmiersprache Python und ist mit so genannten Produkten modular sehr leicht erweiterbar. Plone ist ein reifes Open Source Projekt, das in vielen auch großen Produktionsumgebungen eingesetzt wird. Plone arbeitet nach dem Model View Controller-Konzept, das eine strikte Trennung von Inhalten und Präsentationslogik vorsieht und gehorcht allen W3C- Standards für Normenkonformität und Barrierefreiheit im Netz. Intern besitzt ZOPE ein integriertes, nichtrelationales, objektorientiertes Datenbanksystem, das indexiert u.a. eine schnelle Volltextsuche ermöglicht. Zur Speicherung externer Inhalte, z.b. bei Vorliegen großer Mengen Dokumentation in pdf-form, lassen sich Inhalte aus dem Dateisystem oder aus relationalen Datenbanksystemen einbinden. Die Speicherung der räumlichen Daten erfolgt in Form von ESRI Shapefiles oder als Verbindung zu PostGIS-Datenbanken, die jeweils als Objekte der ZOPE Datenbank bekannt gemacht werden. Auch Web-Map- Services lassen sich im Projekt einbinden. Workflow Management Plone verfügt über einen eingebauten Workflow, der sich für die oben beschriebenen Abläufe anpassen lässt. In jedem Status des Workflows stehen dem mit der jeweiligen Rolle im System angemeldeten Nutzer nur die für ihn freigegebenen Daten zur Ansicht oder Bearbeitung zur Verfügung. Nichtangemeldete Benutzer sehen nur freigegebene Daten und können keinerlei Veränderungen vornehmen. Angemeldete Benutzer können die von ihnen bearbeiteten Daten an den jeweils nächsten Bearbeitungs-Schritt im Workflow weiterreichen oder zurückziehen. Die beschriebenen und im Content Managment System anzulegenden Rollen der Nutzer lassen sich wie folgt beschreiben: Administratoren legen die erforderlichen Rohdaten im System an, machen sie also für die Bedienung per Weboberfläche/Content Management System zugänglich.
WebGIS-gestützte Kooperationsplattform zur Datenspeicherung und -Analyse 627 Analysten erzeugen daraus Kartendarstellungen in Form der Rohdaten, bestehender Interpolationsdaten und kontextrelevanter Informationen wie toxikologischer Daten und normativer Vorgaben. In einem Review-Prozess werden diese Karten zur Analyse weitergeleitet und dort statistisch untersucht. Hierbei kommen Punkt- und Flächenstatistik zum Einsatz. Hinweise auf möglicherweise zu erwartende Probleme bei der Interpolation bzw. Regionalisierung können hierbei aufkommen und vermerkt werden. Sind die Voraussetzungen erfüllt, wird interpoliert und die Daten wiederum abgelegt, um später vom Administrator ins System eingepflegt werden zu können. Fertige Regionalisierungsdarstellungen werden beispielsweise mit den Ergebnissen der Grundwassermodelle und Landnutzung kombiniert und hinsichtlich bestehender oder zu erwartender Risiken interpretiert und die Ergebnisse gegebenenfalls allen anderen Nutzern zur Begutachtung freigegeben. Zwischendurch oder nach vollständiger Durchführung dieses Reviewprozesses können Berichte in pdf-form erstellt werden und in definierten Bereichen des CMS abgelegt, oder im integrierten Weblog oder Forum diskutiert werden, die abgestuft mit oder ohne Passwort zugänglich sind. Diese Form der Kommunikation während der Review wird durch einfaches Verschicken von Links auf zu berücksichtigende oder zu bearbeitende Seiten oder Inhalte mit dem integrierten Mailserver vereinfacht. Ein Gruppenkalender kann die Terminplanung der Mitglieder vereinfachen. Das Ablegen von Favoriten bzw. Bookmarks, als Links auf Seiten innerhalb oder außerhalb der Plattform ist ebenso in diesen Workflow integriert. Wie erwähnt ist die Trennung zwischen Frontend und Backendarbeiten nicht komplett scharf trennbar: Administratoren können browserbasiert verschiedene Arbeiten durchführen und auch der normale Benutzer wird in unterschiedlichen Rollen an bestimmten definierten Punkten des Arbeitsablaufes verschiedene Aufgaben übernehmen können. 3.2 Räumliche Datenanalyse und Regionalisierung Als GIS zur Visualisierung und Abfrage kommt PrimaGIS zum Einsatz. Dies ist der Nachfolger des ebenfalls bereits in ZOPE integrierbaren ZMapServers (LINDENBECK 2004) und ist vollständig in den Workflow von Plone integriert. PrimaGIS stellt über Python eine Schnittstelle zum bekannten UMN-Mapserver über Python dar. Mit der Statistiksprache R, einem Klon des kommerziellen Produktes S-Plus werden Algorithmen zur beschreibenden Statistik und explorativen räumlichen Datenanalyse (ESDA) implementiert. Dazu gehören z.b. Summenstatistik, Histogramme, Box- und Whisker-Plots und QQ-Plots, und Punktmusteranalysen wie der Moran s I Index. Außer den bereits in der Datenbank oder als Raster vorhandenen Interpolationen lassen sich mit in R implementierten Methoden Interpolationen wie inverse distance weighted oder kriging interpolation durchführen. Die räumliche Auswahl der zu berücksichtigenden Punkte erfolgt im Kartenbild. Zusätzlich lassen sich z.b. zeitliche Einschränkungen für die Ausgangsdaten per SQL übergeben, für welche die Daten in Formularfeldern einzutragen sind. Auf diese Weise lassen sich beispielsweise Zeitscheiben interpolieren. Die vorgesehenen Algorithmen bzw. Verfahren liegen als Content- Objekte im CMS vor und werden als solche auf die Daten angewandt.
628 T. Steinmetz Als großer Vorteil ist zu sehen, dass das Content Management System über Formulare eine einfach bedienbare Schnittstelle sowohl zu den Werkzeugen für die Analyse wie zur Datenbank darstellt und zusätzlich die Visualisierungswerkzeuge integriert. Damit werden Analyse und Visualisierung auch Nutzern zugänglich, die bisher aufgrund der damit verbundenen technischen Hürden nicht beteiligt werden konnten. Abb. 2: Zentraler Bestandteil des Systems ist das CMS, welches webgestützt Funktionalität zur statistischen Analyse bzw. geostatistischen Interpolation, deren Darstellung im WebGIS und die Erstellung von Berichten ermöglicht. 4 Aufbau und Funktionsweise des Systems Als Betriebssystem wurde FreeBSD ii, ein UNIX -ähnliches, freies System gewählt, welches sich aufgrund der zu fordernden Stabilität als Serverbetriebssystem eignet. Praktisch jede moderne Software für UNIX oder LINUX, die im Quelltext vorliegt, lässt sich hierauf installieren, indem sie kompiliert wird, sofern der für die Programmiersprache erforderliche Compiler vorliegt. ZOPE wurde in der Version 2.7.8, Plone iii 2.1.1 installiert. PostgreSQL iv und PostGIS v dienen als Datenbank mit räumlichem Aufsatz. PrimaGIS vi bietet eine visuelle Oberfläche, mit der die in ZOPE abgelegten ZOPE Cartographic Objects ZCO (GILLIES 2004) über die Python Cartographic Library PCL innerhalb Plones Oberfläche zugänglich gemacht werden (s. Schema in Abb. 3). Dazu muss der UMN Mapserver vii mit Python- Mapscript-Unterstützung installiert sein. Für die on-the-fly Projektion verwendet dieser die proj4 viii -Bibliothek und zum Lesen und Schreiben zahlreicher Raster- und Vektorformatdaten die gdal ix - und ogr-bibliotheken. Im Gegensatz zur häufig verwendeten php- Schnittstelle des Mapservers hat im vorliegenden System das CMS über die Python- Schnittstelle und die Zope Cartographic Objects direkten Zugang zum Mapserver.
WebGIS-gestützte Kooperationsplattform zur Datenspeicherung und -Analyse 629 Abb. 3: Schematischer Aufbau der System-Komponenten PrimaGIS, ZCO und PCL R x in der Version 2.1.1 stellt sämtliche statistische Funktionalität bereit, indem es den RSessionDataAdapter über SOAP zur Verfügung stellt. R läuft als Server und lauscht auf einem bestimmten Port. Empfängt es Anforderungen auf Berechnungen, so wird eine R-Instanz gestartet, die Berechnung mit den übergebenen Daten gestartet und das Ergebnis zurückgegeben. Anforderungen erfolgen im vorliegenden Fall aus ZOPE heraus. Dieses System wurde als RStatServer xi von Gregory Warnes von Pfizer entwickelt. Aufgabe des Administrators für die vorgestellte Kommunikations- und Arbeitsplattform ist es, Daten in Form von Shapefiles auf den Server zu laden. Dies kann zum Beispiel über das HTTP-gestützte Protokoll WebDAV erfolgen. Ergänzungen und Veränderungen an der PostGis-Datenbank können z.b. über Microsoft Access als Frontend oder durch Export der Access-Daten über den PostgreSQL ODBC-Adapter vorgenommen werden. Dem Administrator kann außerdem die Aufgabe zufallen, Inhalte aller Art, wie Literatur oder Gesetzestexte in Form von PDF-, Word- oder HTML-Dateien auf den Server zu übertragen, wenngleich berechtigte Nutzer das auch selbst tun können. Die rohen Raumdaten werden dem System als Zope Cartographic Objects ZCO bekannt gemacht. Dazu muss ein Administrator sich browsergestützt in ZOPE am ZOPE Management Interface ZMI anmelden. Hier werden zunächst für die Rohdaten sogenannte ZCO data stores angelegt, die, als jeweils ein Layer, visualisiert werden können. Styles und Symbolizers bestimmen das Aussehen der eigentlichen Objekte später in der GIS-Karte. Detaillierte Filterregeln ermöglichen unterschiedliches, auch z.b. maßstabsabhängiges, Styling für ein- und dieselben Rohdaten in derselben oder verschiedenen Karten. Erst wenn data store und layer angelegt sind, können Plone-Nutzer auf die Daten zugreifen. Liegt kein Symbolizer für ein Objekt vor, wird ein default verwendet. Ein Administrator muss außerdem ein map renderer Kartenobjekt anlegen, bevor in Plone Karten erstellt werden können. Nutzer mit Schreibrecht können nun Karten erstellen, das Aussehen der Karte durch Veränderung der Projektion und Inhalte beeinflussen, indem sie Layer hinzufügen oder entfernen,
630 T. Steinmetz dabei können sie unter den vom Administrator angelegten Styles auswählen, um das Aussehen der Kartenobjekte zu beeinflussen. Daran schließt sich, wie oben bereits erwähnt, die Kartenanalyse an, bei der Nutzer kartographische Objekte auswählen und durch Mausklick an R zur gewählten Analyse übergeben. Das Ergebnis kann in Form neuer Shapes oder Rasterdaten über ZCO von einem Administrator zur Kartendarstellung zur Verfügung gestellt werden, oder, wenn es sich um Tabellen handelt, direkt im CMS angezeigt werden. Serverseitig ist die Erstellung von Berichten im PDF Format möglich, die freigegeben und dann von allen Nutzern heruntergeladen werden können. Abb. 4: PrimaGIS Benutzeroberfläche für einen angemeldeten Benutzer im Browserfenster. Im Kartenbild ist eine Lokalitäts- und Stoffkontextsensitive Volltext-Abfrage der Zope-internen Datenbank eingeblendet. Über Links sind auf diese Weise verwandte Elemente direkt zugänglich. Nutzer können eine Volltextrecherche in den im CMS erfassten Dokumenten durchführen und durch die vorgesehenen Kommunikationsmöglichkeiten mittels Weblog und Forum sowie der Bookmarksammlung ist eine effektive Zusammenarbeit auch in räumlich oder zeitlich separaten Zusammenhängen gewährleistet. Der auf dem Server installierte Mapserver ermöglicht es übrigens gleichzeitig mit der vorgestellten Lösung, außerhalb der Steuerung durch das CMS, dessen Fähigkeiten über herkömmliche Mapfiles und die php-cgi- Schnittstelle zu nutzen. Da der Mapserver in der Lage ist, WMS und auch WFS- Server zu
WebGIS-gestützte Kooperationsplattform zur Datenspeicherung und -Analyse 631 sein, können vorhandene Mapserver-Projekte als Web Services zur Verfügung gestellt werden und von PrimaGIS als Client genutzt werden. Auf diese Weise können vorhandene Daten genutzt werden und müssen nur als ZCO- WebService Layer bekannt gemacht werden. 5 Fazit Das vorgestellte System gibt Arbeitsgruppen ein effektives Mittel und gleichzeitig durch den vorgesehenen Workflow eine Methode zur Kommunikation und Zusammenarbeit mit räumlichen und nicht räumlich referenzierten Daten an die Hand. Große Menge Daten lassen sich schnell auffinden und per Karte, Tabelle, Bild oder Bericht anzeigen. Viele Teile des Systems sind in Produktionsumgebungen erprobte, stabile Open Source Software und ermöglichen daher die Anpassbarkeit auf spezielle Erfordernisse. Mit RStatServer steht ein Statistikwerkzeug zur Verfügung, das aufgrund seiner umfassenden Fähigkeiten und universellen Anpassbarkeit gerade auch als Lern- und Schulungsumgebung im universitären Feld Anwendung finden könnte. Die Möglichkeit (geo-)statistische Analytik als fertige Objekte als Webservices zur Verfügung zu stellen, erweitert deren Anwendbarkeit auf völlig neue Nutzerkreise. Die Kombination von GIS und geostatistischen Methoden auf der einen Seite (ANSELIN et. al. 2003, BIVAND 2005, ESRI Geostatistical Analyst), und GIS und Mapserver auf der anderen Seite ist nicht neu, stellt aber in ihrer beiderseitigen Verbindung mit einem Content Management System aufgrund der einfacheren Bedienung und dem alles umfassenden Zugriff im Rahmen der beschriebenen Workflow-Steuerung über die heutzutage verbreitete Umgebung im Webbrowser ein Novum dar. Sie bietet zum Beispiel in einem Gebiet wie dem Risiko Management im Umfeld einer großräumigen Grundwasserkontamination mit ihren vielen zu berücksichtigenden sozioökonomischen wie naturwissenschaftlichtechnischen Aspekten ein hervorragendes Mittel zur Beschleunigung der Beurteilung und Generierung von Entscheidungsalternativen im Prozess der Entscheidungsunterstützung. Literatur ANSELIN, L. KIM, YONG WOOK & SYABRI, I. (o. J.): Web-based Analytical Tools for the Exploration of Spatial Data. Webseite: http://sal.agecon.uiuc.edu/webtools/index.html BIVAND, R. (2005): Interfacing GRASS 6 and R. GRASS News, 11-28. ESRI Geostatistical Analyst (o. J.): Erweiterung für ArcMap. Web: www.esri.com GILLIES, S. (2004): Users Manual, Cartographic Objects for ZOPE, 1.0 LINDENBECK, C. (2004): UMN-MapServer: Integration in den Web-Applikationsserver ZOPE. Vortrag, AGIT 2004, Salzburg.
632 T. Steinmetz WYCISK, P., C. NEUMANN, G. FLECK, W. & GOSSEL (O. J.): M.L. Universität Halle: Ermittlung räumlicher Risikobereiche und Auswirkungen auf die Landnutzung als Grundlage einer maßnahmeorientierten Schadensvorsorge im Bereich Bitterfeld/Wolfen Risikobereiche und Landnutzung. In: GELLER, W., OCKENFELD, K., BÖHME, M., KNÖCHEL, A. (Hrsg.) (2004) Endbericht Schadstoffbelastung nach dem Elbe-Hochwasser 2002. BMBF-FKZ PTJ 0330492 WYCISK, P., GRATHWOHL, P., GOSSEL, W., NEUMANN, C., STEINMETZ, T. & KLEINEIDAM, S. (2005): Raumauswirkungen Beurteilung der Langzeitwirkung von verbleibenden Grundwasserbelastungen und ihre Auswirkungen auf die Schutzgüter und die Landnutzung im Raum Bitterfeld-Wolfen. SAFIRA II. Abschlussbericht des BMBF-Projektes, BMBF-FKZ: 02WT0412, 169 S. u. Anlagen. WYCISK, P., WEISS, H., KASCHL, A., HEIDRICH, S. & SOMMERWERK, K. (2003). Groundwater pollution and remediation options for multisource contaminated aquifers (Bitterfeld/Wolfen, Germany). Toxicology Letters, 140-141, 343-351. i ii iii iv v vi vii viii ix x xi www.zope.org. www.freebsd.org. plone.org. www.postgresql.org. www.postgis.org. www.primagis.fi. mapserver.gis.umn.edu, www.umn-mapserver.de. proj.maptools.org. www.gdal.org. www.r-project.org. http://research.warnes.net/projects/rstatserver.