Verwaltung von Zeitreihen in datenbank-basierten

FRIEDRICH-SCHILLER-UNIVERSITÄT JENA
Chemisch-Geowissenschaftliche Fakultät
Institut für Geographie
Verwaltung von Zeitreihen
in datenbank-basierten Informationssystemen
am Beispiel von RBIS
(River Basin Information System)
Diplomarbeit
eingereicht von Franziska Zander
geb. am 14. August 1982 in Karl-Marx-Stadt jetzt Chemnitz
Gutachter: Prof. Dr. Wolfgang-Albert Flügel
Dr. Sven Kralisch
November 2007
Danksagung
Ich möchte mich an dieser Stelle bei allen Personen herzlichen bedanken, die mich
während meiner Diplomarbeit unterstützt haben.
Insbesondere danke ich Dr. Sven Kralisch, der mein Interesse für das Datenbankumfeld
sowie die Anwendungsentwicklung weckte und förderte, diese Diplomarbeit fachlich
betreute und mir stets beratend zur Seite stand.
Bedanken möchte ich mich ebenfalls bei Prof. Dr. Wolfgang-Albert Flügel, an dessen
Lehrstuhl ich diese Arbeit verfassen durfte und allen Mitarbeitern des Lehrstuhls für
Geoinformatik, Geohydrologie und Modellierung für ihre Unterstützung.
Mein Dank gilt auch den Mitarbeitern des Lehrstuhls für Datenbanken und
Informationssysteme in Jena für die abwechslungsreiche Ausbildung in meinem
Nebenfach Informatik.
Bei Thomas Erb, Christian Fischer, Torsten Sauer und meinem lieben Freund Thomas
Meyer möchte ich mich für die vielen Denkanstöße und das Korrekturlesen bedanken.
Ebenfalls möchte ich meinen Eltern danken, die mir das Studium und damit auch diese
Diplomarbeit erst ermöglicht haben.
Inhaltsverzeichnis
Verzeichnisse
Abkürzungsverzeichnis
Abbildungsverzeichnis
III
III
IV
1 Einführung und Problemstellung
1
2 Grundlagen
4
2.1 Einordnung von RBIS
2.1.1 IWRM – Integrated Water Resources Management
2.1.2 AIDIS – Adaptive Integrated Data Information System
2.1.3 RBIS – River Basin Information System
2.2 Datenhaltung und -verwaltung
2.2.1 Informationssystem
2.2.2 Datenhaltung und Anwendung
2.2.3 Einsatz von Open-Source
2.3 Meta- und Zeitreiheninformationssysteme
2.3.1 Metadaten für räumliche Informationen
2.3.1.1 Metadatenstandards
2.3.1.2 Metadateneditoren
2.3.1.3 Metainformationssysteme für Geodaten
2.3.2 Verwaltung von raum-zeitlichen Informationen
2.3.2.1 Standards für Zeitreihen und Sensoren
2.3.2.2 Zeitreiheninformationssysteme
2.4 Zeitreihen und Datenlücken
2.4.1 Zeitreihenarten
2.4.2 Ursachen für Datenlücken in Zeitreihen
2.4.3 Umgang mit Datenlücken
2.4.4 Interpolationsverfahren
2.4.4.1 Zeitliche Interpolationsverfahren
2.4.4.2 Räumliche Interpolationsverfahren
3 Metadaten- und Zeitreihenverwaltung in RBIS
3.1 Datenbankschema
3.2 Grundlegende interne Funktionsweise
3.2.1 XML-Dokumente
3.2.2 Sicherheit
3.2.3 Datenintegrität
3.3 Funktionsumfang aus der Sicht der Anwender
3.4 Aktueller Datenbestand im RBIS-IMTIS
3.5 Anforderungen für zukünftige Erweiterungen
4 Verwaltung und Interpolation von Zeitreihen in RBIS
4.1 Problemstellung und Ausgangssituation
4
4
5
6
7
7
8
10
12
13
13
15
16
18
18
21
22
23
24
25
26
26
28
32
33
35
35
37
38
39
40
41
42
42
I
4.2 Metadaten über Zeitreihen
4.2.1 Anpassung des Datenmodells für die Verwaltung
4.2.2 Erweiterung des Import-Formulares
4.2.3 Überarbeitung der Upload-Funktion
4.2.3.1 Transaktionen
4.2.3.2 Qualitätsprüfung
4.2.3.3 Datenlückenanalyse
4.3 Bereitstellung verschiedener Datenanalysemöglichkeiten
4.3.1 Allgemeine Funktionsweise und Voraussetzungen
4.3.2 Anwendung durch RBIS-Nutzer
4.4 Implementierung und Anwendung verschiedener Interpolationsverfahren
4.4.1 Datenmodell und Datenhaltung
4.4.1.1 Datenmodell für die Metadaten
4.4.1.2 Speicherung der berechneten Werte
4.4.2 Interpolationsvorgang und technische Umsetzung
4.4.2.1 Berechnungsansatz
4.4.2.2 Umsetzung und Ablauf von Interpolationen
4.4.2.3 Implementierte Interpolationsverfahren
4.4.2.4 Prüfen und Korrigieren der interpolierten Messwerte
4.4.3 Anwendung durch RBIS-Nutzer
4.4.3.1 Verwendung interner Verfahren
4.4.3.2 Verwendung externer Verfahren
4.5 Export und Darstellung von Zeitreihendaten
4.5.1 Export
4.5.2 Darstellung
4.6 Einbindung der entwickelten Funktionen in RBIS
4.7 Aufgetretene Probleme
43
44
46
46
47
49
49
51
52
55
58
58
59
60
61
62
63
65
70
71
71
73
74
74
76
78
78
5 Zusammenfassung und Ausblick
80
Anhang A: Datenmodelle
82
DS_Station – konzeptionelles Modell
TS_TimeSeries – konzeptionelles Modell
82
83
Anhang B: XML-Schema von RBIS (rbis.xsd)
84
Anhang C: Auszüge aus dem Quellcode
87
create_query_linear_interpolation()
interpolation_set()
Literatur
87
88
92
II
Verzeichnisse
Abkürzungsverzeichnis
ACID
Atomicity, Consistency, Isolation, Durability
AIDIS
Adaptive Integrated Data Information System
CeGi
Center for Geoinformation GmbH
CEN
Comite Europeen de Normalisation
CSDGM
CSW
Content Standard for Digital Geospatial Metadata
Catalog-Service-Web
DBMS
Datenbank-Management-System
DBS
Datenbanksystem
DCMI
Dublin Core Metadata Initiative
FGDC
Federal Geographic Data Committee
FOSS
GDI-DE
Freie und Open-Source-Software
Geodateninfrastruktur - Deutschland
GeoMIS.Bund
Metainformationssystem für Geodaten des Bundes
GIS
Geoinformationssystem
GWP
Global Water Partnership
IDW
Inverse Distanzwichtung
ILMS
IMTIS
Integriertes Landschafts-Managementsystem
Integrated Metadata (and) Time series Information System
ISO
International Standards Organization Integrated
IWRM
Integrated Water Resources Management
JAMS
Jena Adaptable Modelling System
NOKIS
Nord-Ostsee-Küsten-Informations-System
O&M
OGC
Observation and Measurement
Open Geospatial Consortium
OWS
OGC Web Service
PortalU
Umweltportal Deutschland
RBIS
River Basin Information System
RDBMS
relationale Datenbank-Management-System
SensorML
SWE
Sensor Model Language
Sensor Web Enablement
TRIS
Tisza River Information System
UDK
Umweltdatenkatalog
III
Abbildungsverzeichnis
Abbildung 1: Aufbau von RBIS mit den Anwendungen Metadaten- und
Zeitreihenverwaltung und Kartenserver sowie den Datenbanken .........................................6
Abbildung 2: ISO 19115 Profil für bestimmte Nutzergruppen oder Länder „community
profile“ (Quelle: ISO 19115:2003).......................................................................................14
Abbildung 3: Grundelemente Observation und Event in O&M (Cox 2006:13)..................20
Abbildung 4: Kontinuierliche Zeitreihe mit Lücke..............................................................23
Abbildung 5: Intervall-Zeitreihe mit Lücken.......................................................................23
Abbildung 6: Momentan-Zeitreihe mit Lücke.....................................................................24
Abbildung 7: RBIS-IMTIS: Übersichtsansicht (Metadaten für Zeitreihen)........................32
Abbildung 8: Übersicht zur zentralen Rolle der Metadaten-ID (konzeptionelles Modell)..33
Abbildung 9: Bedeutung von XML-Dokumenten im RBIS-IMTIS....................................35
Abbildung 10: Übersicht XML-Schema von RBIS-IMTIS ................................................36
Abbildung 11: RBIS-IMTIS: Oberfläche zur Rechteverwaltung.........................................37
Abbildung 12: Erfassung aller Schreibenden Zugriffe in Logs...........................................39
Abbildung 13: tägliche Temperaturwerte (Minimalwert (value1), Durchschnittswert
(value2) und Maximalwert (value3)) ..................................................................................41
Abbildung 14: Tabelle „ts_timeser“ (physisches Datenmodell)..........................................49
Abbildung 15: Datenzuverlässigkeitsmodul (physisches Datenmodell)..............................50
Abbildung 16: Import-Formular für Zeitreihendaten...........................................................51
Abbildung 17: Transaktionen innerhalb eines Import (Upload)-Vorgangs.........................53
Abbildung 18: Lücken der Niederschlagszeitreihe Eich......................................................55
Abbildung 19: Beispiel SQL-Abfrage für das in Abbildung 22 dargestellte Suchergebnis 64
Abbildung 20: Benutzerschnittstelle mit Informationen über den Niederschlag an der
Station Frauensee und umliegende Stationen.......................................................................66
Abbildung 21: Darstellung der Lücken für zuvor ausgewählte Stationen...........................68
Abbildung 22: Abfrageergebnis für das Lückenintervall vom 1.2.1993 bis 31.3.1993 der
Zeitreihe „Niederschlag Frauensee“.....................................................................................69
Abbildung 23: Konzeptionelles Datenmodell: Interpolation und Interpolationsvorgang...71
Abbildung 24: Beispiel für Tabelle (calc_504) mit berechneten Werten ...........................74
Abbildung 25: Temporäre Tabelle (temp_113312812) mit dem Zeitstempel (timestamp),
den Mittelwerten der Werte (avg_val) und der Höhe (avg_elevat) und die Höhen (elevat_)
und Werte (value_) der Quellstationen................................................................................92
Abbildung 26: Übersicht der Grenzwerte für Messgrößen und Einheiten...........................94
Abbildung 27: Auswahl einer Zusammenstellung von Interpolationsverfahren..................95
Abbildung 28: Interpolationsregeln für IDW (5-3)..............................................................95
Abbildung 29: Informationen zu einem Interpolationsprozess............................................96
Abbildung 30: Importieren von extern gefüllten Datenlücken............................................97
Abbildung 31: Dateianfang einer exportierten Datei ..........................................................98
Abbildung 32: Übersichtsansicht für die Daten vom Metadatensatz „Niederschlag
Frauensee“..........................................................................................................................101
Abbildung 33: konzeptionelles Modell für DS_Station.....................................................106
Abbildung 34: konzeptionelles Modell für TS_TimeSeries...............................................107
Abbildung 35: XML-Schema von RBIS............................................................................110
Abbildung 36: Quellcode der Funktion: create_query_linear_interpolation()...................111
Abbildung 37: Quellcode der Funktion: interpolation_set()..............................................115
IV
1 Einführung und Problemstellung
1 Einführung und Problemstellung
In den letzten Jahrzehnten haben Naturkatastrophen, Ressourcenmangel und das gestiegene
Umweltbewusstsein des Menschen dazu geführt, dass die Erhebung von umweltbezogenen
Daten verstärkt in das öffentliche und wirtschaftliche Interesse gerückt ist. So werden zum
Beispiel möglichst viele und genaue Messwerte für die Erstellung zuverlässiger
Hochwasservorhersage- oder Klimaprognosemodelle benötigt um sowohl die Folgen für
den natürlichen Haushalt als auch für die Wirtschaft besser abschätzen zu können. In
Bezug auf die lebenswichtige Ressource Wasser können auf der Grundlage von Daten aus
verschiedenen Disziplinen, wie Fernerkundung, GIS-Analysen, Modellierungen und
sozioökonomischen Bewertungen sowie dem Fachwissen aus der Forschung, u. a.
Konzepte für ein Integriertes Wasserressourcen-Management (IWRM) (GWP 2000)
entwickelt und umgesetzt werden. Diese sollen den Umgang mit Wasser zu einem
möglichst großen sozialen und ökonomischen Nutzen fördern. Das IWRM erfordert eine
ganzheitliche Herangehensweise bei der Betrachtung des Wasserkreislaufes und seinen
Wechselwirkungen mit anderen Ressourcen des Ökosystems. Um all diese
Zusammenhänge, Prozesse und Interaktionen erfassen und beschreiben zu können sowie
darauf aufbauend grundlegende Informationen für Entscheidungsträger in Bezug auf ein
IWRM zu schaffen, müssen Daten nicht nur aus vielen verschiedenen Disziplinen
gesammelt, sondern auch integriert ausgewertet werden.
Erfolgte die Erhebung von Daten vor ein paar Jahrzehnten noch manuell, zeichnen heute
meist Datalogger über längere Zeiträume hinweg kontinuierlich erheblich größere Mengen
an Daten auf. Um dieser Datenflut gerecht zu werden, ist es notwendig, geeignete Systeme
und Anwendungen zu entwickeln, die diese verwalten können. Hierbei geht es nicht nur
um ein strukturiertes Abspeichern, sondern viel mehr um die Erhöhung der
Wiederauffindbarkeit und Nutzbarkeit dieser Daten. Zu diesem Zweck müssen zu den
Datensätzen Informationen erfasst werden, welche sie beschreiben. Diese Daten über
Daten (Metadaten) gewannen in den letzten Jahren immer mehr an Bedeutung und sind
heute auch im Bereich der Geowissenschaften ein fester Bestandteil der Aufgabe zur
Beschreibung großer Datenmengen. Um eine einheitliche Erfassung von Metadaten
voranzutreiben und somit den Austausch und eine effiziente Nutzung der Datenbestände zu
ermöglichen, wurden und werden Standards entwickelt. Im Bezug auf geografische
Informationen existiert der ISO-Standard 19115. Die Entwicklung eines Standards für die
Verwaltung von Sensoren und Zeitreihen ist in Vorbereitung, jedoch noch nicht
abgeschlossen. Nicht nur die Verwaltung von großen Datenmengen und Metadaten,
sondern auch der Austausch und die Präsentation von Ergebnissen sind Anforderungen, die
sich aus Forschungsprojekten im Bereich des Integrierten Wasserressourcen-Managements
ergeben. Um diesem gerecht zu werden, können Informationssysteme zum Einsatz
kommen.
1
1 Einführung und Problemstellung
Ein Informationssystem für die Verwaltung von Geodaten und (derzeitig vorrangig)
meteorologischer und hydrologischer Zeitreihen wurde am Lehrstuhl für Geoinformatik,
Geohydrologie und Modellierung des Instituts für Geographie der Universität Jena
entwickelt. Das River Basin Information System (RBIS) ist eine Web-Anwendung, die die
Möglichkeit bietet, Geodaten und Zeitreihen bzw. deren Metadaten über das Internet zu
verwalten, zu visualisieren und abzurufen. Im Datenbankmodell der Metadaten ist der
ISO 19115 Standard vollständig umgesetzt. Es enthält außerdem Ergänzungen für die
Verwaltung von Messstationen und Zeitreihen. Die Datenhaltung erfolgt hierbei im
Datenbank-Management-System PostgreSQL in mehreren Datenbanken.
Im Rahmen dieser Diplomarbeit wurde die Web-Anwendung im Bereich der Verwaltung,
Analyse und Abfrage von Zeitreihen erweitert und verbessert. Dazu gehören neben
Anpassungen des Datenbankschemas auch die Identifikation von in Zeitreihen vorhanden
Datenlücken des Datenbestandes. Außerdem sollte dem Anwender die Möglichkeit
geschaffen werden diese mit einem Interpolationsverfahren eigener Wahl zu schließen.
Die berechneten Werte sollten temporär oder permanent in der Datenbank für den Export
vorgehalten werden.
Folgende Ausgangssituation lieferte die Motivation für diese Aufgabenstellung. Daten für
die Verwendung in hydrologischen Modellen müssen stets lückenlos vorliegen. Dies ist
jedoch in der Praxis oft nicht der Fall. Die eingesetzte Software zur Simulation der
hydrologischen Modelle kann – muss aber nicht – die notwendigen Funktionalitäten
bereitstellen um Datenlücken zu schließen. Aus diesem Grund müssen Lücken häufig von
Hand geschlossen werden. Dabei wird die Herkunft der berechneten Werte gar nicht oder
nur unzureichend dokumentiert. Das kann dazu führen, dass die Daten unter falschen
Voraussetzungen in Berechnungen einbezogen werden. Das Ergebnis des Prozesses des
Schließens der Lücken ist abhängig vom jeweiligen Bearbeiter. Dieser Missstand sollte
beseitigt werden. Gleichzeitig sollte der Prozess zum Schließen von Lücken standardisiert
und durch die Dokumentation der angewendeten Verfahren die Transparenz dieses
Prozesses erhöht werden. Dies führt dazu, dass die Datenqualität besser bewertet werden
kann. Um nicht nur eine lückenlose Zeitreihe, sondern auch eine lückenlose
Dokumentation über Veränderungen der Daten zu erhalten, zählte nicht nur die Umsetzung
von Interpolationsverfahren zur Aufgabenstellung, sondern insbesondere auch die
Entwicklung eines Dokumentationsverfahrens, das es ermöglicht, alle Veränderungen am
Datenbestand zu erfassen.
Im theoretischen Teil der Aufgabenstellung sollten Grundlagen von RBIS, existierende
Standards zur Verwaltung von Metadaten und Zeitreihen sowie die existierenden
Interpolationsverfahren und deren Verwendung untersucht und beschrieben werden. Die
Basis für eine Erweiterung bildet das RBIS selbst. Die Aufgabenstellung sah vor, an die
bestehenden Funktionalitäten anzuknüpfen und eine geeignete Lösung für die
Implementierung und Umsetzung der Anforderungen zu finden. Zu diesem Zweck sollte
2
1 Einführung und Problemstellung
für den praktischen Teil der Aufgabe zunächst geklärt werden, welche zusätzlichen
Metadaten benötigt werden, um überhaupt in der Lage zu sein Informationen über
Datenlücken abzuspeichern. Ebenso mussten Informationen den Metadaten hinzugefügt
werden, die für die Suche nach Zeitreihendaten erforderlich sind. Darauf aufbauend
konnten Funktionen entwickelt werden, die Datenlücken identifizieren und zusätzliche
Metadaten automatisch erfassen. Als Teilaufgabe ergab sich daraus, dass der gesamte
Importvorgang grundlegend überarbeitet werden musste. Mit diesen zusätzlich erfassten
Informationen konnten verschiedene Möglichkeiten zur Datenanalyse unter verschiedenen
Gesichtspunkten geschaffen werden. Im Vordergrund stand dabei die Darstellung der
räumlichen Verteilung und Verfügbarkeit von Zeitreihen. Zum Schließen der Lücken, wie
in der Aufgabenstellung gefordert, waren verschiedene Interpolationsverfahren zu
implementieren. Als weitere Teilaufgabe konnte identifiziert werden, dass eine einfache
und flexible Lösungen für den Zugriff auf die Zeitreihendaten aus der Anwendung heraus,
für die Speicherung der Metadaten zu den verwendeten Interpolationsverfahren und der
Dokumentation dieser Verfahren gefunden werden musste. Da vorher ein Zugriff auf
Zeitreihen mit geschlossenen Lücken nicht vorgesehen war, mussten abschließend die
Verfahren zum Export der Daten überarbeitet und angepasst werden.
3
2 Grundlagen
2 Grundlagen
In diesem Kapitel wird ein Überblick über die Grundlagen im Bezug auf das RBIS sowie
den entwickelten Erweiterungen und Anpassungen gegeben. Hierbei wird zunächst auf die
fachlichen Konzepte und Ideen, auf denen RBIS beruht eingegangen. Anschließend folgen
die technischen Grundlagen in Bezug auf Datenhaltung und -verwaltung. Anhand von
RBIS werden die Vorteile einer zentralen Datenhaltung, sowie Vor- und Nachteile einer
Umsetzung als Web-Anwendung diskutiert. Auch der Einsatz von Open-Source-Software
wird behandelt. Abschnitt 2.3 beschäftigt sich allgemein mit Informationssystemen, die
den Fokus auf die Verwaltung von Metadaten und Zeitreihen unter der Berücksichtigung
von Standards richten, sowie mit konkreten Beispielen aus dem geowissenschaftlichen
Umfeld Deutschlands. Der folgende Abschnitt umfasst die Gründe für und den Umgang
mit Datenlücken in umweltbezogenen Zeitreihen, sowie eine Auswahl verschiedener
Interpolationsverfahren, die zum Schließen von Datenlücken verwendet werden können.
2.1
Einordnung von RBIS
Im Rahmen der am Lehrstuhl laufenden Forschungen für ein Integriertes
Wasserressourcen-Management (Integrated Water Resources Management, IWRM) wurde
das so genannte Adaptive Integrated Data Information System (AIDIS) für die
Informationsverwaltung entwickelt. AIDIS bildet mit seinem Datenbankmodell den
konzeptionellen Rahmen für das River Basin Information System (RBIS). RBIS selbst ist
eine konkrete Umsetzung von AIDIS und besteht aus einer Web-Anwendung sowie
einigen Datenbanken. Was unter IWRM, AIDIS und RBIS genau zu verstehen ist, soll im
Folgenden erläutert werden.
2.1.1
IWRM – Integrated Water Resources Management
IWRM wurde im Jahr 2000 vom Global Water Partnership (GWP), einem internationalen
Netzwerk, welches Ministerien, UN-Behörden, Entwicklungsbanken, Forschungsinstitutionen, NGOs und private Institutionen umfasst,wie folgt definiert:
IWRM ist ein Prozess zur ganzheitlichen Entwicklung und Bewirtschaftung von
Wasser-, Land- und damit zusammenhängenden Ressourcen, mit dem Ziel einer
Maximierung des sozialen und ökonomischen Nutzens unter fairen Bedingungen
und ohne die Nachhaltigkeit vitaler Ökosysteme zu gefährden (GWP 2000).
4
2 Grundlagen
Die Grundprinzipien von IWRM folgen im Grundsatz den vier Dublin-Prinzipien. Diese
wurden 1992 in Dublin auf einer internationalen Umweltkonferenz unter Beteiligung von
mehr als 100 Staaten verabschiedet und sollen zur Verbesserung der weltweiten Wasserversorgung beitragen:
1. Süßwasser ist eine begrenzte und gefährdete Ressource, die unentbehrlich für
das Leben, die Entwicklung und die Umwelt ist.
2. Wassererschließung und -management sollten auf einem partizipativen Ansatz
basieren, der Nutzer, Planer und politische Entscheidungsträger aller Ebenen
einbezieht.
3. Frauen spielen eine zentrale Rolle bei der Versorgung mit Wasser, seinem
Management und Schutz.
4. Wasser hat einen wirtschaftlichen Wert in allen seinen Nutzungsmöglichkeiten und sollte als wirtschaftliches Gut angesehen werden. (GWP
2000)
Die Konzepte von IWRM gelten mit den Dublin-Prinzipien (1992) und der Agenda 21
(1992) als wasserpoltischer Konsens auf internationaler Ebene und verankern ein Leitbild
zur nachhaltigen Entwicklung und dem Umgang mit der Resource Wasser. Die Agenda 21
selbst ist ein entwicklungs- und umweltpolitisches Aktionsprogramm für das 21.
Jahrhundert, das 1992 in Rio de Janeiro auf der „Konferenz für Umwelt und Entwicklung“
der Vereinten Nationen von 179 Staaten beschlossen wurde (AGRAR 2007).
2.1.2
AIDIS – Adaptive Integrated Data Information System
AIDIS (FLÜGEL 2006) wurde den Anforderungen eines IWRM folgend zur
Entscheidungsunterstützung am Lehrstuhl für Geoinformatik, Geohydrologie und
Modellierung der Universität Jena entwickelt. Grundlage bilden ein gutes
Datenmanagement und Strategien zur gemeinsamen Informationsnutzung. Dies beinhaltet
neben anderen Informationen die Sammlung und Verwaltung von Zeitreihen in Bezug auf
Wassermenge und -qualität, sozioökonomische Daten sowie digitale Karten, welche die
räumliche Verteilung dieser Informationen zeigen. Das objekt-relationale Datenmodell von
AIDIS, in dem der Metadatenstandard für geografische Informationen, ISO 19115 (ISO
19115:2003), vollständig umgesetzt wurde, lässt sich durch seine modulare Struktur leicht
an die Anforderungen regionaler, sowie internationaler Forschungsprogramme anpassen.
Eine der ersten erfolgreichen Umsetzungen einer internetbasierten Projektdatenbank
erfolgte im Rahmen des von der Europäischen Union finanzierten Tisza River Projektes
durch das Tisza River Information System (TRIS)(FLÜGEL ET AL. 2005). In einer
weiterentwickelten Version kommt es nun als River Basin Information System (RBIS) in
verschiedenen Forschungsprojekten zum Einsatz.
5
2 Grundlagen
2.1.3
RBIS – River Basin Information System
Das River Basin Information System (RBIS) wurde in den letzten Jahren am Lehrstuhl
entwickelt und geht aus den Entwicklungen für das TRIS hervor. Es wird zur Verwaltung
aller Informationen bzw. Daten über ein bestimmtes Flusseinzugsgebiet eingesetzt,
angefangen von Dokumenten über Zeitreihen bis hin zu GIS-Daten. Es setzt sich aus den
zwei eigenständigen Komponenten Metadaten- und Zeitreihenverwaltung, die in Kapitel 3
näher beschrieben wird, und dem Kartenserver zusammen. Beide können auch unabhängig
voneinander zum Einsatz kommen. Aus technischer Sicht werden die Informationen in drei
Datenbanken gespeichert. In einer Datenbank werden die Metadaten, in einer weiteren die
Zeitreihendaten und in einer dritten die GIS-Daten verwaltet (Abbildung 1).
Abbildung 1: Aufbau von RBIS mit den Anwendungen Metadaten- und
Zeitreihenverwaltung und Kartenserver sowie den Datenbanken
RBIS kommt in verschiedenen Forschungsprojekten zum Einsatz, wobei die Oberfläche,
die Datenbanken und die Anwendungen der jeweiligen Aufgabenstellung durch den
modularen Aufbau des Datenmodells leicht angepasst werden können. Beispiele hierfür
sind die Installationen für das Einzugsgebiet des Brahmaputra (BrahmaRBIS) und der
Donau (DanubeRBIS) im EU-Forschungsprojekt Brahmatwinn. In diesem Forschungsprojekt geht es um eine Erweiterung des Wissens für den harmonischen Umgang mit den
Wasserressourcen großer alpiner Flusssysteme, deren Quelleinzugsgebiete vom Klimawandel beeinflusst sind. Umzusetzen ist dies über einen multilateralen Wissenstransfer,
Erfahrungsaustausch, sowie die Entwicklung und Anpassung bestehender Flussgebietsmanagementwerkzeuge zwischen europäischen und asiatischen Partnern (FSU 2007b). Ein
weiteres Beispiel ist die Verwaltung der Daten aus dem Einzugsbereich der Saale
(SaaleRBIS), in welchem die Daten für das vom BMBF geförderte Forschungsprojekt für
ein Integriertes Landschafts-Managementsystem für Wasserwirtschaft, Kommunal- und
Regionalplanung (ILMS) verwaltet werden sollen (FSU 2007a).
6
2 Grundlagen
2.2
Datenhaltung und -verwaltung
Die Verwaltung der verschiedenen Daten eines IWRM Systems kann innerhalb eines
Informationssystems wie dem RBIS erfolgen. Hier werden Metadaten, Zeitreihendaten und
GIS-Daten verwaltet und den Projektpartnern und Entscheidungsträgern bereitgestellt.
Anhand der Umsetzung von RBIS und den gesammelten Erfahrungen soll auf
konzeptionelle Grundlagen der Datenhaltung und -verwaltung eingegangen werden. Dabei
wird zunächst der Begriff Informationssystem definiert bevor die Vor- und Nachteile einer
zentralen Datenhaltung diskutiert und Web- und Desktop-Anwendungen gegenüber gestellt
werden. Abschließend wird der Einsatzes von Open-Source allgemein und in Bezug auf
RBIS aufgegriffen und thematisiert.
2.2.1
Informationssystem
Informationssysteme (IS) allgemein bestehen aus:
„Menschen und Maschinen, die Informationen erzeugen und/oder benutzen und
die durch Kommunikationsbeziehungen miteinander verbunden sind“
(HANSEN & NEUMANN 2001:132).
Aus Sicht der Informatik ist ein Informationssystem
„ein (rechnergestütztes) System zur Beschaffung, Verarbeitung, Übertragung,
Speicherung und/oder Bereitstellung von Informationen“ (SCHWARZE 2000:46),
das aus „Hardware, Software, Daten und den Anwendungen besteht“ (BILL
1999:4).
Es gibt viele Ausprägungen von Informationssystemen. Eine Art der Untergliederung kann
nach dem Typ der bereitgestellten Informationen erfolgen. Dabei wird zwischen
betrieblichen,
analytischen,
raumbezogenen
oder
personenbezogenen
Informationssystemen unterschieden. Weitere Einordnungen sind z. B. nach der Art der
Anwendung (Auskunftssystem, Buchungssystem,...) oder nach ihrer fachlichen
Ausrichtung möglich. Ein Beispiel eines Fachinformationssystems ist ein GeoInformationssystem mit dem
„raumbezogene Daten digital erfasst und redigiert, gespeichert und
reorganisiert werden, modelliert und analysiert sowie alphanumerisch und
graphisch präsentiert werden“ (BILL 1999:4) können.
Für die Realisierung eines Informationssystems spielen Internet- und Datenbanktechnologien eine zentrale Rolle. In der Regel werden alle Operationen, welche die Daten
betreffen, von einem Datenbanksystem (DBS) übernommen. Ein DBS setzt sich aus einem
Datenbank-Management-System (DBMS) und einer Datenbank zusammen. Unter einem
DBMS wird hierbei „die Gesamtheit der Software-Module, die die Verwaltung einer
7
2 Grundlagen
Datenbank übernehmen“ (HEUER & SAAKE 2000:8) verstanden. Der Unterschied zwischen
einem DBS und einem Informationssystem besteht darin, dass in einem
Informationssystem meist unterschiedliche Datenbestände in einen größeren thematischen
Zusammenhang gebracht und die Metadaten (Daten über Daten) hier intensiv für die
Recherche in den Datenbeständen genutzt werden. Weiterhin werden anwendungsnahe
Auswertungsmethoden und Visualisierungsmöglichkeiten dem Nutzer zur Verfügung
gestellt (STREIT 1998).
Viele Informationssysteme werden durch den Einsatz von Internettechnologien für einen
breiten Nutzerkreis zugänglich gemacht. Ein Beispiel aus dem täglichen Leben sind die
Fahrgastinformationssysteme für Fahrgäste des öffentlichen Personennah- und
-fernverkehrs, die über das Internet oder andere Medien benutzt werden können. Sie
umfassen u. a. Liniennetzpläne, Fahrplanbücher und -karten, Verspätungs-, Anschluss- und
Tarifinformationen.
RBIS kann als ein raumbezogenes Informationssystem bezeichnet werden. In Bezug auf
die Verwaltung von Zeitreihen und räumlichen Daten besitzt es sowohl Eigenschaften
eines Meta- als auch eines Zeitreiheninformationssystems (siehe Abschnitt 2.3).
2.2.2
Datenhaltung und Anwendung
Grundlage für den Betrieb eines Informationssystems ist der Datenbestand selbst, der
immer so abgespeichert sein muss, dass über klar definierte Schnittstellen darauf
zugegriffen werden kann. Dies ist zum Beispiel bei der Datenhaltung über ein DBMS in
einer Datenbank der Fall, wobei sich hier die Daten selbst auch auf (räumlich) verteilten
Systemen befinden können. Unabhängig von der Art der Daten oder Verwendung in einem
Informationssystem sind mit einer zentralen Datenhaltung - im Vergleich zur dezentralen
Speicherung der Daten ohne eine gemeinsame übergeordnete Verwaltung - eine Reihe von
Vorteilen verbunden. So kann durch zentral durchgeführte und im Bedarfsfall auch zentral
eingespielte Backups eine hohe Datensicherheit erreicht werden. Darüber hinaus erfolgt
die Speicherung der Daten in einem einheitlichen Format und eine aufwendige
Konvertierung zwischen verschiedenen Datenformaten entfällt. Die Plausibilität der Daten
kann über Formulare mit Validierungsfunktionen bereits bei der Eingabe überprüft werden.
Beim Zugriff über das Intranet oder Internet können sensible Daten vor unberechtigtem
Zugriff über Firewalls, Zugriffskontrollen, Verschlüsselung usw. geschützt werden
(KLOSSEK 2004). In Bezug auf das RBIS bedeutet eine zentrale Datenhaltung die
Speicherung der Daten in einer Datenbank und nicht nur lokal auf dem Rechner der
zuständigen Mitarbeiter innerhalb eines Forschungsprojektes. Die Vorteile kommen
besonders dann zum tragen, wenn die Projektpartner räumlich sehr weit voneinander
entfernt sind und auf Informationen zugreifen müssen. Alle Projektpartner können sich
schnell einen Überblick über vorhandene Daten verschaffen und diese gegebenenfalls
herunterladen. Somit entfällt das Versenden der Daten per E-Mail oder CD. Auch ein
8
2 Grundlagen
Fortbestand der Informationen über die Projektlaufzeit hinaus oder die Nutzung in
Folgeprojekten wird durch eine zentrale Datenhaltung begünstigt.
Um die gesammelten Datenmengen den Nutzern zur Verfügung zu stellen, müssen
Anwendungen entwickelt werden. Diese können grundsätzlichen als Web- oder DesktopAnwendung konzipiert sein. Unter Web-Anwendungen fallen all jene Computerprogramme, bei der die Interaktion mit dem Benutzer ausschließlich über einen Webbrowser
erfolgt. Der Computer des Benutzers (Client) ist dabei über ein Netzwerk mit einem
Server verbunden. Ein solches Netzwerk kann das Internet oder ein Intranet sein. DesktopAnwendungen sind hingegen Programme die lokal auf einem Rechner installiert sind und
über eine eigene Benutzerschnittstelle verfügen. Das RBIS ist eine Web-Anwendung.
Die Verwendung einer Web-Anwendung hat zahlreiche Vorteile. Zu diesen zählt, dass
lediglich ein Webbrowser benötigt wird und keine weitere Installation von Software wie
bei Desktop-Anwendungen, benötigt wird. Damit wird ein hoher Grad an Plattformunabhängigkeit erreicht. Auch die Hardwareanforderungen an die einzelnen Arbeitsplätze
werden gering gehalten, da aufwendige Berechnungen vom Webserver ausgeführt werden.
Ein weiterer entscheidender Vorteil ist, dass bei Änderungen der Anwendungslogik die
Änderungen nur an einer Stelle ausgeführt werden müssen, sich dadurch der Wartungsaufwand minimiert und dementsprechend damit verbundene Kosten verringert werden
können. Weiterhin kann dadurch sichergestellt werden, dass alle Anwender zu einem
bestimmten Zeitpunkt immer mit der gleichen Programmversion arbeiten (KLOSSEK 2004).
Dies ist bei Anwendungen wie dem RBIS, die in der Praxis eingesetzt und permanent
weiterentwickelt werden, sehr vorteilhaft. Hier kann bei auftretenden Problemen und
Fehlern sofort wirksam reagiert werden. Für die Arbeit mit Zeitreihen kommt ein weiterer
bedeutender Aspekt hinzu. Werden Daten zentral über einen Webserver in eine Datenbank
eingefügt, gilt stets ein Datum bzw. eine Uhrzeit als Bezugspunkt und nicht die lokale Zeit
des Benutzers, der die Daten in das System einpflegt. Insbesondere falsch eingestellte
Rechneruhren könnten hier bei der Umrechnung in UNIX-Zeit und wieder zurück in ein
lesbares Datumsformat zu Problemen führen. Neben der Ortsunabhängigkeit der Benutzer
zählen auch die preiswerte Pflege und Entwicklung und die zentrale Datenhaltung und
-verwaltung zu den Vorteilen.
Web-Anwendungen besitzen gegenüber Desktop-Anwendungen mit einer lokalen
Datenhaltung auch Nachteile. Zu diesen zählt an erster Stelle die benötigte TCP/IP
Verbindung zwischen Client und Server. Somit wird bei einer Web-Anwendungen über
das Internet immer eine Internetanbindung mit ausreichend großer Bandbreite
vorausgesetzt, die die Anforderungen der Anwendung erfüllt. Dieses Kriterium stellt in
entwickelten Industrienationen kein großes Problem dar. In den vielen Ländern Afrikas
oder Asiens hingegen ist ein schneller Internetzugang keine Selbstverständlichkeit und
selbst bei einer bestehenden guten Internetanbindung werden unter Umständen die
Anforderungen der Web-Anwendung durch begrenzte Kapazitäten der interkontinentalen
9
2 Grundlagen
Verbindungen nicht erfüllt. Dies stellt derzeit den effizienten und uneingeschränkten
Einsatz von RBIS im Forschungsprojekt Brahmatwinn in Frage. Innerhalb der
europäischen Partner ist der Einsatz unproblematisch. Jedoch ist des Einfügen und
Auslesen größerer Datenmengen ab einer Dateigröße von 10 Mega Byte durch die
asiatischen Partner teilweise durch eine zu geringe Bandbreite nicht möglich. Generell
können sich durch eine TCP/IP Verbindung auch Sicherheitsprobleme ergeben, da es eine
Vielzahl verschiedener Angriffsmöglichkeiten im Zusammenhang mit Web-Anwendungen
gibt. Dies gilt jedoch auch für Desktop-Anwendungen. Ein weiterer Nachteil gegenüber
von Desktop-Anwendungen ist die Tatsache, dass alle Browser den Quellcode
unterschiedlich interpretieren und sich somit geringe Abweichungen in der Darstellung und
dem zur Verfügung stehenden Funktionsumfang ergeben können. Allgemein gehören zu
den Nachteilen noch der erhöhte Sicherheitsbedarf des Webservers, der bei der Verwaltung
vieler sensitiver Daten entsteht, die proportional steigende benötigte Rechenleistung pro
Nutzer sowie eine ansteigende Netzlast, die sich allerdings im Fall von RBIS durch die
insgesamt geringe Benutzeranzahl kaum bemerkbar machen wird.
Das Beispiel RBIS zeigt, dass hier die Vorteile einer Web-Anwendung überwiegen.
Nachteile, wie etwa eine unzureichende Internetanbindung, werden in Zukunft eine
untergeordnete Rolle spielen.
2.2.3
Einsatz von Open-Source
Im RBIS wird ausschließlich Freie und Open-Source-Software (FOSS) eingesetzt. Für den
generellen Einsatz von Open-Source-Lösungen sind verschiedene Gründe ausschlaggebend. Dazu gehören die im Vergleich zu kommerziellen Produkten geringeren Lizenzund Anschaffungskosten. Dieser Aspekt gewinnt vor allem in öffentlichen Einrichtungen
an Bedeutung, da hier die Finanzmittel in vielen Fällen gekürzt werden. Nach einer Studie
der EU (GHOSH 2006) sparen Unternehmen rund ein Drittel ihrer Investitionen mit der
Verwendung von Open-Source Produkten bei der Entwicklung eigener Software. Dadurch
werden andere Entwicklungen und Innovationen möglich oder die Profitabilität wird
gesteigert. Durch die Unabhängigkeit der eingesetzten Software von einzelnen Herstellern
wird die Investitionssicherheit in Projekten und in der zukünftigen Betriebsphase erhöht.
Bei der Auswahl der eingesetzten Software wird auf umgesetzte Standards sowie die
Erweiterbar- und Austauschbarkeit von Komponenten geachtet. Wie eine Studie (STOLL
2006) zeigt, findet etwa 40% der Entwicklung von Open-Source-Software durch bezahlte,
professionelle Entwickler in kommerziell tätigen Unternehmen statt. Somit ist davon auszugehen, dass die Qualität von FOSS der Qualität kommerzieller Software nicht unterlegen
sein muss. Im Gegenteil entsteht durch die Öffnung des Quellcodes für Anwender und
Experten ein höherer Anspruch an die Umsetzung und ein stärkeres Kontrollpotential,
welches in der Regel der Qualität des Produktes förderlich ist. Zudem konnte in der Studie
eine deutlich höhere Akzeptanz des Open-Source-Gedankens bei den betroffenen
10
2 Grundlagen
Entwicklern und in Folge dessen eine deutlich höhere Motivation bei der Arbeit an OpenSource-Projekten festgestellt werden, als bei der Arbeit an klassischer closed-Source
Software.
Im Umfeld der Datenbank-Management-Systeme gibt es fünf größere Open-Source
-Datenbankensysteme. Zu diesen zählen MySQL, PostgreSQL, Firebird, Ingres und
MaxDB (HORSTMANN 2006). Für die Anwendung in RBIS wird die Unterstützung von
geographischen bzw. raumbezogenen Datentypen für die Speicherung der GIS-Daten
benötigt, die zurzeit von den drei Produkten MySQL, PostgreSQL und Ingres zur
Verfügung gestellt werden.
Ingres von der Ingres Corporation ist die älteste der fünf genannten Open-SourceDatenbanksystemen. MySQL der schwedischen Firma MySQL AB wurde im Jahre 1995
veröffentlicht. Bekannte Nutzer sind Yahoo, SourceForge, NASA, Lycos, Wikipedia
(Wikimedia) und T- Systems. Mit der Version 5.0 gibt es viele Neuerungen. Es stehen elf
verschiedene Tabellentypen (Datenbanktreiber) zur Verfügung, mit denen unterschiedliche
Funktionen verknüpft sind. Die beiden wichtigsten Typen sind MyISAM und InnoDB
(HORSTMANN 2006). PostgreSQL ist ein objektrelationales Datenbanksystem. Anwendung
findet es zum Beispiel bei BASF und Fujitsu (HORSTMANN 2006). Die aktuelle Version ist
PostgreSQL 8.2. Die Verarbeitung von geografischen Objekten wird durch die
Erweiterung PostGIS realisiert. Sie versetzt damit PostgreSQL in die Lage als Datenserver
für ein Geoinformationssystem (GIS) zu dienen (RAMSEY 2007).
Die drei DBMS MySQL, PostgreSQL und Ingres unterscheiden sich in ihren Grundfunktionalitäten nur geringfügig. Vor allem die Unterschiede zwischen MySQL und
PostgreSQL sind gering. Galt MySQL als schneller aber mit einem geringeren Funktionsumfang und PostgreSQL als langsamer jedoch mit einem größeren Funktionsumfang, so
haben beide ihren Rückstand zum einen durch neue Funktionen mit MySQL 5.0 und zum
anderen durch wesentlichen Performace-Gewinne bei PostgreSQL aufgeholt (HORSTMANN
2006).
Im RBIS kommt PostgreSQL mit PostGIS als DBMS zum Einsatz. Die Wahl wurde
anhand der verfügbaren Funktionen für die Verarbeitung von räumlichen Objekten der
verschiedenen Open-Source-Datenbanksystem getroffen. Hier war der zur Verfügung
stehende Umfang bei PostgreSQL / PostGIS im Vergleich zu MySQL höher. Inzwischen
wurde MySQL um eine eigene GIS-Lösung erweitert. Daher können heute beide Lösungen
als gleichwertig betrachtet werden. Dieser Entwicklung wurde in der Art vorausschauend
Rechnung getragen, als bei der Umsetzung darauf geachtet wurde, so weit wie möglich auf
die Verwendung proprietärer Funktionen des DBMS zu verzichten und das Datenmodell
unabhängig vom eingesetzten DBMS zu modellieren. Insgesamt wurde RBIS für das
Betriebssystem Linux, dem Apache-Webserver, dem DBMS PostgreSQL und PHP (LAPP
stack) realisiert, wobei ausschließlich Open-Source-Produkte eingesetzt werden.
11
2 Grundlagen
2.3
Meta- und Zeitreiheninformationssysteme
Ganz allgemein werden Geoinformationen (raumbezogene Informationen), die durch Geodaten repräsentiert werden, dazu verwendet, um Menschen bei Entscheidungsprozessen zu
unterstützen. Da nicht jedes Unternehmen seine eigenen Geodaten produzieren kann und
dies auch eine Verschwendung von Ressourcen darstellen würde, werden Informationen,
welche die Daten selbst beschreiben (Metainformationen) benötigt. Sie ermöglichen die
Verwendung außerhalb des Entstehungskontextes und dienen zum einen dazu die
Geodaten so zu beschreiben, dass sie sachgemäß eingesetzt werden können. Zum anderen
ermöglichen sie, dass Datensuchende diese finden, ohne von ihrer Existenz zu wissen. Der
Zugriff auf die in einem Geodatenkatalog enthaltenen Geodaten erfolgt über verschiedene
Dienste. Dies gilt ebenfalls für raum-zeitliche Informationen (gemessene oder simulierte
Werte). Ein komplexes Netzwerk in dem der Austausch von Geodaten zwischen GeodatenProduzenten, Dienstleistern sowie Geodatennutzern unterstützt wird, wird als Geodateninfrastruktur bezeichnet. Dabei erfolgt der Datenaustausch meist über das Internet.
Die Erfassung, Speicherung und Präsentation von Metainformationen ist die Aufgabe eines
Metainformationssystems. Für die Suche und den Austausch von Metadaten aus verschiedenen Quellen ist es notwendig, bestimmte Normen und Standards einzuführen. Die
Normierung und Standardisierung für Geoinformationen erfolgt durch die International
Standards Organization (ISO) (Normen) und das Open Geospatial Consortium (OGC)
(Standards) (MÜLLER ET AL. 2005:126f). Für Metadaten raumbezogener Informationen gibt
es
bereits
einige
Metadatenstandards.
Für
zeitliche
Informationen
im
geowissenschaftlichen Umfeld, die immer einen räumlichen Bezug aufweisen, gibt es noch
keine Standards. Aufgrund dieses räumlichen Bezugs von Zeitreihendaten und ihren
Metadaten können diese nicht ganz unabhängig von den bestehenden Metadatenstandards
für Geoinformationen betrachtet werden. Die Metadaten raum-zeitlicher Informationen
werden daher zum Teil in Erweiterungen zu bestehenden Metadatenstandards in
Metainformationssystemen verwaltet. Informationssysteme, die sich auf die Speicherung,
Analyse und Bereitstellung von Zeitreihendaten konzentrieren, können als Zeitreiheninformationssysteme bezeichnet werden. Diese besitzen häufig eine GIS-Erweiterung, um
der räumlichen Verortung der Daten Rechnung zu tragen.
Im Folgenden sollen die bestehen Metadatenstandards, verschiedene Metadateneditoren,
die für die Erstellung der Metadaten verwendet werden können, und einige Beispiele für
Metainformationssysteme, die in Deutschland im Einsatz sind, vorgestellt werden. Der
Abschnitt über die Standards für raum-zeitliche Informationen gibt einen kleinen Einblick
in aktuelle Standardisierungsvorhaben des OGC und Parallelen oder mögliche
Schnittpunkte mit dem Datenmodell von RBIS. Es gibt auch einen Überblick über
ausgewählte Zeitreiheninformationssysteme, vorrangig aus dem deutschsprachigen Raum,
mit einer hydrologischen Ausrichtung.
12
2 Grundlagen
2.3.1
Metadaten für räumliche Informationen
Metadaten für räumliche bzw. geografische Informationen spielen eine wichtige Rolle bei
der Veröffentlichung, der Weitergabe und dem Vertrieb von Geodaten. Sie sollten
möglichst immer die Fragen nach dem Was (Titel und Beschreibung), Wann (Datum der
Erstellung und Änderung), Wer (Ersteller und Vertreiber der Daten), Wo (räumliche
Ausdehnung und Ort) und dem Wie (Verfügbarkeit der Daten) beantworten können. Als
internationaler Standard für die Beschreibung von geografischen Informationen gilt der
ISO-Standard ISO 19115. Neben diesem weltweit gültigen Standard existieren auch noch
weitere Metadatenstandards. Für die Verarbeitung und Speicherung von Metadaten gibt es
mehrere verschiedene Metadateneditoren, die unterschiedliche Standards unterstützten.
Eine Auswahl wird im Folgenden benannt. Die Suche nach, aber auch die Verwaltung von
Geodaten kann über so genannte Metainformationssysteme für geografische Informationen
erfolgen. Exemplarisch werden hier fünf dieser Informationssysteme, die ein Teil der
Geodateninfrastruktur in Deutschland sind, vorgestellt.
2.3.1.1
Metadatenstandards
Für Geodaten gibt es mehrere Dokumentationsstandards. Der wichtigste Standard für
Metadaten im Geoinformationswesen ist ISO 19115. Neben diesem gibt es auf
verschiedenen Ebenen eine Vielzahl weiterer Metadatenstandards. Dazu gehört zum einen
der Dublin Core Standard, der allgemein zur Beschreibung von Dokumenten und anderen
Objekten im Internet dient. Zum anderen wird der in den USA vom Federal Geographic
Data Committee (FGDC) entwickelte Content Standard for Digital Geospatial Metadata
(CSDGM) dazu gezählt. Ein Beispiel für einen fachlichen Standard in Deutschland ist der
Umweltdatenkatalog (UDK), der Metadaten zum Nachweis umweltrelevanter
Datenbestände in den öffentlichen Verwaltungen enthält. Die Anzahl der zu
dokumentierenden Attribute reicht von 15 bis weit über 300 (MÜLLER ET. AL 2005:130).
FGDC-CSDGM
Der Content Standard for Digital Geospatial Metadata (CSDGM) oder kurz auch FGDCStandard wurde erstmals 1994 vom 1990 gegründeten Federal Geographic Data Comitee
(FGDC) veröffentlicht. Er ist seit 1998 verbindlicher Standard für die Dokumentation
raumbezogener Daten für Behörden in den USA. Der FGDC-Standard besteht, ähnlich
ISO 19115, aus verschiedenen Metadaten-Kategorien, die untereinander in Verbindung
stehen und alle von der Oberkategorie Metadata ausgehen. Für die meisten ISO-Elemente
gibt es eine Entsprechung im CSDGM (FDGC 1998, FDGC 2007a).
13
2 Grundlagen
Dublin-Core Standard
Der Dublin-Core Standard wurde von der Dublin Core Metadata Initiative (DCMI) 1995
ursprünglich für das Bibliothekswesen entwickelt. Er wurde unter der Bezeichnung ISO
15836:2003 Information and documentation - The Dublin Core metadata element set 2003
als internationale Norm veröffentlicht. Diese Norm bietet einfache Elemente zur
Beschreibung von Ressourcen im Internet. Dublin-Core Metadaten können z. B. im Header
von HTML-Dateien als Meta-Element angeben werden. Sie sind alle optional und können
beliebig oft und in beliebiger Reihenfolge verwendet werden (HILLMAN 2005). Dublin-Core
wird zum Beispiel als Minimalsatz an Metadaten in der OGC Catalogue Services
Specification 2.0 verwendet, die eine offene Standardschnittstelle zum Auffinden,
Durchsuchen und Aufrufen von beliebig, verteilt vorliegenden Georessourcen beschreibt
(CON TERRA 2004).
ISO 19115
ISO 19115 Geographic information – Metadata ist eine internationale Metadaten-Norm,
welche die Struktur für die Beschreibung von Geodaten vorgibt. Die Arbeiten unter diesem
Namen (früher ISO 15046) begannen 1996 und endeten 2003, als das Dokument durch die
ISO zum internationalen Standard wurde. Eine der Grundlagen bildete zum Beispiel der
FDGC-Metadatenstandard von 1994. Aus diesem Grund sind diese auch recht ähnlich,
jedoch nicht gleich, da sie sich auseinander entwickelten. Weiterhin flossen unter anderem
die Ergebnisse des technischen Komitees 287 des Comite Europeen de Normalisation
(CEN) ein. Dieses entwickelte in den Jahren 1997 und 1998 eine europäische MetadatenNorm (ENV 12657:1998 - Geographic Information - Data description – Metadata). Die
Arbeiten wurden eingestellt, und die ISO-Norm wurde unter dem Namen
EN ISO 19115:2005 als CEN-Norm übernommen (CEN 2007, ISO/TC 211 2007, FDGC
2007b).
Abbildung 2: ISO 19115 Profil für bestimmte Nutzergruppen oder
Länder „community profile“ (Quelle: ISO 19115:2003)
14
2 Grundlagen
ISO 19115:2003 beinhaltet 409 Metadatenelemente, die in Metadatenentitäten gruppiert
sind. Diese wiederum sind nach ihrem Zweck zu 15 Hauptmetadatenpaketen zugeordnet.
Ausgangspunkt bildet dabei die Klasse Metadata entity set information. Es gibt 22 so
genannte core metadata elements (components), welche einen Minimalsatz an Elementen
bilden, den nach ISO 19115:2003 jede Umsetzung beinhalten sollte (Abbildung 2). Sie
sollen sicherstellen, dass die Fragen über das Was, Wo, Wann und Wer eines Datensatzes
immer beantwortet werden können. Die restlichen Metadatenelemente können optional
umgesetzt werden. Durch die Vorgabe von Codelisten wird die Anzahl der Felder, die mit
freiem Text belegt werden können, reduziert, was eine einheitliche Interpretation zwischen
verschiedenen Metadateninformationssystemen ermöglicht. Weiterhin ist es erlaubt eigene
Erweiterungen einzubinden oder zu erstellen (siehe extended metadata in Abbildung 2).
Damit wird eine wesentliche Voraussetzung für die Integration bzw. nachträgliche
Anpassung an die ISO-Norm geschaffen (ISO 19115:2003).
2.3.1.2
Metadateneditoren
Mit der zunehmenden Bedeutung von Metadaten für die Bereitstellung von Geodaten im
Internet und bei der Vernetzung von Informationssystemen wurden neben Standards auch
eine Reihe von Metadateneditoren entwickelt. Zum gegenwärtigen Zeitpunkt unterstützen
fast alle aktuellen Anwendungen ISO 19115. Zu den Desktop-Anwendungen zählt der
kommerzielle ArcCatalog und die ArcView Metadata Extension von der Firma ESRI, die
den FGDC-Standard und ISO 19115 abdecken. Ein weiteres kommerzielles Produkt ist
Infopath von Microsoft. Zu den kommerziellen Web- und Desktop-Anwendungen, die
ISO 19115 unterstützen, zählen z. B. Authentic (Bestandteil von XMLSpy), PubliStar,
Geometa-Editor (Teil der Geo-Metadata Network Suite), sdi.suite terraCatalog und
GeoKey. Die Produkte CatMDE, disy Preludio und GeoNetwork sind hingegen als
Freeware verfügbar (GISPUNKT 2007, BEHRENDS ET AL. 2006).
Ein Problem liegt in der Breite der potenziellen Anwendungsmöglichkeiten der
Programme. Oft ist diese Software nur für einen bestimmten Anwendungszweck geeignet.
Daher ist die Integration in die Prozesse eines Unternehmens bzw. eines
Forschgungsprojektes oft mit einem höheren Anpassungsaufwand verbunden, als für die
Einarbeitung, Schulung und Programmierung aufgebracht werden müsste. Der Trend geht
dahin, dass Editoren an spezielle Dienstleistungen oder Komponenten größerer
Softwarelösungen gebunden sind. Auch die Kopplung an Onlinedienste und Webangebote
scheint nach BEHRENDS ET AL. (2006:45f) aufgrund der Komplexität der Sachverhalte eine
praktikable Lösung zu sein.
15
2 Grundlagen
2.3.1.3
Metainformationssysteme für Geodaten
Metainformationssysteme für Geodaten dienen der Erfassung, Verwaltung und Recherche
von Geodaten, Geodiensten und Geoanwendungen. Sie sind als Suchmaschine nach
KAZAKOS (2006) ein wichtiger Bestandteil einer Geodateninfrastruktur und bilden die
Grundlage zur Mehrfachnutzung von Geodaten in den öffentlichen Verwaltungen sowie
die Basis für die Vermarktung von Geodaten. Allgemein können Kosten gespart werden,
wenn die Daten in Folgeprojekten wiederverwendet und nicht neu erhoben werden müssen.
Auch kann die Qualität von schlecht dokumentierten Daten z. B. bei einem Mitarbeiterwechsel möglicherweise nicht mehr beurteilt werden. In besonders schwerwiegenden
Fällen können Kosten entstehen, weil Entscheidungen auf der Grundlage von fehlerhaften
Daten getroffen werden. Das Ziel beim Einsatz eines Metainformationssystems für
Geodaten ist daher, Auskunft über Art, Verfügbarkeit und Qualität der Geodaten zu geben.
In Deutschland wird die Schaffung einer Geodateninfrastruktur (GDI-DE) seit 2003
verstärkt vorangetrieben und gefördert. Beispiele aus Deutschland sind das nationale
GeoMIS.Bund (BKG 2007), das PortalU (KRUSE 2007), der CeGi GEOcatalog (CEGI
2007), das NOKIS (KAZAKOS 2006) und der Umweltdatenkatalog (UDK) (KRUSE 2007).
GeoMIS.Bund
GeoMIS.Bund ist das Metainformationssystem für Geodaten des Bundes. Es ist im
GeoPortal.Bund als Geodatensuchmaschine integriert und beruht auf dem ISO-Standard
ISO 19115. Es war der erste Schritt zur Schaffung der nationalen Geodateninfrastruktur
GDI-DE. GeoMIS.Bund ermöglicht die Suche in verteilten Geokatalogen. Ziel ist es, alle
Fachinformationssysteme der Bundesbehörden daran anzuschließen, sowie die Länder und
die Privatwirtschaft einzubeziehen. GeoMIS ist als Dienst für Behörden, Wirtschaft und
die breite Öffentlichkeit verfügbar (BKG 2007).
Aus technischer Sicht kommuniziert das GeoMIS über einen oder mehrere Web Catalog
Services (CSW) mit den angeschlossenen Metadatenbanken. Es gibt zwei Varianten, zu
welchem Zeitpunkt die Abfrage zwischen GeoMIS und CSW erfolgt. Das GeoMIS des
Bundes erfragt alle angeschlossenen Kataloge zum Zeitpunkt der Kundenanfrage und
erhält damit immer die aktuellsten Metadaten. Das zukünftige GeoMIS der GDI
Berlin/Brandenburg wird im Vorfeld die Metadaten aller angeschlossenen Stellen in das
eigene relationale Datenbankmanagementsystem (RDBMS) integrieren. Dies führt zu einer
höheren Verfügbarkeit, birgt aber auch die Gefahr von Mehrfacheinträgen durch
Rekursionen von verketten Katalogdiensten (WIKIPEDIA 2007).
PortalU
Das PortalU (Umweltportal Deutschland) ist ein gemeinsames Internetportal des Bundes
und der Länder. Es bietet über einen zentralen Zugang Zugriff auf die Internetseiten,
Datenkataloge und Datenbankeinträge von öffentlichen Institutionen und Organisationen
16
2 Grundlagen
des Bundes und der Länder. Es können gezielt aktuelle Umweltnachrichten und
-messwerte, detaillierte Informationen zu verschiedenen Umweltthemen, Hinweise auf
Veranstaltungen und neue Publikationen, sowie Informationen über historische
Umweltereignisse abgerufen werden. Über PortalU kann auch auf die Daten des UDK
zugegriffen werden. Die Koordinierungsstelle PortalU ist beim Niedersächsischen
Umweltministerium in Hannover angesiedelt (KRUSE 2007).
CeGi GEOcatalog
Der CeGi GEOcatalog ist ein webbasiertes Metadateninformationssystem, das auf
internationalen Standards des OGC und ISO (19115, 19119) basiert. Hierbei handelt es
sich um ein Gemeinschaftsprodukt der Center for Geoinformation GmbH (CeGi) und der
ConTerra GmbH. Mit seiner Hilfe kann über verteilte registrierte Kataloge und getrennt
nach Geodaten oder Geodiensten gesucht werden (CEGI 2007).
NOKIS
Das Nord-Ostsee-Küsten-Informations-System (NOKIS) ist ein Informationssystem für die
Nord- und Ostseeküste, über das Geodaten aber auch Zeitreihen und Forschungsprojekte
zu deutschen Küstengebieten recherchiert werden können. Es ist eine der größten
Metadatenquellen von GeoMIS.Bund. NOKIS unterstützt nicht nur den ISO 19115
Standard, sondern auch standardkonforme Erweiterungen wie küstenspezifische Elemente
(z. B. Informationen über Gezeiten). Aufbauend auf den Technologien von disy Preludio,
bildet NOKIS inzwischen einen wichtigen Baustein für die Metadaten-Infrastruktur der
meisten Institutionen an der deutschen Küste. Über die OGC Catalog-Service-WebSchnittstelle (CSW) wird ein verteilter Zugriff realisiert. Ebenso können Daten auch mit
dem Umweltdatenkatalog (UDK) ausgetauscht werden (KAZAKOS 2006).
UDK
Das Grundkonzept sowie die Anwendungssoftware des Umweltdatenkataloges (UDK)
wurden im Zeitraum von 1991 bis 1995 im Niedersächsischen Umweltministerium
entwickelt. Die weitere Entwicklung und Einführung der Software beruhte auf der am
1.1.1996 in Kraft getretenen Verwaltungsvereinbarung UDK (seit 1.1.2003:
Verwaltungsvereinbarung UDK/GEIN). Der UDK enthält Metainformationen über die in
den Umweltverwaltungen der Bundesländer und des Bundes vorhandenen
umweltrelevanten Datenbestände und dient der Beschreibung von Umweltdaten bzw. der
Auffindung umweltrelevanter Datenquellen im Internet. In Deutschland setzen heute das
Umweltbundesamt und das Bundesamt für Naturschutz sowie alle Bundesländer mit
Ausnahme von Berlin den UDK als Metainformationssystem ein (KRUSE 2007).
17
2 Grundlagen
2.3.2
Verwaltung von raum-zeitlichen Informationen
Für die Verwaltung von raum-zeitlichen Informationen, wie beispielsweise
Abflusszeitreihen eines Pegels oder Temperaturzeitreihen einer Klimastation, gibt es noch
keine Standards, wie sie etwa für räumliche Daten zur Verfügung stehen. Welchen Stand
der Standardisierungsprozess hat und welche Parallelen zu dem Datenmodell von RBIS
gezogen werden können, wird nachfolgend behandelt. Im Anschluss werden verschiedene
Zeitreiheninformationssysteme, die als eine weitere Art von Informationssystemen
angesehen werden können, vorgestellt. Sie verfolgen im Vergleich zu den
Metainformationssystemen ein anderes Ziel, da sie sich mehr auf die Daten selbst und ihrer
Verarbeitung und weniger auf ihre Metadaten konzentrieren, wenngleich auch hier
Metadaten, wie etwa die Position der Messstelle, unerlässlich sind.
2.3.2.1
Standards für Zeitreihen und Sensoren
Konzentrierte sich die Entwicklung von Anwendungen und Standards zunächst auf
räumliche Informationen, so rückten in den letzten Jahren Anwendungen und
Informationssysteme, die Daten mit einem raum-zeitlichen Bezug verwalten, in den
Vordergrund. Auch die Entwicklung von Standards wurde von verschiedenen Stellen
vorangetrieben. So wurde infolge der Ereignisse des 11. September 2001 in New York die
OGC Web Service (OWS)-Initiative gegründet, die u. a. zum Ziel hat, Standards für die
Verwaltung von verschiedenen Sensoren und deren Daten über das Internet zu entwickeln,
um im Katastrophenfall besser agieren zu können. Das Open Geospatial Consortium
(OGC), früher Open GIS Consortium, wurde 1994 gegründet und ist ein internationales,
nicht gewinnorientiertes und freiwilliges Industriekonsortium mit derzeit 349 Mitgliedern
aus Industrie, Behörden, öffentlicher Verwaltung und Universitäten. Ziel dieses
Konsortiums ist es, Grundlagen für einheitliche und interoperable Zugriffsmethoden auf
raumbezogene Informationen zu entwickeln (OGC 2007c). Im Rahmen der OGC Web
Service Testbeds (OWS) 1 und 1.2 des OGC wurde u. a. die Sensor Web Enablement
Initiative (SWE) für die interoperable Steuerung und Abfrage von Sensoren gegründet
(OGC 2007a). Im Rahmen der SWE-Initiative wurden OGC Spezifikationen für eine Reihe
von Diensten und dazugehöriger Beschreibungssprachen erarbeitet, die neben der Abfrage
durch Sensoren erfasster raum- und zeitrelevanter Messdaten auch die interoperable
webbasierte Steuerung von Messvorrichtungen vorsehen. Mit der Sensor Model Language
(SensorML) werden alle Arten von Sensoren unterstützt, die sich ruhend oder in
Bewegung befinden können, angefangen bei Pegelmessstationen über Webcams bis hin zu
satellitengestützten Sensoren. Mit der Verwaltung von Messwerten befasst sich
Observation and Measurement (O&M) (WYTZISK & SIMONIS 2005:235ff).
18
2 Grundlagen
Eine Übersicht der verschiedenen Teilprojekte von SWE und deren Status innerhalb des
OGC ist in Tabelle 1 zusammengetragen. Einige dieser Dokumente besitzen schon den
Status eines offiziellen OGC Standards, andere befinden sich auf dem Weg dahin und sind
daher noch möglichen Änderungen unterlegen.
Tabelle 1: Übersicht der Teilprojekte des OGC Sensor Web Enablement (SWE)
Name
Inhalt
Status (OGC)
Sensor Observation
Service (SOS)
Bereitstellung von Messergebnissen
(standardisierte, webbasierte Schnittstelle für Zugriff
auf Sensoren und Sensordatenarchive)
13.02.2006
(Draft OpenGIS®
Implementation
Specification)
Observations &
Measurements (O&M)
Modellierung und Codierung von Messergebnissen
(Modell zur Abbildung räumlich und zeitlich varianter
Größen; XML basiertes encoding)
21.09.2006
(Draft OpenGIS® Best
Pratices Document)
Sensor Model Language Beschreibung der Sensoren
17.07.2007
(SensorML)
(Beschreibungssprache zur eindeutigen Referenzierung (OpenGIS®
und Definition von Sensoren)
Implementation
Specification )
Transducer Markup
Language (TML)
Charakterisierung der Sensoren
(Modellierung und Codierung für Datenströme von
Sensoren; Beschreibung von System und Daten
encoding)
02.07.2007
(OpenGIS®
Implementation
Specification )
Sensor Alert Service
(SAS)
Alarmmeldungen der Sensoren
(Anzeigen, Abonnieren und Veröffentlichen von
Warnungen)
13.05.2006
(Candidate OpenGIS®
Implementation
Specification
Sensor Planning Service Planung von Messexperimenten
(SPS)
(standardisierte Schnittstelle zur Informationsbeschaffung für Mess- und Simulationsaufgaben)
01.12.2005
(Request for
Comments OpenGIS®
Best Pratices
Document)
Web Notification
Service (WNS)
18.11.2006
(Draft OpenGIS® Best
Pratices Document)
Benutzerbenachrichtigung
(Schnittstelle zur Kapselung von Funktionen für
Benachrichtigung von Nutzern und Diensten)
(Quellen: OGC 2007b, WYTZISK & SIMONIS 2005:235ff, Stand: 27.07.2007)
Im Teilprojekt O&M wird ein konzeptionelles Modell, sowie auch eine Kodierung für
Beobachtungen und Messungen entwickelt. Die Grundelemente sind in Abbildung 3
dargestellt. In der aktuellen Version steht die Observation, als ein spezielles Event mit
einem Wert, der ein Phänomen beschreibt, im Mittelpunkt. Ein Event wird durch eine Zeit
oder ein Zeitintervall und optional durch eine semantische Beschreibung des Wertes
definiert. Jedem Event können Qualitätsmerkmale zugeordnet werden. Für jede
Observation ist eine Organisation oder Person (CI_ResponsiblePerson – ISO 19115)
zuständig. Jeder Observation muss zugeordnet sein, was für ein Phenomenon (z. B.
Abfluss) beobachtet wurde. Über die Zuordnung von Procedure wird beschrieben, wie der
19
2 Grundlagen
Wert zustande gekommen ist. Alle Observations können ein bestimmtes Ziel oder Objekt
der Beobachtung haben (feature of interest). Hierzu zählen Flüsse, Straßen, Personen,
Fahrzeuge, Gebäude, Berge, Aquifere genauso wie einzelne Proben, Stationen,
Geländemessungen oder Bildausschnitte. Die räumliche Referenzierung geschieht
entweder über die Beschreibung des Vorgangs (procedure), oder über das Ziel oder Objekt
der Beobachtung (feature of interest). Die Beschreibungen der einzelnen Sensoren, mit
denen die Werte erfasst werden, gehören nicht zu O&M und werden von anderen
Teilprojekten in SWE abgedeckt (COX 2006).
Abbildung 3: Grundelemente Observation und Event in O&M (COX 2006:13)
Das aktuell frei verfügbare Entwurf mit dem Stand vom 21.09.2006 enthält eine offizielle
Position des OGC, wurde jedoch noch nicht endgültig als OGC Standard anerkannt und
unterliegt daher noch Veränderungen. Aus diesem Grund wurden bei der Erweiterung des
Datenmodells des RBIS für die Verwaltung von Zeitreihen und Stationen diese Entwürfe
nicht verwendet (ZANDER 2006). Eine Anpassung des Datenmodells von RBIS könnte sich
als problematisch erweisen, da der OGC Standard mehr von einzelnen Messwerten (COX
2006) als von ganzen Zeitreihen ausgeht, wenngleich auch hier die Möglichkeit besteht
mehrere Messwerte zusammenzufassen. Im aktuelle RBIS-Datenmodell wird immer von
ganzen Zeitreihen beliebiger Länge ausgegangen. Die Metadaten der Zeitreihen im RBIS
verweisen ebenfalls auf Responsible Parties aus ISO 19115. Auch die Angaben von
Beginn und Ende einer Zeitreihe sieht O&M vor. Genaue Aussagen über die Verwaltung
der Datenqualität gibt es in O&M noch nicht. COX (2006) schlägt in diesem
Zusammenhang eine Verknüpfung mit bestehenden Data Quality Elementen in ISO
Standards vor. Im RBIS wird hierfür eine eigene Erweiterung verwendet.
20
2 Grundlagen
2.3.2.2
Zeitreiheninformationssysteme
Die Verwaltung von Zeitreihen, u. a. für die hydrologische Modellierung, kann unter
Verwendung so genannter Zeitreiheninformationssysteme erfolgen. Diese können als eine
mögliche Spezialisierung eines Fachinformationssystems gesehen werden. Die
Zeitreihenverwaltung, sowohl von gemessenen, als auch simulierten Messwerten in einem
Informationssystem, stellt im weitesten Sinne das Gegenstück zu einem geographischen
Informationssystem mit seinen flächenbezogenen Daten dar. Ein klassisches Beispiel sind
Pegelinformationssysteme, über die auf aktuelle oder vergangene Messwerte zugegriffen
werden kann. Ein Beispiel hierfür ist das gewässerkundliche Informationssystem der
Wasser- und Schifffahrtsverwaltung des Bundes (Pegelonline), das interessierten Bürgern
Zugriff auf den tagesaktuellen Wasserstand ausgewählter Binnenpegel der Wasserstraßen
des Bundes gewährt. Mitarbeitern und autorisierten Personen steht ein noch größeres
Informationsangebot zur Verfügung (WSV 2007). In den hydrologisch geprägten
Ingenieurswissenschaften spielt die Verwaltung von Zeitreihen eine große Rolle. Im
deutschsprachigen Raum gibt es mehrere Unternehmen, die Zeitreiheninformationssysteme
mit hydrologischer Ausrichtung selbst oder innerhalb von Forschungsprojekten entwickelt
haben. Darunter zählt die Ingenieurgesellschaft aqua_plan, die unter dem Namen AquaZIS
ihre bisherigen Produkte AquaRell, AquaCoup und AquaLog (wasserwirtschaftliche
Informationssysteme im Sachgebiet Niederschlag, Pegelwesen und Grundwasser ) vereint
(AQUAPLAN 2007). Eine andere Ingenieurgesellschaft (SYDRO) entwickelte die Anwendung
WELLE zur Erfassung, Verwaltung, Visualisierung und Analyse von Zeitreihen (SYDRO
2007). Die Gesellschaft für Logistik & Gewässermanagement (Gelog mbH) vertreibt das
Programmsystem HydroZIS, welches für die Erfassung, Speicherung, Verwaltung,
Prüfung, Pflege, Visualisierung und Auswertung hydrologischer Zeitreihen ausgelegt ist
(GELOG 2006). Beim Bundesamt für Wasserbau ist WISKI (ein Produkt der Firma
Kisters) im Einsatz. WISKI ist ein umfangreiches wasserwirtschaftliches Informationssystem mit zahlreichen Komponenten und Modulen für spezielle wasserwirtschaftliche
Anwendungsgebiete (KISTERS AG 2007). Über WISKI werden auch die Daten für
Pegelonline bereitgestellt. Über NOKIS wiederum können die Metadaten der Pegel von
Pegelonline abgefragt werden.
Alle genannten Zeitreiheninformationssysteme sind mit einem GIS verknüpft und
ermöglichen auch eine räumliche Darstellung und Auswahl der Messstationen. Dies
verdeutlicht noch einmal die enge Verzahnung zwischen den verschiedenen Ausprägungen
von Fachinformationssystemen im geowissenschaftlichen Umfeld.
RBIS selbst ist zum Teil ein Metainformationssystem mit einem geringeren
Funktionsumfang (es werden keine Dienste angeboten) gegenüber den oben beschriebenen
Produkten. Zusätzlich erfüllt es die Aufgaben eines Zeitreiheninformationssystems. An
dieser Stellte sollte lediglich aufgezeigt werden, welche zwei generell voneinander
unterscheidbaren Informationssysteme mit ähnlichen Aufgabenstellungen wie RBIS vor
dem Hintergrund möglicher Standards existieren.
21
2 Grundlagen
2.4
Zeitreihen und Datenlücken
Umweltbezogene Zeitreihen weisen recht häufig aus verschiedenen Gründen Lücken auf.
Diese müssen aufgefüllt werden, wenn auf diesen Zeitreihen statistische Analysen
durchgeführt werden oder sie zum Beispiel in hydrologischen Modellen als Ausgangsdaten
verwendet werden sollen. In der Literatur gibt es viele Arbeiten, die sich mit den
verschiedenen Methoden zum Füllen fehlender Messwerte in umweltbezogenen Zeitreihen
befassen. Die Klasse von Verfahren und Problemen aus der numerischen Mathematik, bei
der zu gegebenen diskreten Daten eine kontinuierliche Funktion gefunden werden soll,
wird als Interpolation bezeichnet. Viele Methoden, die bei der Übertragung von
Punktdaten in die Fläche (Regionalisierung) angewendet werden, können auch zum
Schließen einzelner Datenlücken verwendet werden. Ferner gibt es noch andere
Einsatzmöglichkeiten dieser Verfahren, wie die Prüfung der Daten auf ihre Plausibilität.
Ein Beispiel wird von YOU ET AL. (2004) beschrieben. Hierbei werden die Ergebnisse
zweier räumlicher Interpolationsverfahren miteinander verglichen, um mögliche Fehler in
maximalen und minimalen Temperaturwerten zu finden.
Im Folgenden wird zunächst definiert, was Zeitreihen sind und wie sie sich untergliedern
lassen, bevor auf die Ursachen von Datenlücken eingegangen wird und allgemeine
Verfahrensweisen zum Auffüllen von Lücken beschrieben werden. Diese sind nicht nur auf
umweltbezogene Daten anwendbar, sondern auch auf Zeitreihendaten allgemein.
Anschließend wird auf die einzelnen Interpolationsverfahren eingegangen, die zum
Schließen von Datenlücken verwendet werden können. An dieser Stelle soll nur eine
Auswahl mit möglichen Anwendungsbereichen und Varianten sowie Beispielen oder
Empfehlungen von Autoren für die Anwendung betrachtet werden. Der Schwerpunkt liegt
hierbei auf den Interpolationsverfahren, die in der RBIS-Erweiterung realisiert wurden.
Eine allgemeine Definition von Zeitreihen gibt HERZOG (2005):
„Zeitreihen sind ganz allgemein Sammlungen von Messwerten, die zu bestimmten
Zeitpunkten aufgenommen wurden.“
Eine Zeitreihe setzt immer voraus, dass die Daten nicht kontinuierlich, sondern in diskreten
bzw. endlichen Abständen vorliegen. Zeitreihen können, wie zum Beispiel bei der
kontinuierlichen Aufzeichnung von Pegelständen, durch Abtastung der Messreihe zu
bestimmten Zeitpunkten erzeugt werden. In Zeitreihen können die Zeitpunkte äquidistant,
d. h. mit festem Zeitabstand, oder in unregelmäßigen zeitlichen Abständen vorliegen, wenn
zum Beispiel nur die Veränderung eines Messwertes registriert wird. Zeitreihen gibt es in
vielen Bereichen, wie etwa in der Form von Börsenkursen in der Finanzmathematik, der
Arbeitslosenquote in der Ökonomie oder von Abflussdaten in der Hydrologie. Die
Disziplin, die sich mit der mathematisch-statistischen Analyse und der Vorhersage von
Zeitreihen beschäftigt, ist die Zeitreihenanalyse (HERZOG 2005).
22
2 Grundlagen
2.4.1
Zeitreihenarten
Generell lassen sich drei Zeitreihenarten unterscheiden, nämlich kontinuierliche, Intervallund Momentan-Zeitreihen, die sich auch in der Definition von Datenlücken unterscheiden.
Kontinuierliche Zeitreihen
Hydrologische Parameter werden häufig mit Schreibstreifen oder Dataloggern
kontinuierlich aufgezeichnet. Auch wenn Datalogger dabei meistens in einem festen
Zeitintervall oder bei einer festen Änderung des Messwertes aufzeichnen, werden diese
Daten kontinuierlich interpretiert. Der Graph besitzt jedoch keine geschlossene
Darstellung, da die Anzahl der Stützstellen begrenzt ist. Hier wird meist zwischen zwei
Stützstellen linear interpoliert. Ein Beispiel sind Messungen an einem Abflusspegel. Liegt
zu einem bestimmten Zeitpunkt kein Wert vor, so ist dies eine Lücke (Abbildung 4).
(AQUAPLAN 2002:15ff).
Abbildung 4: Kontinuierliche Zeitreihe mit Lücke
Intervall-Zeitreihen
Bei einer Intervall-Zeitreihe liegen die Werte für ein bestimmtes Zeitintervall vor. Diese
Zeitintervalle können, müssen aber nicht, äquidistant sein. Ein Beispiel für eine
äquidistante Intervall-Zeitreihe sind Niederschlagstagessummen, die jeweils einen
Zeitraum von 24 Stunden repräsentieren. Nicht äquidistante Intervall-Zeitreihen entstehen,
wenn zum Beispiel nur wochentags die Daten eines Niederschlagsmessers abgelesen
werden. Am Montag enthält dieser dann die Niederschlagsmenge seit der letzten Ablesung
am Freitag. Lücken in einer äquidistanten Intervall-Zeitreihe können ein oder mehrere
Intervalle umfassen (Abbildung 5)(AQUAPLAN 2002:15ff).
Abbildung 5: Intervall-Zeitreihe mit Lücken
23
2 Grundlagen
Momentan-Zeitreihen
Momentan-Zeitreihen sind nur für eine diskrete Zeitpunkt definiert. Zwischen diesen
Zeitpunkten ist nichts bekannt. Eine Interpolation zwischen diesen Werten ist nicht
sinnvoll, weil hier keine aussagekräftigen Daten ermittelt werden können. Ein Beispiel für
eine solche Reihe sind alle lokalen Maxima einer Niederschlagszeitreihe. Als MomentanZeitreihen können auch Zeitreihen betrachtet werden, die Aufgrund ihres großen
Zeitintervalls die zugrunde liegende Dynamik nicht widerspiegeln, wie etwa die Messung
der Temperatur aller 3 Monate. Ein weiteres Beispiel sind 14tägig gemessene
Gewässergüteparameter. Lücken in Momentan-Zeitreihen sind nur Zeitpunkte, die einen
undefinierten Wert liefern (Abbildung 6)(AQUAPLAN 2002:15ff).
Abbildung 6: Momentan-Zeitreihe mit Lücke
2.4.2
Ursachen für Datenlücken in Zeitreihen
Die Gründe für fehlerhafte oder fehlende Messwerte sind breit gefächert und reichen von
routinemäßigen Wartungen über systematische Messfehler bis hin zu ungeplanten
Totalausfällen. Generell können eine temporäre Schließung, Umsetzung, ein Neubau oder
Zerstörung von Teilen oder der gesamten Station Datenlücken in den Zeitreihen
verursachen. Auch einfache bauliche Veränderungen können die Zuverlässigkeit der
Messwerte beeinträchtigen. Eine weitere Quelle für Datenlücken ist in den Sensoren selbst
zu suchen. Sind die Messinstrumente einer hohen Beanspruchung durch
Starkniederschläge, Hochwasser, Frost (Eisbildung), Trockenheit und Hitze ausgesetzt,
liefern diese keine oder fehlerhafte Werte. Auch Alterung, Verschmutzung, Schwankungen
in der Stromversorgung oder in dem Verhalten elektronischer Geräte können für den
Ausfall von Messstationen verantwortlich sein. Eine ungenaue Kalibrierung der
Messgeräte kann ebenfalls zu Fehlern innerhalb der Zeitreihe führen. Das Fehlen von
Messwerten kann auch durch das Über- oder Unterschreitung der Messgrenzen des
Messinstrumentes erklärt werden, wie zum Beispiel bei einer automatische
Pegelmessstation, die bei Hochwasser per Hand abgelesen werden muss. Neben all den
technischen Gründen kommen auch andere Ursache für unzuverlässige Daten in Frage.
Hierzu gehört der Wechsel des Beobachters, eine Zeitänderung der Beobachtung oder bei
einer Klimastation das Baumwachstum in unmittelbarer Umgebung, die Veränderung des
24
2 Grundlagen
Wasserangebotes oder der Vegetation in unmittelbarer Nähe der Messstation (vgl. ALLEN ET
AL. 1998). Auch die Tatsache, dass die Daten noch nicht digitalisiert verfügbar sind, kann
ein Grund für Datenlücken sein. Die Folge von systematischen Messfehlern sind
Inhomogenitäten in den Zeitreihen, die durch verschiedene Homogenitäts- und
Plausibilitätstests erkannt und durch spezielle Verfahren ausgebessert oder als Fehlwert
markiert werden können.
Auch politische oder gesellschaftliche Ereignisse können zu größeren Lücken innerhalb
von Zeitreihen führen. Ein Beispiel hierfür sind fehlende Messungen aus Deutschland
während der beiden Weltkriege.
2.4.3
Umgang mit Datenlücken
Treten in Zeitreihen Lücken oder Fehlwerte auf, gibt es verschiedene Möglichkeiten, damit
umzugehen. Es kann zunächst versucht werden die fehlenden Werte durch manuelle
Recherche in alternativen Quellen als den Originaldaten, wie etwa Jahrbücher oder anderen
Arbeiten zu finden. Auch kann es bei Klimastationen vorkommen, dass an ein und
derselben Station die Daten in unterschiedlichen Zeitabständen oder Messgeräten vorliegen
und durch Überlagerung dieser eine Lücke geschlossen werden kann (RAPP 2001:1). So
lagen zum Beispiel 2002 noch an 90% der Pegel in Baden-Württemberg
Wasserstandsganglinien sowohl von einem analogen als auch einem digitalen
Aufzeichnungsgerät vor (LUBW 2002).
Häufig wird ein bestimmter Grenzprozentsatz an fehlenden Werten festgelegt, bevor
Verfahren zur Berechnung der Wertelücken angewendet werden (HINTERDING 2003:59).
Alle Zeitreihen bei denen der Prozentsatz der fehlenden Werte über diesem liegt, werden
aus dem Datenbestand entfernt. Von FAMILI ET AL. 1997 wird ein solcher Richtwert, ab dem
eine Zeitreihe entfernt werden sollte, mit 20% angeben. Das Entfernen ganzer Zeitreihen
aus einem Datenbestand zählt zu den ältesten Methoden. Dabei muss jedoch zum einen
bedacht werden, dass Informationen, die durch keine anderen Zeitreihe abgedeckt werden,
verloren gehen und zum anderen, dass bei der Entnahme zu vieler Datensätze aus einem
Datenbestand eine weitergehende Datenanalyse nicht mehr möglich ist (WRIGHT 1998:2f).
Für das Schließen von Datenlücken gibt es eine Vielzahl von verschiedenen Verfahren, die
entweder auf der Grundlage der jeweiligen Zeitreihe oder auf anderen Datensätzen im
Datenbestand basieren. Die meisten Standardverfahren zum Auffüllen von Fehlwerten
werden in verbreiteten Softwarepaketen angeboten (HINTERDING 2003:59). Speziell auf
Geostatistik ausgerichtete Programme sind zum Beispiel GSTAT (PEBESMA 2006), GSLIB
(DEUTSCH & JOURNEL 1998), Geo-EAS (ENGLUND & SPARKS 1991) und SAGA GIS (OLAYA
2004). Viele Zeitreiheninformationssysteme oder hydrologische Modelle, wie WaSiMETH (JASPER & SCHULLA 2007) oder PREVAH (WINMET)(ZAPPA & VIVIROLI 2005), stellen
ebenfalls Interpolationsverfahren zur Verfügung.
25
2 Grundlagen
2.4.4
Interpolationsverfahren
Für das Auffüllen von fehlenden Werten zwischen bekannten Datenpunkten existieren
Methoden auf der Grundlage der jeweiligen Zeitreihe (zeitliche Interpolation) sowie unter
Benutzung benachbarter Referenzstationen (räumliche Interpolation). Bei der zeitlichen
Interpolation wird nur die Zeitreihe betrachtet, in der die Datenlücke auftritt. Die
Interpolation erfolgt unter Verwendung der vorhandenen Messwerte mit Verfahren wie der
linearen Interpolation. Bei der räumlichen Interpolation gehen die Messwerte umliegender
Stationen in die Berechnung ein. Dabei werden die räumliche Mittelwertbildung, lineare
oder multiple Regressionsbeziehungen oder entfernungs- und richtungsabhängige
Interpolation zur Berechnung der Werte verwendet (RAPP 2001:1f).
Neben der Unterteilung in zeitliche und räumliche Interpolationsverfahren kann auch
zwischen lokalen und globalen Verfahren unterschieden werden. Bei lokalen Methoden
wird nur eine Teilmenge aller vorhanden Datensätze, die in einem bestimmten Suchgebiet
oder in der Nachbarschaft liegen, zur Berechnung verwendet. Die globalen Methoden
benutzen hingegen alle Datensätze, die zur Verfügung stehen (KLINKENBERG 1997).
Eine weitere Möglichkeit ist die Einteilung in deterministische und stochastische
Interpolationsverfahren. Zu den deterministischen Verfahren gehören u. a. NächsterNachbar-Verfahren, Inverse Distanzwichtung und die Spline Interpolation. Sie basieren auf
exakt vorherbestimmbaren räumlichen Zusammenhängen. In stochastische Verfahren
hingegen gehen Zufallselemente in die Berechnung mit ein. Die Interpolation wird als eine
von vielen möglichen Realisationen einer Verteilungsfunktion gesehen, welche die
beobachteten Messwerte erzeugt. Zu den bekanntesten stochastischen Verfahren gehört das
geostatistische Verfahren Kriging (LORUP & FISLER 2006, KLINKENBERG 1997).
2.4.4.1
Zeitliche Interpolationsverfahren
Zu den zeitlichen Interpolationsverfahren, die nur die Zeitreihe mit der Datenlücke
betrachten, gehören lineare Interpolation, Splines und weitere Verfahren. Zeitliche
Interpolationsverfahren sollten nur auf Zeitreihen ausgeführt werden, die kontinuierlich
sind (z. B.: Temperatur, Abfluss) und nicht einzelne unabhängige Ereignisse beschreiben,
wie das zum Beispiel beim Niederschlag der Fall ist. Sie besitzen den Vorteil, dass keine
Informationen über umliegende Stationen benötigt werden und eignen sich vor allem für
kleine Datenlücken. Werden die Lücken jedoch zu groß können keine zuverlässigen Daten
ermittelt werden, weil die Dynamik nicht mehr richtig erfasst werden kann.
26
2 Grundlagen
Lineare Interpolation
Die lineare Interpolation geht auf Isaac Newton zurück und ist ein sehr einfaches
Verfahren, bei dem zwei gegebene Datenpunkte linear verbunden werden. Beim Füllen
von Lücken innerhalb einer Zeitreihe werden hierfür der Anfangs- und Endpunkt einer
Lücke verwendet und diese durch eine Gerade verbunden. Die fehlenden Messwerte liegen
direkt auf dieser Geraden.
Kleine Datenlücken (etwa in Abflusszeitreihen in Zeiten einer geringen Abflussdynamik)
können problemlos mit diesem Verfahren gefüllt werden (LUBW 2002:16). Die lineare
Interpolation eignet sich aber auch zum Schließen kleiner Lücken bei Klimaelementen wie
Temperatur oder Luftfeuchte.
Splines
Splines sind Funktionen n-ten Grades, die stückweise aus Polynomen mit dem maximalen
Grad n zusammengesetzt sind. Je nachdem, was für n gewählt wird, ist der Spline linear,
quadratisch, kubisch usw.. Splines werden häufig zur Interpolation und Approximation
verwendet, da sie durch die stückweise Interpolation flexibler als Polynome sind. Das
Verfahren liefert sehr schnell Werte, da immer nur wenige Datenpunkte in eine
Berechnung eingehen.
Splines werden nicht nur zur zeitlichen, sondern auch zur räumlichen Interpolation zur
Erstellung von Oberflächen mit einer minimaler Krümmung eingesetzt (BURROUGH &
MCDONNELL 1998). Zeitliche Spline-Interpolationen hingegen werden z. B. zum Schließen
von Lücken in Wasserstandsdaten verwendet (LUBW 2002:16).
Weitere Verfahren
Weitere Möglichkeiten, eine Datenlücke mit den gegeben Informationen der Zeitreihe zu
füllen, sind das Einsetzen des Mittelwertes des Gesamt- oder eines Teilintervalls, des
Ordinatenwertes einer Trendgeraden durch die Zeitreihe zum Zeitpunkt der Datenlücke
oder die Rekonstruktion per Hand (RAPP 2001:2). Auch die Verwendung des zuletzt
gemessenen Wertes für die Lücke ist möglich. Eine andere Variante zum Bereinigen
größerer meteorologischer Datenausfälle besteht in dem so genannten „Einpassen in die
Datenlücke“. Hierfür wird aus der Spenderzeitreihe (kann auch dieselbe wie die
Empfänger-Datenreihe sein) die erforderliche Datenfolge herauskopiert und durch
vertikales Verschieben und horizontales Drehen so in die Empfänger-Datenreihe
eingepasst, dass die Berührungspunkte jeweils stufenlos ineinander übergehen (LUBW
2002:19).
27
2 Grundlagen
2.4.4.2
Räumliche Interpolationsverfahren
Räumliche Interpolationsverfahren bieten die Möglichkeit, auf Basis von punktuell
gemessenen Daten Aussagen über ihre flächenhafte Verteilung zu treffen. Es kann an
jedem beliebigen Punkt ein Wert geschätzt werden, dementsprechend können damit auch
Lücken in Zeitreihen unter Verwendung der vorhandenen umliegenden Werte geschlossen
werden. Das am häufigsten eingesetzte Verfahren zum Schließen von Datenlücken in
umweltbezogenen Zeitreihen ist die inverse Distanzwichtung. Weiterhin gibt es noch das
Nächste-Nachbar-Verfahren sowie die lineare Regression, mit der auch Lücken gefüllt
werden können. Ein weiteres, sehr bekanntest Verfahren ist zum Beispiel das globale
Interpolationsverfahren Kriging, dass es in vielen Varianten gibt. Da Kriging nicht als
Interpolationsverfahren im RBIS umgesetzt wurde, soll es hier auch nicht näher
beschrieben werden
Nächste-Nachbarn-Verfahren
Das Nächste-Nachbarn-Verfahren ist ein sehr weit verbreitetes und sehr einfaches
Verfahren. Dabei wird im Datenbestand der Datensatz gesucht, welcher bei der jeweils
verwendeten Metrik den Quelldaten am ähnlichsten bzw. bei dem der Abstand am
geringsten ist. Lücken werden dann mit der Übernahme der Attributwerte des benachbarten
Datensatzes geschlossen. Das Verfahren kann durch die Verwendung des Mittelwertes der
nächsten Nachbarn als Schätzung verbessert werden (lokale Mittelwertbildung)
(HINTERDING 2003:59). Das Verfahren ist dann problematisch, wenn keine ähnlichen
Datensätze im Datenbestand vorhanden sind oder eine hohe topografische Variabilität
vorliegt, da die aufgefüllten Lücken eine andere Charakteristik als die des Quelldatensatzes
aufweist (WRIGHT 1998:2f).
Als Maß für die Ähnlichkeit bzw. zur Bestimmung der Entfernung gibt es verschiedene
Parameter. Die Verwendung der euklidischen Distanz zur nächsten Station ist eine
Möglichkeit und wird oft in GIS-Anwendungen für das Auffüllen fehlender Werte
verwendet. Ferner kann auch der Korrelationskoeffizient verwendet werden.
Nach KNIESS & SCHERZER (2003) sollte bei der Übernahme von Daten benachbarten
Klimastationen eine optimale Korrelation zwischen Quell- und Zielstation vorliegen. Als
optimal wird dabei ein Korrelationskoeffizient von 0,9 und höher angesehen. Zahlreiche
Hinweise für die direkte Übernahme von Globalstrahlungsdaten von benachbarten
Stationen werden bei ALLEN ET AL. (1998) gegeben. Fehlende Wasserstandsdaten können
mit Daten einer Vergleichsmessstelle gefüllt werden, wenn der Pegel am selben Gewässer,
im gleichen Einzugsgebiet oder in unmittelbarer Nähe liegt und er ähnliche Gebiets- und
Niederschlagscharakteristika besitzt. Weisen die Daten der Vergleichsmessstelle einen
zeitlichen Versatz oder eine konstante Differenz auf, so müssen die Daten noch
entsprechend angepasst werden (LUBW 2002:18).
28
2 Grundlagen
IDW – Inverse Distanzwichtung
Die Inverse Distanzwichtung (IDW) ist ein nichtstatistisches Verfahren, das zur einfachen
Interpolation von räumlich abhängigen und georeferenzierten Daten genutzt wird. Dabei
wird davon ausgegangen, dass die Ähnlichkeit zu einem unbekannten Messwert mit der
Entfernung von diesem abnimmt. Dieser Zusammenhang wird durch die Verwendung des
inversen Abstandes (1/d) zwischen Schätzpunkt und Messort als Gewicht (wi) für jeden
Messwert zum Ausdruck gebracht (1).
n
wi =
1
d p (1)
xw =
∑ (x ⋅ w )
i
i =1
i
n
∑w
i =1
i
(2)
Somit nimmt mit größer werdender Entfernung der Einfluss des Messwertes auf den
Schätzwert ab. Diese Gewichtsabnahme kann durch einen festgelegten Exponenten (p)
gesteuert werden. Je höher der Exponent ist, desto mehr wird der Schätzwert dem Wert des
nächstgelegenen Messortes ähnlich. Im Regelfall wird ein Exponent von 2 verwendet. Die
Summe aller normalisierten Gewichte beträgt 1. Der Schätzwert berechnet sich aus der
Summe aller beitragenden gewichteten Messwerte (2) (SCHULLA 1997:19f, LORUP & FISLER
2006).
Die Interpolation mit der inversen Distanzwichtung hat den Vorteil, dass sie in ihrer
Berechnung sehr schnell ist, die unterschiedliche Distanz in die Schätzung einbezieht und
der Einfluss der Distanzgewichtung durch den Exponenten gesteuert werden kann. Zu den
Nachteilen zählt vor allem, dass keine richtungsabhängige Gewichtung möglich ist und
somit räumlich gerichtete Zusammenhänge wie etwa Höhenpunkte entlang eines
Bergrückens nicht in die Berechnung einfließen (LORUP & FISLER 2006). Voraussetzung für
eine erfolgreiche Anwendung ist immer ein ausreichend dichtes Messnetz. Existieren nur
sehr wenige Stationen in unmittelbarer Nähe, so wird der Fehler größer, wie dies auch YOU
ET AL. (2004) am Beispiel mit IDW interpolierter minimaler und maximaler
Temperaturwerte zeigten. Die IDW wird häufig für die Interpolation von stündlichen
Niederschlagsmengen verwendet, jedoch können auch fehlende Messwerte von anderen
Messgrößen wie der Sonnenscheindauer hiermit aufgefüllt werden (SCHULLA 1997:19). Für
die Niederschlagsinterpolation schlägt SCHULLA (1997:20) einen Exponenten zwischen 2
und 3 vor. Sollen Tageswerte oder gar Wochen-, Monats- oder Jahreswerte interpoliert
werden, empfiehlt er den die Einbeziehung der Höhe, da diese hier stärker zum Tragen
kommt.
Die Interpolation von Windgeschwindigkeiten kann mit Verfahren, die auf der Basis von
IDW beruhen und die Höhe mit einbeziehen, erfolgen. So vergleicht GERLACH (2001)
29
2 Grundlagen
Verfahren wie das Höhendifferenzen-Verfahren nach Palomino & Martin, welches die
Höhendifferenzen als Gewichte verwendet, mit dem geostatistischen Verfahren Kriging,
wobei sie mit den IDW-basierten Verfahren bessere Ergebnisse erzielt.
AHRENS (2005) ersetzt hier bei der Interpolation von täglichen Niederschlägen in Österreich
die geographische Distanz durch eine statistische Distanz und erzielt damit bessere
Ergebnisse als mit der geographischen Distanz. Die Verwendung der statistischen Distanz
ist nach AHRENS (2005) demnach vor allem in der Nähe von und in bergigen Regionen
besser geeignet als die geographische Distanz.
Lineare Regression
Die lineare Regression ist ein mathematisches Verfahren, mit dem eine Gerade so durch
eine Punktwolke gelegt wird, so dass die mittlere quadratische Abweichung der Punkte
von der Geraden minimiert wird. In Bezug auf die Daten von zwei Messstellen wird eine
Regressionsbeziehung zwischen den vorhandenen Werten erstellt. Diese wird dann
verwendet, um Fehlwerte der einen Station anhand der Werte der anderen zu füllen, wobei
von einem linearem Zusammenhang ausgegangen wird. Bei der Anwendung einer linearen
Regression mit Werten einer benachbarten Messstation entscheidet häufig das
Bestimmtheitsmaß r² (Anteil der erklärten Varianz eines Zusammenhangs) einer
Regressionsbeziehung über die Eignung einer Messstelle. Der Wertebereich von r² liegt
zwischen 0 und 1, wobei 1 für einen exakten linearen Zusammenhang steht.
Ausgehend von einer einfachen linearen Regression entwickelte Scherzer (2002) (in
KNIESS, A. & J. SCHERZER 2003:56) einen zweistufigen Regressionsansatz, der auf der
Erfahrung beruht, dass oft Ausfälle an Ziel- und Quellstationen simultan auftreten. Hier
wird zunächst eine Regression mit der besten Zeitreihe durchgeführt. Alle verbleibenden
Lücken werden mit Hilfe der nächst besten Zeitreihe aufgefüllt.
Regressionsbeziehungen können nicht nur zwischen den einzelnen Werten von Stationen
ermittelt werden, sondern auch in empirischen Regressionsmodellen für die
Regionalisierung unter der Verwendung von Hilfsvariablen wie der Höhe, geografischen
Breite und Länge, Küstennähe oder Exposition und Neigung (SCHÖNAU 2003). Die Höhe
der Stationen spielt besonders in gebirgigen Einzugsgebieten eine große Rolle, da es einige
Klimaelemente (Lufttemperatur, Dampfdruck, Windgeschwindigkeit) mit einer
ausgeprägten Höhenabhängigkeit gibt. Um die Höhe mit einzubeziehen, gibt es einen sehr
einfachen Ansatz, der von einem linearen Zusammenhang zwischen der topographischen
Höhe und dem Messwert ausgeht. Hier wird zunächst die Regressionsfunktion zwischen
den klimatologischen Parametern und der Topographie für einzelne Regionen berechnet.
Die Werte des klimatologischen Parameters an den einzelnen Messstationen werden mit
Hilfe der räumlich variablen Regressionsfunktion auf ein gemeinsames Bezugsniveau, i. A.
den Meeresspiegel, reduziert. Dieser Werten werden dann zum Beispiel mit IDW
30
2 Grundlagen
interpoliert und anschließend wieder mit der Regressionsfunktion auf die Werte der
tatsächlichen Höhe umgerechnet (MÜLLER-WESTERMEIER 2003). SCHULLA (1997:17)
beschreibt eine höhenabhängige Regression mit wechselnden Höhengradienten. Damit
können Inversionsschichten, die durch bestimmte Höhenlagen abgegrenzt werden,
abgebildet werden. In der Kombination mit IDW konnten die Ergebnisse noch verbessert
werden.
Auch die Berechnung von Abflussdaten ist unter Berücksichtigung der Laufzeitunterschiede mit einer linearen Regression möglich (LUBW 2002:18).
Weitere Verfahren
Neben den bereits beschriebenen Verfahren gibt es weitere, die bei der Interpolation in
umweltbezogenen Zeitreihen oder allgemein zur Regionalisierung verwendet werden. Zu
diesen zählen die geostatistischen Verfahren, welche im Gegensatz zu IDW,
richtungsabhängige Informationen verwenden. Räumliche Korrelationen werden somit
nicht mehr ignoriert. Die wichtigsten Verfahren sind die Kriging-Methoden (lineare
Schätzverfahren), die nach dem südafrikanischen Ingenieur D. G. Krige benannt wurden
(LORUP & FISLER 2006:22). Sie wurden Mitte dieses Jahrhunderts von G. Matheron in
Frankreich zur Anwendung im Bereich Bergbau entwickelt. Zur gleichen Zeit entwickelte
L.S. Gandin in der Sowjetunion das selbe Verfahren und wandte es auf den Bereich der
Meteorologie an (STREIT 1998). Weiterhin können auch neuronale Netze (z. B.
Backpropagation Neural Network, General Regression Neural Network) zum Lückenersatz
verwendet werden (SCHERZER 2007).
Einen sehr guten allgemeinen Überblick über das Prinzip der geographischen
Informationsverarbeitung und über mathematische Regionalisierungsverfahren geben
BURROUGH & MCDONNELL (1998). Eine Zusammenstellung verwendeter Verfahren und
Ergebnisse nach den einzelnen Klimaelementen aufgeteilt und bezogen auf die
Anwendung in der Regionalisierung ist bei SCHÖNAU (2003) zu finden.
31
3 Metadaten- und Zeitreihenverwaltung in RBIS
3 Metadaten- und Zeitreihenverwaltung in RBIS
Die Anwendungskomponente für die Verwaltung der Metadaten und der Zeitreihen im
RBIS (Abbildung 7) bildet den Ausgangspunkt und die Grundlage für die in Kapitel 4
beschriebenen Arbeiten. Im Folgenden wird diese Komponente mit RBIS-IMTIS abgekürzt, wobei IMTIS für Integrated Metadata (and) Time series Information System steht.
Mit Hilfe von RBIS-IMTIS lassen sich Metadaten von Kartendaten, Zeitreihen, Simulationsreihen, Messstationen und Dokumenten, die sich jeweils auf ein hydrologisches Einzugsgebiet oder ein Forschungsprojekt beziehen sowie die Zeitreihendaten und Dokumente
selbst, verwalten. Diese Daten können räumlich verortet werden und ermöglichen so eine
raumbezogene Auswertung. Die Verwaltung der Kartendaten erfolgt in einem separaten
Anwendungsbestandteil von RBIS unter Verwendung des UMN (University of Minnesota)
MapServers. Die Anwendungslogik des Kartenservers ist daher vom Rest der Anwendung
entkoppelt. Die Verknüpfung zwischen den beiden Komponenten erfolgt allein durch die
Verlinkung von einzelnen Inhalten. An dieser Stelle wird nur auf RBIS-IMTIS eingegangen, da der Kartenserver nicht direkt bei der Verwaltung der Zeitreihen beteiligt ist. Über
ihn können lediglich die Stationen und deren Lage im Einzugsgebiet dargestellt werden.
Die folgenden Abschnitte befassen sich mit dem zugrunde liegenden Datenbankschema,
der allgemeinen Funktionsweise von RBIS-IMTIS, den Funktionalitäten, die dem
Anwender und Anwendungsadministrator zur Verfügung stehen, sowie den generellen
Entwicklungsleitlinien, welche die Vorgaben für Erweiterungen und Veränderungen am
Datenmodell oder der Anwendung bilden.
Abbildung 7: RBIS-IMTIS: Übersichtsansicht (Metadaten für Zeitreihen)
32
3 Metadaten- und Zeitreihenverwaltung in RBIS
3.1
Datenbankschema
Das Datenbankschema für die Datenbank von RBIS-IMTIS beinhaltet eine vollständige
Umsetzung des ISO 19115 Standards und verschiedene allgemeine Erweiterungen. Eine
global eindeutige Metadaten-ID verbindet die ISO 19115 Elemente mit ihren jeweiligen
Erweiterungen (Abbildung 8). Allen Metadatensätzen ist eine solche ID zugeordnet. Dazu
gehören die Metadaten der Dokumente (Documents), Kartendaten (Map_Data), Zeitreihen
(TS_TimeSeries), Stationen (DS_Station) und Flüsse (RS_RiverSystem).
Abbildung 8: Übersicht zur zentralen Rolle der Metadaten-ID (konzeptionelles Modell)
33
3 Metadaten- und Zeitreihenverwaltung in RBIS
Weitere können als projektspezifische Erweiterungen jederzeit hinzugefügt werden. Über
die Metadaten-ID ist später in der Anwendung die Zuordnung von Dateien (Files)
beliebigen Typs zu den einzelnen Metadatensätzen möglich.
Wie bereits bei der Beschreibung des ISO 19115 (Abschnitt 2.3.1.1) aufgeführt, gibt es
eine Vielzahl an vordefinierten Codelisten. Darüber hinaus gibt es zwei weitere sehr
umfassende Codelisten. Units of Measure (UOM) beinhaltet eine umfangreiche Sammlung
verschiedener Messeinheiten und ihren Eigenschaften. Die Codeliste der Feature
Parameter (FP) enthält eine ausführliche Zusammenstellung verschiedener Parameter aus
20 Oberkategorien, die sich wiederum in Unterkategorien aufteilen. Beispiele sind u. a.
verschiedene Messstationstypen, Wasserqualitätsparameter oder Länder. Für die
Verwaltung der Zeitreihen kommen vor allem die Module TS_TimeSeries, DS_Station und
RS_RiverSystem zum Einsatz. Das Modul RS_RiverSystem realisiert die Darstellung von
einzelnen Flüssen oder Teilen von Flüssen mit ihren Eigenschaften und Beziehungen
untereinander. In DS_Station (Anhang A Abbildung 33) werden die Messstationen
beschrieben und die Zeitreihen mit diesen verknüpft. Einer Station können beliebig viele
Zeitreihen zugeordnet werden. Zu einer Station können Informationen wie der Name, die
Lage, Zuordnung zu einem Flusssystem, Betriebsbeginn und -ende und verantwortliche
Person oder Organisation hinterlegt werden. Jeder Station können ein oder mehrere
Stationstypen zugeordnet werden. Das können zum Beispiel Niederschlags-, Klima- oder
Abflusspegelstationen sein. Weiterhin ist es an dieser Stelle möglich, Eigenschaften, die
nur einen bestimmten Stationstyp betreffen, anzugeben. Ein Beispiel hierfür ist der
Durchmesser und die Tiefe von Bohrlöchern zur Messung des Grundwasserpegels. In
TS_TimeSeries (Anhang A Abbildung 34) werden die Metadaten der Zeitreihen verwaltet.
Dazu zählen auch Informationen über die Art der Werte und Einheiten der einzelnen
Attribute. Im Rahmen dieser Arbeit wurden hier einige Ergänzungen vorgenommen, die in
Abschnitt 4.2.1 beschrieben werden.
Im aktuellen konzeptionellen Modell ist die vollkommen unabhängige Tabellenstruktur der
Systemdateien der Anwendung nicht enthalten. In ihr findet die gesamte Nutzer- und
Rechteverwaltung, die Verwaltung der eigenen Codelisten und der Protokolle statt.
Systemtabellen sind durch die Vorsilbe app_ in der Datenbank eindeutig identifizierbar.
34
3 Metadaten- und Zeitreihenverwaltung in RBIS
3.2
Grundlegende interne Funktionsweise
Das RBIS-IMTIS ist eine Web-Anwendung, das in der Skriptsprache PHP programmiert
ist. Ein Großteil der Anwendungslogik basiert im wesentlichen auf der Interaktion
zwischen XML-Dokumenten und PHP-Skripten. Darüber hinaus gibt es Funktionen, die
dem Schutz der Daten und der Datenintegrität dienen.
3.2.1
XML-Dokumente
Die Web-Anwendung ist sehr flexibel, da über die XML-Dokumente Anpassungen sehr
einfach und schnell vorgenommen werden können. Fast alle Anwendungsbereiche greifen
auf XML-Dokumente zurück, die den Hauptkern der Anwendung bilden. Diese XMLDokumente werden für die Definition und Beschreibung der einzelnen inhaltlichen Sichten
auf die Daten, wie zum Beispiel die Metadaten zu einer Station, verwendet. Sie
entsprechen ihrer Funktion nach einem View in der Datenbank auf die Daten. Der Grund
für die Verwendung von diesen Views auf der Seite der Anwendung und nicht auf der
Seite der Datenbank liegt darin, dass Datenbankviews, sobald Inhalte aus mehr als eine
Tabelle betroffen sind, nicht mehr über diesen View geändert oder neu eingefügt werden
können. In den bestehenden Anwendungsfällen gibt es jedoch nur sehr wenige Sichten, die
tatsächlich nur eine Tabelle benutzen. Vielmehr ist es so, dass im Extremfall ein Umfang
von bis zu 60 Tabellen pro Sicht erreicht wird. Die allgemeine Funktionsweise ist in
Abbildung 9 dargestellt.
Abbildung 9: Bedeutung von XML-Dokumenten im RBIS-IMTIS
35
3 Metadaten- und Zeitreihenverwaltung in RBIS
Die Informationen in einem XML-Dokument werden auf der einen Seite zur dynamischen
Erzeugung der SELECT (ab1), INSERT, DELETE und UPDATE (b7) SQL-Anweisungen
verwendet. Andererseits dienen sie in der Anwendung zur dynamischen Generierung der
Anordnung der Inhalte (ab4). Weiterhin werden sie für die Wahl verschiedener Eingabefeldtypen für die Formulare (b4) für das Neuanlegen und Ändern von Inhalten verwendet.
Die zugrunde liegenden Mechanismen sind durch die verwendeten Elemente und Attribute
in dem XML-Dokument leicht steuerbar, eröffnen eine große Breite an Kombinationsmöglichkeiten und lassen auch Spielraum für Anpassungen, die teilweise sehr komplex
sein können. Bei der dynamischen Generierung von INSERT- und DELETE-Anweisungen
wird intern zusätzlich die richtige Reihenfolge für eine erfolgreiche Ausführung anhand
verschiedener Indikatoren aus dem XML-Dokument ermittelt. Über die XML-Dokumente
kann auf das komplette Datenbankschema zugegriffen werden. Geänderte oder neue XMLDateien können gegen ein aktuelles XML Schema (Abbildung 35) validiert werden. Die
einzelnen Elemente ohne ihre jeweiligen Attribute sind in Abbildung 10 dargestellt.
Abbildung 10: Übersicht XML-Schema von RBIS-IMTIS
Verschiedene Sichten können über die Angabe von PHP-Code als Wert spezieller
Elemente untereinander verlinkt sein und ermöglichen somit eine anwenderfreundliche
Navigation zwischen verschiedenen Inhalten. Das Element table bzw. das Unterelement
besitzt eine Vielzahl von Attributen wie beispielsweise name, title, type, group, order oder
size, die für die Darstellung der Daten von Bedeutung sind. Über die Attribute (from_table,
from_key, to_table, to_table_alias, to_key) des Elements join werden die JoinBedingungen für die bei table aufgelisteten Tabellen definiert. Generell werden diese bei
der Zusammenstellung einer SQL-Anweisung immer als LEFT JOIN umgesetzt. Die
Verwendung eines expliziten Joins kann bei größeren Joins entscheidend die
Ausführungszeit verkürzen, da dem Optimierer der Datenbank eine Reihenfolge für die
Joins vorgegeben wird (POSTGRESQL 2007).
36
3 Metadaten- und Zeitreihenverwaltung in RBIS
Für Anwendungsfälle, die nicht nach diesem einheitlichen Schema abgebildet werden
können, existieren im Vergleich zu den sehr flexiblen XML-Dokumenten Webseiten mit
mehr oder minder statischem Aufbau und Inhalt. Darunter fallen u. a. die Seiten für die
Benutzerauthentifikation, das Importieren von Zeitreihen oder die Ansicht der
Zeitreihendaten.
3.2.2
Sicherheit
Das RBIS-IMTIS ist über das Internet erreichbar und gegen Zugriffe von nicht autorisierten Personen durch die Abfrage von Zugriffskontrolle bzw. Benutzerauthentifikation
geschützt. Innerhalb der Anwendung gibt es ein detailliertes und anpassungsfähiges
Rechtesystem bezogen auf die Ebene von einzelnen Sichten und Aktionen (Lesen,
Schreiben/Ändern, Löschen). So können beispielsweise Nutzergruppen mit nur lesendem
Zugriff angelegt werden oder Gruppen mit vollen oder eingeschränkten Schreibrechten. In
Abbildung 11 sind die Rechte für die Ansicht der Zeitreihendaten dargestellt. Benutzer, die
der Gruppe „Group 3“ zugeordnet sind, dürfen hier weder Zeitreihendaten herunterladen
(„Export“), importieren („Import“) noch löschen („Delete“). Angehörige der Gruppen
„Group 4/5“ besitzen uneingeschränkte Rechte und die Benutzer aus Gruppe „Group 6“
dürfen lediglich Daten herunterladen, diese jedoch nicht ändern (importieren oder löschen).
Abbildung 11: RBIS-IMTIS: Oberfläche zur Rechteverwaltung
Eine zusätzliche Sicherheitsebene ermöglicht es Rechte bezogen auf einzelne Datensätze
mit einer Metadaten-ID zu vergeben. Ist dieses zusätzliche Rechtesystem aktiviert, können
alle Metadatensätze und Zeitreihen nur noch von ihrem Eigentümer (Nutzer der den
Metadatensatz angelegt hat) oder von allen Nutzern verändert bzw. exportiert werden,
sofern diese aus der übergeordneten Sicherheitsebene dieses Recht generell besitzen.
Dieses mehrschichtigen Verfahren ermöglicht eine feingranulare Rechteverwaltung, wie
sie für ein Informationssystem mit einer großen Anzahl von Benutzern und sensiblen
Daten zwingend erforderlich ist.
37
3 Metadaten- und Zeitreihenverwaltung in RBIS
3.2.3
Datenintegrität
Für die Datenintegrität im RBIS-IMTIS sorgen mehrere Mechanismen. Die Formate der
Eingabewerte werden hinsichtlich ihres korrekten Typs (Datum, Float, Integer, Email und
Länge) geprüft und falls nötig in ein anderes Format umgewandelt, wie das bei
Zeitangaben oder Passwörtern notwendig ist. Alle schreibenden Befehle an die Datenbank
werden innerhalb von Datenbanktransaktionen ausgeführt. Generell werden alle
Veränderungen am Datenbestand sowie aufgetretene Fehler in verschiedenen Protokollen
(Abbildung 12), die von Anwendungsadministratoren eingesehen und analysiert werden
können, erfasst. Hier lässt sich auch der Änderungsverlauf eines Datensatzes
nachvollziehen. Falls notwendig ist somit die Wiederherstellung eines älteren Zustandes
des Metadatensatzes per Hand möglich. Bei den Protokollen wird entsprechend der Art des
Datenbankzugriffs zwischen dem INSERT, UPDATE und DELETE – Protokollen
unterschieden. Sie halten jeweils den Benutzernamen, den Zeitpunkt und die IP-Adresse
des Zugriffes fest. Bei einem INSERT werden die neuen Inhalte sowie die Werte der neu
erzeugten Primärschlüssel abgespeichert. Im Falle von UPDATE und DELETE wird der
Zustand des Datensatzes vor der Änderung gespeichert. Schlagen diese Aktionen aus
irgendeinem Grund fehl, wird ein entsprechender Eintrag zusammen mit der letzten an die
Datenbank versandten SQL-Anweisung, der Anzahl der betroffenen Datensätze und, falls
vorhanden, die ermittelte Fehlermeldung in das ERROR-Protokoll geschrieben. Die
Vermeidung von Verletzungen der referenziellen Integrität in der Datenbank wird vom
DBMS PostgreSQL sichergestellt.
Abbildung 12: Erfassung aller Schreibenden Zugriffe in Logs
38
3 Metadaten- und Zeitreihenverwaltung in RBIS
3.3
Funktionsumfang aus der Sicht der Anwender
Die Web-Anwendung bietet dem Benutzer eine Vielzahl von Funktionen an. Alle im
RBIS-IMTIS erfassten Informationen können innerhalb der vom Anwendungsadministrator definierten Sichten dargestellt werden. Für jede dieser Sichten gibt es jeweils
eine Übersichtsansicht, bei der die Anzahl der dargestellten Datensätze pro Seite frei
wählbar ist. Von dieser ausgehend, können Detailinformationen zu jedem Datensatz
eingesehen werden. Viele Detailansichten enthalten Links zu anderen Inhalten wie zum
Beispiel den Zeitreihen- oder Kartendaten. Die Suchfunktion auf der Ebene der einzelnen
Sichten hilft dem Anwender, gesuchte Informationen schnell zu finden. Bei der Suche
kann zwischen einer Freitextsuche oder einer Suche über Auswahlfelder, die nur
tatsächlich verwendete Attributwerte anbietet, gewählt werden.
Die Erfassung der Informationen erfolgt ebenfalls über Sichten. Um eine einfache und
eindeutige Eingabe der Daten zu unterstützen, sind die Eingabefelder entsprechend des
erwarteten Typs angepasst und die Pflichtfelder farblich hervorgehoben. Zu den möglichen
Varianten zählen einfache Textfelder, Textboxen für die Eingabe von längeren
Beschreibungen, Datumsfelder mit einem interaktiven Kalender, anpassungsfähige
Auswahllisten sowie Radiobuttons für die Auswahl von Formularfeldern. Für die Eingabe
von Daten steht dem Nutzer eine Hilfefunktion zu jedem Eingabefeld zur Verfügung,
deren Text vom Anwendungsadministrator frei editiert werden kann. Eine Vorbelegung
der Formularfelder durch Defaultwerte ist ebenfalls durch eine entsprechende Angabe im
XML-Dokument möglich. Wird das Formular abgeschickt, werden alle Datentypen und
Pflichtfelder überprüft. Der Nutzer wird beim Auftreten eines Fehlers solange zum
Korrigieren seiner Eingaben aufgefordert bis seine Eingaben korrekt sind. Einem
angelegten Metadatensatz können anschließend beliebig viele Dateien zugeordnet werden.
Zu jedem Metadatensatz für Zeitreihen können Zeitreihendaten importiert werden, die
anschließend grafisch dargestellt und komplett oder in Teilen exportiert werden können.
Die Originaldaten können hierbei in verschiedenen Datumsformaten vorliegen. Andere
Metadatensätze (Geodaten, Stationen) können hingegen mit einem Layer, einem
Geometrieobjekt oder einer Karte auf der Seite des Kartenservers über einen Link
verknüpft werden. Für ein automatisches Anlegen und Verknüpfen aller Stationen anhand
der gegebenen Koordinaten in einem Layer als ein Geometrieobjekt gibt es ebenfalls eine
Funktion, die vom Anwendungsadministrator ausgeführt werden kann.
39
3 Metadaten- und Zeitreihenverwaltung in RBIS
3.4
Aktueller Datenbestand im RBIS-IMTIS
Im RBIS-IMTIS werden verschiedene Zeitreihen verwaltet, die sich derzeit in die
Teilbereiche Geografie, Meteorologie, Hydrologie und Wasserwirtschaft untergliedern
lassen.
Zu den geografischen Daten gehören Angaben über die räumliche Verteilung der
Messstationen durch ihre Koordinaten und Höhenangabe. Zur Meteorologie zählen
Zeitreihendaten zum Niederschlag, der Lufttemperatur, dem Luftdruck, der
Luftfeuchtigkeit, der Windstärke, der Strahlung und der Sonnenscheindauer. Im Bereich
der Hydrologie gibt es Abflussdaten, Grundwasserstände und Schneedaten. Zu den
wasserwirtschaftlichen Zeitreihen gehören vor allem eine Vielzahl von
Gewässergüteparametern. Bei der Speicherung der Werte in der Datenbank wird das
Datum in UNIX-Zeit umgewandelt, wobei es auch möglich ist mehrere Werte zu ein und
demselbem Datum anzugeben. Die UNIX-Zeit wurde für das Betriebssystem UNIX
entwickelt und gibt die vergangene Zeit in Sekunden seit dem 1.1.1970 00:00 nach
koordinierter Weltzeit (UTC ) an (IEEE & OPEN GROUP 2004). Abbildung 13 zeigt ein
Beispiel aus der Zeitreihendatenbank für eine Temperaturzeitreihe. Die Beschreibung der
einzelnen Attribute erfolgt in den Metadaten der Zeitreihe.
Abbildung 13: tägliche Temperaturwerte (Minimalwert (value1),
Durchschnittswert (value2) und Maximalwert (value3))
Des weiteren werden Datensätze über Personen und Organisationen sowie Metadaten zu
Stationen (SaaleRBIS: ~1200), Zeitreihen (SaaleRBIS: ~1900), Flüssen (SaaleRBIS: ~84),
Geodaten und Dokumenten verwaltet.
Für die Weiterentwicklung der Anwendung kann auf den Datenbestand des Lehrstuhls für
Geoinformatik, Geohydrologie und Modellierung der Universität Jena zurückgegriffen
werden. In erster Linie wird hier mit den zur Verfügung stehenden Daten aus dem
Einzugsgebiet der Saale (SaaleRBIS) gearbeitet. Die Praxistauglichkeit wird bei den aktiv
genutzten Installationen BrahmaRBIS und DanubeRBIS aus dem BrahmatwinnForschungsprojekt getestet.
40
3 Metadaten- und Zeitreihenverwaltung in RBIS
3.5
Anforderungen für zukünftige Erweiterungen
Für die Umsetzung zukünftiger Erweiterungen gibt es verschiedene Anforderungen bei der
Anwendungsentwicklung sowie bei der Datenbankmodellierung. Das RBIS soll
anpassungsfähig bleiben, damit neue Anforderungen einfach realisiert werden können
Weiterhin zählt eine weitgehende DBMS- und plattformunabhängige Entwicklung der
Anwendung, aber auch der Einsatz von Open Source Software sowie ein flexibler,
transparenter und modularer Aufbau der Anwendungsstruktur zu den Anforderungen.
Ebenso muss die Benutzung einfach und übersichtlich für einen typischen Endanwender
von RBIS sein. Komplexere Konfigurationsmöglichkeiten sollten nur für einen
ausgewählten Benutzerkreis zugänglich sein. Alle Informationen, die automatisch generiert
werden können, sollten von der Anwendung auch automatisch erzeugt werden, um den
Endanwender zu entlasten und um Fehlern bei der Eingabe vorzubeugen.
Für das Datenbankschema gelten alle allgemeinen Anforderungen an eine gute
Datenmodellierung, wie etwa eine stets inhaltlich aussagekräftige Benennung der Spalten
und Tabellen. Ergänzend dazu sind neue Tabellen, die einem klar abgrenzbaren Modul
oder Teilmodul angehören, durch führende Buchstaben zu kennzeichnen. Spalten, die den
Primärschlüssel enthalten, setzen sich stets aus dem Tabellennamen und der Endung „_id“
zusammen. Werden diese als Fremdschlüssel in anderen Tabellen verwendet, sollte
möglichst dort der gleiche Name verwendet werden. Generell sind Tabellen mit einem
zusammengesetzten Primärschlüssel zu vermeiden. Primär- und Fremdschlüsseldefinitionen sind anzulegen. Alle Änderungen an der Datenbank müssen im
konzeptionellen Datenmodell nachgeführt werden.
41
4 Verwaltung und Interpolation von Zeitreihen in RBIS
4 Verwaltung und Interpolation von Zeitreihen in RBIS
Im Rahmen der Diplomarbeit wurden die Komponenten für die Verwaltung der Zeitreihen
weiterentwickelt und angepasst. Dabei wurde der gesamte Lebenszyklus von Zeitreihendaten mit ihren Metadaten innerhalb von RBIS, beginnend mit dem Einpflegen der Daten
über die Interpolation bis hin zum Export, vollständig überarbeitet und ergänzt. Das Modul
für die Interpolation von Zeitreihendaten ist komplett neu entstanden und kann optional
hinzugefügt werden.
Nach der Beschreibung der Ausgangssituation und der sich daraus ergebenden konkreten
Problemstellung wird die Umsetzung vorgestellt, die sich in vier einzelne Arbeitspakete
zerlegen lässt. Die einzelnen Arbeitspakete wurden in der angegebenen Reihenfolge
bearbeitet und lauten wie folgt:
●
Ergänzen der Metadaten um wichtige beschreibende Informationen
●
Bereitstellung verschiedener Datenanalysemöglichkeiten
●
Implementierung und Anwendung verschiedener Interpolationsverfahren
●
Zugriff auf den Datenbestand (Export)
Jedes Arbeitspaket wird im Folgenden sowohl hinsichtlich seiner Umsetzung als auch
seiner Funktionsweise dargestellt.
4.1
Problemstellung und Ausgangssituation
Der Import von Daten über RBIS erfolgte bisher ohne Kontrollmechanismen und nur
wenigen Datenprüfungen, so dass dementsprechend auch keine ausreichend hohe Qualität
der importierten Daten gewährleistet werden konnte. Es gab kaum Möglichkeiten für den
Anwender, den Grund für einen fehlgeschlagenen Importvorgang zu erfahren. An dieser
Stelle bestand die Aufgabe darin, den Importvorgang um eine angemessene
Fehlererkennung und Fehlerausgabe zu ergänzen. Zusammen mit entsprechenden
Kontrollmechanismen soll sichergestellt werden, dass die Daten für eine spätere Analyse
oder Interpolation verwendet werden können. Bisher wurden im RBIS keinerlei
Informationen über Lücken erfasst oder diese entsprechend aufgefüllt. Die Zeitreihendaten
konnten demzufolge nur genauso heruntergeladen werden, wie sie in das System
eingespeist wurden. Sollten diese Daten jedoch in einer Anwendung, wie etwa dem
Framework Jena Adaptable Modelling System (JAMS) für die Entwicklung und
Anwendung von Umweltmodellen, verwendet werden, so dürfen diese keine Lücken
enthalten (FSU 2007a). Der Grund dafür ist, dass diese Anwendungen nicht immer
Funktionen zur Verfügung stellen, die diese Lücken schließen können. Für einen
Modelllauf werden jedoch stets vollständige Datensätze benötigt. Ein weiteres Ziel der
Arbeit war es demzufolge, eine Erweiterung für RBIS-IMTIS zu entwickeln, die
vorhandene Datenlücken erkennt und schließt. Für das Erkennen und Schließen von
42
4 Verwaltung und Interpolation von Zeitreihen in RBIS
Datenlücken ergaben sich folgende Problemstellungen, die im Verlauf der Umsetzung der
Aufgabe beachtet werden mussten:
●
die Länge der gesamten Zeitreihe ist unbekannt bzw. immer verschieden
●
die Lücken selbst und ihre Länge und Anzahl sind unbekannt
●
es sind keine Angaben über verwendete Fehlkennungen vorhanden
●
es gibt keine Angaben über den verwendeten Zeitschritt bzw. dessen Konsistenz
über den gesamten dargestellten Zeitraum einer Zeitreihe
●
es existiert keine gesicherten Aussagen über die Qualität der Daten
●
die geografische Distanz zwischen zwei Zeitreihen und die Korrelation zwischen
diesen ist nicht bekannt
●
es gibt nicht nur ein Interpolationsverfahren für einen Parameter, sondern immer
eine Reihe von Verfahren, die je nach Einzugsgebiet, Größe der Lücke und anderen
Einflussfaktoren besser oder schlechter geeignet sind
●
die Vielfalt der Kombinationsmöglichkeiten zwischen dem vorliegenden
Zeitschritt, Parameter und Einheit schließt eine unüberwachte und vollautomatische
Interpolation der Werte aus.
4.2
Metadaten über Zeitreihen
Für die Suche von Zeitreihen ohne auf die Daten der Zeitreihe direkt zuzugreifen ist es
erforderlich, Informationen wie Beginn und Ende, Zeitintervall, verwendete
Fehlkennungen und Informationen über Datenlücken der Zeitreihe bei den Metadaten
abzuspeichern. Bisher wurde als beschreibende Information der Zeitreihen nur das
Zeitintervall einer Zeitreihe erfasst. Es konnte bei den Metadaten vor bzw. nach dem
Importieren der Daten manuell eingetragen werden, so dass diese Informationen eher
selten angegeben wurden. Dies erfolgte zudem ohne eine Überprüfung, ob die Angaben auf
die Daten tatsächlich zutreffen.
Für das Abspeichern der zusätzlich benötigten Metadaten war es unvermeidlich, das
bestehende Datenmodell sowie den vorhanden Datenbestand aller aktiver Installationen
von RBIS-IMTIS den Änderungen entsprechend anzupassen. Die Anpassungen im
Datenmodell sollen es ermöglichen, einfache Anfragen ohne Zugriff auf die Daten selbst
zu beantworten. Darüber hinaus können mit diesen Informationen einfache
Konsistenzprüfungen durchgeführt werden. Für die Realisierung der neuen Funktionen, die
möglichst automatisch Metadaten-Informationen prüfen, erzeugen und einfügen, sowie die
Datenkonsistenz zu jeder Zeit gewährleisten, war eine umfassende Überarbeitung der
vorhandenen Funktionalität notwendig. Diese wird im Folgenden nach den notwendigen
Datenmodellanpassungen beschrieben.
43
4 Verwaltung und Interpolation von Zeitreihen in RBIS
4.2.1
Anpassung des Datenmodells für die Verwaltung
Zu den Stamminformationen einer Zeitreihe (Ausschnitt des physischen Datenmodells
siehe Abbildung 14) wurden Attribute für die verwendete Fehlkennungen und das
verwendete Zeitintervall hinzugefügt. Die Fehlkennung (ts_timeser.missing_value) wurde
als character varying mit einer Länge von 20 eingefügt. Derzeit sind nur Zahlen als
Fehlkennung angedacht. Hier soll jedoch die Möglichkeit offen gehalten werden, später
auch nicht numerische Zeichen zu akzeptieren. Bei den Attributen für den Beginn
(ts_timeser.startdatetime) und das Ende (ts_timeser.enddatetime) einer Zeitreihe wurde der
Datentyp von integer (32 Bit) in bigint (64 Bit) umgeändert. Der Grund hierfür ist, dass die
Speicherung eines Datums im RBIS bevorzugt in UNIX-Zeit erfolgt. Wird nun die UNIXZeit vor 1901 und nach 2038 berechnet, so ergibt sich ein Integer-Wert, der mehr als 32 Bit
beansprucht (IEEE & OPEN GROUP 2004).
Abbildung 14: Tabelle „ts_timeser“ (physisches Datenmodell)
Für die Speicherung der Informationen über die Datenlücken wurden die bestehenden
Entwürfe entsprechend den neuen Anforderungen verändert. In Abbildung 15 ist die
physische Umsetzung des Moduls für die Datenzuverlässigkeit dargestellt. Jede Zeitreihe
erhielt eine DataReliability-ID (dr_datarelia.dr_datarelia_id), zu der eine allgemeine
Beschreibung über die Qualität der Daten (dr_datarelia.descr), ein Status der Daten
(dr_datarelia.sc_scstatuscd_id), und ein Boolean-Wert für den Erfolg bzw. Misserfolg
einer Datenlückenanalyse (dr_datarelia.gapanalysis) zugeordnet werden können. Jedes
Datenlückenintervall, das immer durch ein Anfangs- und Enddatum (dr_datagps.startgap
bzw. dr_datagaps. Endgap) sowie seiner Länge (dr_datagaps.length) und der als ID
verwendeten Spaltennummer (dr_datatgaps. colnumber) charakterisiert wird, erhält eine
eigene ID (dr_datagaps.dr_datagpaps_id). Sie wird über diese und der DataReliability-ID
mit einer Spaltennummer (als ID) bzw. einer Messgröße innerhalb einer Zeitreihe
verknüpft. Das Datenmodell sieht weiterhin vor, zusätzlich Informationen über den Grund
jeder einzelnen Datenlücke und gegebenenfalls der zum Füllen verwendeten Methode
aufzunehmen. Diese Teile des Datenmodells wurden jedoch im Folgenden nicht
verwendet, da die Abspeicherung der verwendeten Interpolationsmethode innerhalb des
Interpolationsmoduls erfolgt (siehe Abschnitt 4.4.1.1).
44
4 Verwaltung und Interpolation von Zeitreihen in RBIS
Abbildung 15: Datenzuverlässigkeitsmodul (physisches Datenmodell)
45
4 Verwaltung und Interpolation von Zeitreihen in RBIS
4.2.2
Erweiterung des Import-Formulares
Um Informationen über die Datenlücken einer Zeitreihe automatisch zu generieren, war es
erforderlich, die Import-Funktionen entsprechend anzupassen. Zusätzlich zu den bisherigen
Angaben, nämlich dem Quellverzeichnis der Textdatei mit den Messwerten und dem
Datumsformat, wird der Nutzer nun aufgefordert, schon zu Beginn den Zeitschritt (z. B.
„täglich“) anzugeben. Weiterhin gibt es die Möglichkeit, Werte über die verwendete
Fehlkennung anzugeben, die zuvor für fehlende oder fehlerhafte Messwerte eingesetzt
wurde (z. B. „ -9999“)(Abbildung 16).
Abbildung 16: Import-Formular für Zeitreihendaten
4.2.3
Überarbeitung der Upload-Funktion
Die vorhandenen Funktionen, die beim Importieren einer Zeitreihe benutzt werden,
umfassten lediglich Grundfunktionen wie das Hochladen der Datei, das Speichern der
Metadaten-Information, das Auslesen und Umwandeln des Datums und der Messwerte und
das Einfügen der Daten in die Datenbank. Dabei wurden keinerlei Fehler abgefangen, die
Originaldaten hinsichtlich ihrer Qualität nicht geprüft und zu keinem Zeitpunkt wurde die
Konsistenz der Daten in der Datenbank gewährleistet. Um dies zu beheben und um
zusätzliche Metadaten automatisch zu erzeugen, wurde die Verwendung von
Datenbanktransaktionen, eine Qualitätsprüfung sowie eine Datenlückenanalyse eingeführt
und in den gesamten Import-Vorgang integriert.
Im folgenden Abschnitt wird zunächst auf die allgemeinen Eigenschaften und
Bedeutungen von Transaktionen eingegangen und anschließend die Anwendung in der
Import-Funktion betrachtet. Nach den Ausführungen zur Qualitätssicherung werden die
Datenlückenanalyse und die damit verbunden Änderungen am Datenmodell genauer
betrachtet.
46
4 Verwaltung und Interpolation von Zeitreihen in RBIS
4.2.3.1
Transaktionen
Fast alle DBMS unterstützen die Ausführung von Transaktionen zur Integritätssicherung
und der Realisierung eines Mehrbenutzerbetriebes. Eine Transaktion ist eine Folge von
Datenbankoperationen, die als Einheit (atomar) angesehen wird. Relationenübergreifende
Integritätsbedingungen müssen vor und nach dem Ende einer Transaktion gewährleistet
sein, jedoch dürfen Einzel-Operation innerhalb einer Transaktion diese verletzen.
Transaktionen müssen immer die ACID-Eigenschaften (Atomarität (atomicity), Konsistenz
(consistency), Isoliertheit (isolation) und Dauerhaftigkeit (durability)) erfüllen.
Atomarität bedeutet, dass eine Transaktion entweder ganz oder gar nicht ausgeführt wird
und keine Zwischenzustände in der Datenbank hinterlässt. Eine Transaktion wird mit
einem COMMIT (abschließen) erfolgreich beendet und mit einem abort (abbrechen) bzw.
ROLLBACK (zurücksetzen) zurückgesetzt.
Die Konsistenz wird durch die Betrachtung einer Transaktion als Einheit mit der
Voraussetzung, dass am Ende alle Integritätsbedingungen erfüllt sein müssen, hergestellt.
Unter Isoliertheit wird verstanden, dass einzelne Transaktionen im simulierten
Einzelnutzerbetrieb ablaufen. Parallel ablaufende Transaktionen sind isoliert und können
sich nicht gegenseitig beeinflussen. Je nach verwendeten Isolation-Level wird der Grad der
Isoliertheit festgelegt.
Die Dauerhaftigkeit garantiert nach einem Fehlerfall, dass die Daten in der Datenbank
nach Beendigung der Transaktion enthalten sind, auch wenn diese vor einem
Systemversagen noch nicht in die Datenbank geschrieben worden sind (HEUER & SAAKE
2000:497ff, SAAKE ET. AL 2005:497ff).
Der Einsatz von Transaktionen ist während des gesamten Import-Prozesses vorteilhaft, da
hier Qualitätsprüfungen in der Anwendung und viele Datenbankoperationen auf der
Metadaten- und auf der Zeitreihendatenbank ausgeführt werden, die einen Fehler erzeugen
können. Vor allem alle schreibenden Zugriffe auf die Datenbanken sollten innerhalb einer
Transaktion ausgeführt werden, um im Fehlerfall alle Änderungen sauber und einfach
rückgängig machen zu können. Hierzu wird eine Transaktion auf der Metadatendatenbank
und parallel dazu eine auf der Zeitreihendatenbank gestartet (siehe Abbildung 17). Schlägt
einer dieser beiden fehl, wird auch die jeweils andere von der Anwendung durch ein
„ROLLBACK“ beendet. Transaktionen werden nach einem nicht erfolgreichen Einfügen
eines Datensatzes automatisch von der Datenbank zurückgesetzt. Sie können jedoch auch
nach identifizierten Fehlern bei der Qualitätsprüfung oder Datenlückanalyse von der
Anwendung zurückgesetzt werden. Die Anwendung stellt sicher, dass dann auch die
andere Transaktion beendet wird. Erst wenn der Import-Prozess erfolgreich abgeschlossen
wurde, werden die beiden Transaktionen mit einem „COMMIT“ beendet. Aufgrund der
ACID-Eigenschaft von Transaktionen ist die Konsistenz der Daten in der Datenbank
47
4 Verwaltung und Interpolation von Zeitreihen in RBIS
gewährleistet Bei dem verwendeten Isolation-Level („read committed“) werden
Änderungen erst nach erfolgreicher Beendigung der Transaktionen für andere Nutzer
sichtbar (SAAKE ET. AL 2005:600f).
Besonders vorteilhaft ist dies bei größeren Datenmengen, bei denen das Importieren der
Daten bis zu 20 Minuten daueren kann und auch am Ende noch Fehler auftreten können.
Während dieser Zeit können alle anderen Nutzer weder die Änderungen sehen noch den
entsprechenden Metadatendatensatz editieren. Sie können jedoch lesend auf den
Ausgangszustand zugreifen.
Abbildung 17: Transaktionen innerhalb eines Import (Upload)-Vorgangs
Für eine Nachverfolgung der Änderungen wird zu Beginn eines Import-Prozesses ein
entsprechender Eintrag in das Update-Protokoll geschrieben. Tritt ein Fehler auf, werden
nicht nur die Transaktionen beendet, sondern es wird zusätzlich dieser Fehler in das ErrorProtokoll mit der entsprechenden Fehlermeldung geschrieben. Der Anwender erhält eine
kurze Fehlerbeschreibung und wird zum Import-Formular umgeleitet. War der Vorgang
erfolgreich, erscheint die Eingabemaske zum Editieren der Metadaten der importierten
Zeitreihe. An dieser Stelle erfolgt ebenfalls durch den RBIS-Benutzer die Zuordnung der
Messgrößen und Einheiten zu den Spalten in der importierten Textdatei.
48
4 Verwaltung und Interpolation von Zeitreihen in RBIS
4.2.3.2
Qualitätsprüfung
Während des Importierens werden die Daten hinsichtlich verschiedener
Qualitätsanforderungen an die Originaldaten geprüft. Dazu gehört die Überprüfung des
vom Nutzer angegebenen Datenformates des Datums. Das Datum muss in der Textdatei
immer in der ersten Spalte stehen und der durch den Benutzer angegebenen Reihenfolge
von Tag, Monat und Jahr entsprechen. Mit der Prüfung wird einerseits das angegebene
Format überprüft und anderseits sichergestellt, dass das Format nicht innerhalb einer Datei
wechselt. Darüber hinaus muss für eine erfolgreiche Datenlückenanalyse das Datum
aufsteigend sortiert sein, da zu diesem Zeitpunkt der Anwendung immer nur das aktuelle
und vorherige Datum berücksichtigt wird.
Neben dem Datum werden auch die Werte in Bezug auf ihren Datentyp überprüft. Erlaubt
sind ausschließlich numerische Zeichen, da in der Datenbank der Datentyp numeric für die
Speicherung der Werte verwendet wird. Kommastellen können mit Punkt oder Komma
abgetrennt sein. Vor dem Einfügen der Daten in die Datenbank, werden alle Kommas in
Punkte umgewandelt, da sie sonst ebenfalls nicht mit dem verwendeten Datentyp
kompatibel sind.
Wird eines der genannten Kriterien nicht erfüllt, wird der gesamte Import-Vorgang
abgebrochen und dem Nutzer eine Fehlermeldung mit einer kurzen Fehlerbeschreibung
angezeigt.
4.2.3.3
Datenlückenanalyse
Die Identifizierung von Datenlücken erfolgt während des Auslesens und Schreibens der
Daten. Hierbei werden generell zwei verschiedene Arten von Lücken erkannt:
●
Lücken, die durch einen Zeitsprung entstanden sind (Datumslücke) (z. B. bei
täglichen Werten, ein Sprung vom 01.01.2000 auf den 20.01.2000, wobei die
Zeitspanne vom 2. bis 19. undefiniert ist)
●
Lücken, die durch eine Fehlkennung oder einem fehlenden Wert entstanden sind
(z. B. wenn für einen definierten Zeitpunkt der Wert undefiniert ist, wobei sowohl
die Fehlkennung als auch ein fehlender Wert als „undefiniert“ interpretiert werden)
Dabei können sich mehrere Kombinationsmöglichkeiten von Datums- und Wertelücken
ergeben. Grenzen diese unmittelbar aneinander, werden sie zusammengefasst und als eine
einzige zusammenhängende Lücke bzw. ein Lückenintervall behandelt.
In der aktuellen Version wird eine Prüfung auf Lücken nur dann durchgeführt, wenn der
Zeitschritt äquidistant ist und sich in Sekunden ausdrücken lässt, d. h. Werte auf der Basis
von Sekunden und Minuten bis hin zu einer bestimmten Anzahl von Tagen. Monatliche,
jährliche oder unregelmäßige Zeitintervalle können aufgrund der unterschiedlichen Anzahl
von Tagen bzw. Sekunden nicht berücksichtigt werden.
49
4 Verwaltung und Interpolation von Zeitreihen in RBIS
Das Ergebnis der Lückenprüfung und die Fehlkennung werden abschließend den
Metadaten hinzugefügt (Abbildung 18). Die Speicherung erfolgt hierbei pro Spalte und
Zeitreihe unter Angabe von Beginn (erster Zeitpunkt in einem Lückenintervall) und Ende
(letzter Zeitpunkt in einem Lückenintervall), sowie der Länge des Lückenintervalls in der
Einheit des verwendeten Zeitschrittes.
Für eine Suche nach Zeitreihen, die für ein bestimmtes Zeitintervall zur Verfügung stehen,
ist es erforderlich, jeweils den Beginn und das Ende einer Zeitreihe als Metadaten
abzuspeichern. Die Gründe hierfür liegen einerseits in der Aufteilung der Metadaten und
der Zeitreihendaten in je einer Datenbank, da hier eine Abfrage auf die Datenbanken
innerhalb einer Abfrage in dem verwendeten PostgreSQL nicht möglich ist und dadurch
immer zwei Abfragen nötig wären. Damit würde sich der Aufwand und die
Fehleranfälligkeit erhöhen. Andererseits verkürzt sich die Dauer der Abfrage wesentlich,
da der erste und letzte Tag, an dem Werte gemessen wurden, nicht erst selektiert werden
muss. Ein weiterer Vorteil liegt in der Verfügbarkeit der Informationen. Für den Fall, dass
die Datenbank mit den Zeitreihen nicht erreichbar sein sollte, ist eine Suche in den
Metadaten dennoch möglich.
Die Informationen über Beginn und Ende einer Zeitreihe werden, nachdem die Daten
komplett in die Datenbank geschrieben wurden, über entsprechende Datenbankabfragen
ermittelt und in die dafür vorgesehenen Metadatenfelder eingefügt. Hierbei wird nicht das
erste und letzte vorhandene Datum, sondern das erste und letzte mit einem realen Wert in
der ersten Spalte verwendet. Damit werden Datenlücken am Anfang oder am Ende einer
Zeitreihe ignoriert, die keinerlei Informationsgehalt besitzen. Vor allem im Datenbestand
des Einzugsgebietes der Saale gibt es eine große Anzahl von Zeitreihen, die sowohl zu
Beginn als auch am Ende Datenlücken über mehrere Jahre hinweg aufweisen. Ein Beispiel
ist eine Zeitreihe über den Wasserstand in Weida, welche am 1.11.1922 beginnt, jedoch
erst ab dem 1.11.1970 Messwerte beinhaltet.
Abbildung 18: Lücken der Niederschlagszeitreihe Eich
50
4 Verwaltung und Interpolation von Zeitreihen in RBIS
4.3
Bereitstellung verschiedener Datenanalysemöglichkeiten
Der Datenbestand kann hinsichtlich verschiedener Aspekte analysiert werden. Im
Vordergrund steht hier der räumliche, inhaltliche und zeitliche Bezug zu anderen
Messreihen, der sich allein aus den Messwerten und Metadaten ableiten lässt und nicht die
statistische Analyse der Messwerte innerhalb einer Messreihe oder einer räumlichen
Analyse unter Verwendung von zusätzlichen Geodaten. Es sollen Fragestellungen, wie
'Wie weit ist die nächste Station, an der täglich Niederschlag gemessen wird, entfernt?'
oder 'An wie vielen Stationen im Umkreis von 20 km liegen Messwerte einer Messgröße in
einem bestimmten Zeitraum vor und welche dieser Zeitreihen hat die größte Ähnlichkeit
mit der Ausgangszeitreihe?' beantworten werden können. Weiterhin werden dem
fachkundigen Anwender zur Beurteilung des vorliegenden Datenbestandes
Entscheidungshilfen in der Form von Diagrammen und Tabellen zur Verfügung gestellt.
Bei der Umsetzung wurde versucht, nicht eigens für jede Fragestellung eine SQL-Abfrage
an die Datenbank zu formulieren, sondern mit möglichst wenigen konkret formulierten
Abfragen auszukommen und diese dynamisch den jeweiligen Anforderungen anzupassen.
Im Ergebnis wurde ein zentrales SQL-Abfragegerüst entwickelt, das sowohl den
Analysemöglichkeiten, als auch den benötigten Information mehrerer Interpolationsverfahren gerecht wird.
Zur grafischen Aufbereitung und Abfrage für den Endanwender wurde eine eigene
Benutzerschnittstelle erstellt (siehe Abbildung 20), die u. a. auch die Darstellung der
Lücken in einem Diagram beinhaltet (siehe Abbildung 21).
51
4 Verwaltung und Interpolation von Zeitreihen in RBIS
4.3.1
Allgemeine Funktionsweise und Voraussetzungen
Alle Funktionalitäten beruhen auf einem zentralen SQL-Abfragegerüst. Dieses besteht aus
mehreren Komponenten, die entweder zwingend oder optional eingesetzt werden. Der
Rückgabewert enthält immer Informationen über die selektierten Stationen und Zeitreihen.
Dazu gehören verschiedene IDs und Angaben, wie der Name oder die Höhe der Stationen.
Weiterhin wird immer die Distanz zwischen den einzelnen selektierten Stationen berechnet
und ausgegeben.
Es können nur Zeitreihen betrachtet werden, die einer Station zugeordnet sind, bei der
Koordinaten und das entsprechende Koordinatensystem vorliegen. Die Angabe des
Koordinatensystems wird für die Berechnung der Distanzen benötigt. Alle Zeitreihen, die
diese Kriterien nicht erfüllen, können demzufolge in die Abfrage nicht einbezogen werden.
Bei der Suche nach passenden Datensätzen, die beim Füllen der Lücken herangezogen
werden können, muss darüber hinaus der verwendete Zeitschritt und die Einheit
übereinstimmen. Um Fehler und Probleme mit nicht erkannten Fehlkennungen zu
vermeiden, zählt auch eine erfolgreiche Datenlückenanalyse für diese Zeitreihen zu den
Voraussetzungen (Dr_DataReliability.gapanalysis= true).
Die Distanzen werden berechnet um diejenigen Stationen zu finden, die in der Umgebung
der Ausgangszeitreihe liegen. Die Werte dieser Stationen werden häufig für eine
Interpolation herangezogen, da meist davon ausgegangen wird, dass diese der
Ausgangszeitreihe umso ähnlicher sind, je näher diese sich an der Ausgangszeitreihe
befinden.
Die Berechnung der Distanzen erfolgt unter der Verwendung von PostGIS-Funktionen, die
der Metadatendatenbank zunächst hinzugefügt wurden. PostGIS ist eine Erweiterung für
PostgreSQL um geografische Datentypen und Funktionen. Der Einsatz von PostGIS
ermöglicht zum einen die Verwendung von Koordinaten, die in unterschiedlichen
räumlichen Bezugssystemen vorliegen und zum anderen liefert es eine genauere
Berechnung der Distanz, da die jeweilige Projektion in die Berechnung mit einfließt. Das
räumliche Bezugssystem wird in PostGIS über eine SRID (spatial referencing identifier)
festgelegt. PostGIS ist durch die Verwendung der PROJ4 Bibliothek in der Lage,
Geometrieobjekte in jedes beliebige Bezugssystem zu projizieren (RAMSEY 2007). Im RBIS
wird das räumliche Bezugssystem bzw. die SRID über die Auswahl der UTM Zone-Grid
ID den Koordinaten zugeordnet. Bei der Berechnung der Distanz zwischen zwei Stationen
werden die Koordinaten zunächst in Text und dann mit der Funktion GeometryFromText() in
Geometrieobjekte umgewandelt. Anschließend werden die entstanden Geometrieobjekte in
ein einheitliches Bezugssystem gebracht (transform()). Erst jetzt kann die Distanz berechnet
werden, da für die PostGIS-Funktion distance() Geometrieobjekte im gleichen räumlichen
Bezugssystem verwendet werden müssen (RAMSEY 2007).
52
4 Verwaltung und Interpolation von Zeitreihen in RBIS
Werden nun zum Beispiel die fünf nächst gelegenen Zeitreihen bzw. Stationen gesucht, die
in einem bestimmten Zeitraum tägliche Niederschlagswerte gemessen in mm besitzen,
könnte die im Folgenden beschriebene SQL-Abfrage an die Datenbank gesendet werden.
Diese Abfrage entspricht ebenfalls einer SQL-Anweisung, wie sie im Rahmen des
Interpolationsverfahrens IDW mit 5 Stationen durchgeführt wird.
Das in Abbildung 19 dargestellt Beispiel beinhaltet die Abfrage über die Existenz von
Daten innerhalb einer Lücke der Zielstation, ausgehend von dieser Zielstation (Zeile 37)
und der gesuchten Messgröße (Zeile 38). Es werden alle Zeitreihen ausgeschlossen, die
entweder im gesuchten Zeitraum ebenfalls Lücken aufweisen (Zeile 40-45), oder deren
Werte generell nicht im gesuchten Zeitraum liegen (Zeile 46). Weitere Bedingungen sind,
dass alle Koordinaten und SRIDs gegeben sein müssen (Zeile 31-36). Auch die Einheiten
(Zeile 47) und Zeitschritte (Zeile 48) müssen übereinstimmen. Das Ergebnis ist nach der
Distanz aufsteigend sortiert (Zeile 49) und beinhaltet Informationen von 5 Datensätzen
(Zeile 50). Es wird unter anderem die Distanz (Zeile 3) und r² (Zeile 15) auf 2
Kommastellen gerundet zurückgegeben.
Das Ergebnis dieser SQL-Abfrage beinhaltet die 5 Zeitreihen bzw. Stationen die zum einen
in der gesuchten Zeit ebenfalls Niederschlagsdaten besitzen bzw. keine Lücken aufweisen
und zum anderen sich am nächsten an der Ausgangsstation befinden. Sie sind dabei nach
ihrer Entfernung zur Ausgangsstation sortiert. In Abbildung 22 ist das für den RBISBenutzer aufbereitete Ergebnis dargestellt.
Alle einzelnen Bestandteile dieser Abfrage werden dynamisch den jeweiligen
Anforderungen entsprechend zusammengestellt. Spielen zum Beispiel die Lücken keine
Rolle, so entfallen die Anweisungen der Zeilen 40 – 46. Ist auch der verwendete Zeitschritt
ohne Bedeutung entfällt der Inhalt der Zeile 48 ebenfalls.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
SELECT a.statname,
b.statname,
distance(transform(GeometryFromText('POINT(' || cast(a.latutm as
varchar(10)) || ' ' || cast(a.longutm as varchar(10)) || ')',a.srid ),
32632), transform(GeometryFromText('POINT(' || cast(b.latutm as
varchar(10)) || ' ' || cast(b.longutm as varchar(10)) || ')',b.srid ),
32632)),
ts.startdatetime,
ts.enddatetime,
citation.restitle,
b.md_metadata_id,
ts.md_metadata_id,
a.md_metadata_id,
ts.ts_timeser_id,
fp_featpar.featpar,
b.elevat,
ts.missing_value,
ts_desc.colnumber,
round((select rsquared FROM int_correlation where
int_correlation.fp_featpar_id = '12022017' and
(int_correlation.ts_timeser_id1 = 1297 and int_correlation.ts_timeser_id2 =
ts.ts_timeser_id ) or (int_correlation.ts_timeser_id2 = 1297 and
int_correlation.ts_timeser_id1 = ts.ts_timeser_id )),2)
53
4 Verwaltung und Interpolation von Zeitreihen in RBIS
16 FROM
17
ts_timeser ts_a LEFT JOIN
18
stat_ts stats_a ON ts_a.ts_timeser_id = stats_a.ts_timeser_id LEFT
JOIN
19
dsstation a ON stats_a.dsstation_id = a.dsstation_id
20
CROSS JOIN
21
dsstation b LEFT JOIN
22
stat_ts ON stat_ts.dsstation_id = b.dsstation_id LEFT JOIN
23
ts_timeser ts ON stat_ts.ts_timeser_id = ts.ts_timeser_id LEFT
JOIN
24
ts_description ts_desc ON ts.ts_timeser_id = ts_desc.ts_timeser_id
LEFT JOIN
25
fp_featpar ON ts_desc.fp_featpar_id = fp_featpar.fp_featpar_id
LEFT JOIN
26
metadata ON ts.md_metadata_id = metadata.md_metadata_id LEFT JOIN
27
dataidinfo ON metadata.md_metadata_id = dataidinfo.md_metadata_id
LEFT JOIN
28
ident ON dataidinfo.md_ident_id = ident.md_ident_id LEFT JOIN
29 citation ON ident.ci_citation_id = citation.ci_citation_id
30 WHERE
31
a.latutm is not null
32
and a.longutm is not null
33
and a.srid is not null
34
and b.latutm is not null
35
and b.longutm is not null
36
and b.srid is not null
37
and ts_a.ts_timeser_id = 1297
38
and ts_desc.fp_featpar_id = '12022017'
39
and ts.ts_timeser_id != 1297
40
and ts.ts_timeser_id not in
41
(SELECT ts_timeser.ts_timeser_id FROM ts_timeser LEFT JOIN
42
dr_datarelia ON ts_timeser.dr_datarelia_id =
dr_datarelia.dr_datarelia_id LEFT JOIN
43
datagapanalyses ON datagapanalyses.dr_datarelia_id
=dr_datarelia.dr_datarelia_id LEFT JOIN
44
dr_datagaps ON datagapanalyses. dr_datagaps_id =
dr_datagaps.dr_datagaps_id LEFT JOIN
45
ts_description ON ts_timeser.ts_timeser_id =
ts_description.ts_timeser_id WHERE ts_description.colnumber =
dr_datagaps.colnumber and ts_description.fp_featpar_id = '12022017' and
dr_datagaps.startgap between 728524800 and 733536000 or
dr_datagaps.endgap between 728524800 and 733536000 or
(dr_datarelia.gapanalysis = false or dr_datarelia.gapanalysis is null) )
46
and ts.startdatetime <= 728524800 and ts.enddatetime >= 733536000
47
and ts_desc.uom_units_id = (SELECT ts_description.uom_units_id FROM
ts_description WHERE ts_description.ts_timeser_id = 1297 and
ts_description.fp_featpar_id = '12022017')
48
and ts.uom_units_id = ts_a.uom_units_id
49 order by distance
50 LIMIT 5
Abbildung 19: Beispiel SQL-Abfrage für das in Abbildung 22 dargestellte Suchergebnis
54
4 Verwaltung und Interpolation von Zeitreihen in RBIS
4.3.2
Anwendung durch RBIS-Nutzer
Über einen Link gelangt der Anwender zu der Webseite, auf der verschiedene
Abfragemöglichkeiten angeboten werden. Diese beziehen sich immer auf eine ausgewählte
Messgröße einer Zeitreihe. In dem in Abbildung 20 dargestellten Beispiel ist dies der
Niederschlag von der Zeitreihe Niederschlag Frauensee, der an der Station Frauensee
aufgezeichnet wurde.
Abbildung 20: Benutzerschnittstelle mit Informationen über den Niederschlag an
der Station Frauensee und umliegende Stationen
Das in Abbildung 20 dargestellte Abfrageergebnis zeigt die 5 nächst gelegenen Stationen,
sortiert nach ihrem Abstand zur Ausgangszeitreihe bzw. Station, an denen zu einem
beliebigen Zeitpunkt ebenfalls Niederschlag gemessen wurde. Bei Eingabe einer
maximalen Distanz werden nur noch Stationen betrachtet, die sich innerhalb dieses
Umkreises um die Ausgangsstation befinden. Bei der Eingabe der Zahl Null wird die
55
4 Verwaltung und Interpolation von Zeitreihen in RBIS
Distanz, so wie in dem Beispiel in Abbildung 20, nicht in die Suche einbezogen. Durch die
Eingabe eines Startdatums und/oder eines Enddatums wird bei der Abfrage entsprechend
das Start- und/oder Enddatum der Zeitreihen einbezogen. An dieser Stelle wird der Vorteil
der Verwendung des ersten tatsächlich vorhandenen Wertes bei den Metadaten einer
Zeitreihe deutlich, da hier von vornherein Zeitreihenbestandteile ausgeblendet werden
können, die keinen verwendbaren Informationsgehalt besitzen. Vorhandene Lücken
innerhalb der Zeitreihen werden bei dieser Suchanfrage nicht beachtet. Mit der Angabe
einer minimalen oder maximalen Höhenangabe kann ebenfalls die Auswahl der Stationen
gesteuert werden.
Eine weitere Möglichkeit der Manipulation des Suchergebnisses besteht mit der Angabe
eines minimalen Bestimmtheitsmaßes r², das den Zusammenhang der Werte zweier
Zeitreihen beschreibt. Die Sortierung und Einschränkung nach dem Bestimmtheitsmaß
funktioniert jedoch nur dann korrekt, wenn zuvor r² für alle in Frage kommenden
Zeitreihen ermittelt wurde. Aus diesem Grund sollte immer vor der Verwendung dieser
Funktion eine Aktualisierung der Werte durchgeführt werden (update calculation of r²).
Diese Funktion berechnet r² für alle Zeitreihenpaarungen mit der Ausgangszeitreihe, die
seit der letzten Durchführung hinzugekommen sind.
Im dargestellten Beispiel lässt sich erkennen, dass die Zeitreihendaten von Frauensee und
Springen offensichtlich identisch sind und auch der Gesamtzeitraum (1.1.1969 - 30.6.1993)
übereinstimmt. Dies ist ein Anzeichen für einen Fehler beim Importieren der
Zeitreihendaten. Auch die Ansicht der Lückenverteilung als Diagramm (Abbildung 21)
unterstützt diese Vermutung, da hier deutlich zu erkennen ist, dass auch die vorhanden
Lücken übereinstimmen.
Abbildung 21: Darstellung der Lücken für zuvor ausgewählte Stationen
56
4 Verwaltung und Interpolation von Zeitreihen in RBIS
Die Darstellung der Lücken in einem Diagramm ist für alle Zeitreihen möglich (show plot),
die im Suchergebnis enthalten sind, solange es weniger als 9 sind. Die roten Balken
markieren die Zeiträume, in denen keine Daten vorliegen. Die Sichtbarkeit kleiner
Datenlücken ist vom Gesamtzeitraum abhängig. Wird eine detailliertere Ansicht benötigt,
muss der Zeitraum zuvor eingeschränkt oder die Information müssen direkt bei den
Metadaten ermittelt werden.
Abbildung 22: Abfrageergebnis für das Lückenintervall vom 1.2.1993 bis
31.3.1993 der Zeitreihe „Niederschlag Frauensee“
Neben der graphischen Darstellung der Lücken gibt es auch die Möglichkeit, sich diese
und die Zeitreihen, die in dem entsprechenden Zeitraum verwertbare Daten besitzen,
tabellarisch darstellen zu lassen (Abbildung 22). Im Gegensatz zur allgemeinen Suche
fließen hier die Informationen über die Datenlückenintervalle zusätzlich zu den einmal
festgelegten Randbedingungen mit ein. Außerdem muss der Zeitschritt und die Einheit mit
der Ausgangszeitreihe übereinstimmen. Die Zeitreihen, die nun angezeigt werden, besitzen
in dem gesuchten Zeitraum keine Datenlücken und können ohne weitere zusätzliche
Prüfung in Interpolationsverfahren verwendet werden. Die SQL-Abfrage an die
Datenbank, die dazu ausgeführt wird, hat den gleichen Aufbau wie in dem Beispiel im
vorherigen Abschnitt dargestellt.
57
4 Verwaltung und Interpolation von Zeitreihen in RBIS
4.4 Implementierung und Anwendung verschiedener
Interpolationsverfahren
Nach einer erfolgreichen Datenlückenanalyse gilt es nun die identifizierten Lücken mit
einem Interpolationsverfahren zu schließen. Im Vordergrund steht an dieser Stelle weniger
die Umsetzung möglichst vieler verschiedener Interpolationsverfahren, sondern vielmehr
die Schaffung einer Struktur, die es erlaubt, diese zu verwalten, möglichst automatisch
anzuwenden und einen abgeschlossenen Interpolationsvorgang zu dokumentieren. Zur
Dokumentation des Vorgangs gehört u. a. der Zeitpunkt, das verwendete Verfahren und
alle einbezogenen Zeitreihen, die darüber hinaus für den Nutzer einsehbar sein sollten. Bis
zu einem gewissen Grad soll damit die Reproduzierbarkeit der berechneten Werte
gewährleistet werden. Generell stellt sich die Frage nach dem Wie und Wann und der Art
der Interpolationsverfahren, die ausgewählt werden sollen. In vielen wissenschaftlichen
Arbeiten wird der Versuch unternommen, für eine konkrete Fragestellung das geeignetste
Verfahren für einen Interpolationsvorgang anhand von Beispieldatensätzen zu finden. Das
Ergebnis ist jedoch immer stark von der jeweiligen Stationsdichte, dem betrachteten
Zeitschritt, den Eigenschaften des Einzugsgebietes und der Zielstellung abhängig. Aus
diesem Grund wurde hier keine feste Zuordnung zwischen Verfahren und Messwert
festgelegt. Der fachkundige Nutzer kann ein oder mehrere Verfahren auswählen.
Zusätzlich können Regeln festgelegt werden, welche die Anwendung bzw. den
Anwendungsbereich der Verfahren steuern.
Für die Verwaltung der Daten war es zunächst notwendig, entsprechende Ergänzungen im
Datenmodell der Metadaten vorzunehmen. Nicht nur auf der Seite der Metadaten, sondern
auch bei den Zeitreihendaten wurde ein Verfahren zur Speicherung und Verwaltung der
interpolierten Werte entwickelt. Beide werden im nächsten Unterabschnitt vorgestellt. Im
Anschluss wird der vollständige Ablauf eines Interpolationsvorgangs und die
Beschreibung der implementierten Interpolationsverfahren sowohl aus der technischen
Sicht, als auch aus der Sicht des Anwenders beschrieben. Die Anwendung durch den
Nutzer ist Inhalt des darauf folgenden Teilabschnittes.
4.4.1
Datenmodell und Datenhaltung
Für die Speicherung der Metadaten musste das Datenmodell der Metadaten erweitert
werden. Im Folgenden soll die Erweiterung für die Interpolation anhand des konzeptionellen Datenmodells kurz vorgestellt werden. In den nachfolgenden Abschnitten werden
viele der hier kurz angerissenen Funktionalitäten und ihre Anwendung näher beschrieben.
Neben den Anpassungen auf der Seite der Metadaten musste auch eine flexible und
einfache Form der Datenhaltung für die berechneten Werte in der Zeitreihendatenbank
entwickelt werden. Dabei wurde darauf geachtet, dass Originaldaten nicht verändert
werden und somit die Datenhaltung der berechneten Werte getrennt von diesen erfolgt.
58
4 Verwaltung und Interpolation von Zeitreihen in RBIS
4.4.1.1
Datenmodell für die Metadaten
Im Mittelpunkt steht die Entity Interpolation (Abbildung 23). Es stellt die Verknüpfung zu
den anderen Modulen her und ist im übertragenen Sinne der Ausgangspunkt eines jeden
Interpolationsvorgangs. Jeder Interpolationsvorgang erhält eine eindeutige ID
(int_interpolation_id) und entsprechende Metadaten wie das Datum (date), die ID der
interpolierten Zeitreihe und Spalte (ts_timeser_id, colnumber) ebenso wie Informationen
über die Vollständigkeit (complete) und die Möglichkeit einer Beschreibung, welche z. B.
für die Speicherung von Fehlerinformationen genutzt werden kann.
Abbildung 23: Konzeptionelles Datenmodell: Interpolation und Interpolationsvorgang
59
4 Verwaltung und Interpolation von Zeitreihen in RBIS
Weiterhin ist mit diesem Entity die verwendete Methodenkombination verknüpft
(Interpolation Method Set). Diese beschreibt einen definierten Satz an Regeln (Method Set
List), wie die einzelnen Interpolationsverfahren (Interpolation Method) angewendet
werden. Die Anwendung und Konfiguration durch den Nutzer wird in Abschnitt 4.4.3
beschrieben. Für eine automatische Auswahl einer Methodenkombination ist die
Zuweisung einer Defaultkombination vorgesehen (Default Method Set). Dies wurde jedoch
zum gegenwärtigen Zeitpunkt noch nicht umgesetzt. Interpolationsverfahren selbst
besitzen neben einer ID, einen Namen und eine Beschreibung. Weiterhin ist vorgesehen,
dass eine Aussage darüber getroffen werden kann, ob das beschriebene Verfahren im RBIS
implementiert ist oder nicht (implemented). Erfolgte die Interpolation eines
Lückenintervalls erfolgreich, so werden dem Entity Filled gap information die
entsprechenden Datenlücken, das jeweils verwendete Verfahren sowie der aktuelle
Interpolationsvorgang zugeordnet. Das Entity Filled gap information (used TS) stellt eine
Verknüpfung zwischen dem Interpolationsvorgang, der Lücke und den jeweils zum
Schließen der Lücke verwendeten Zeitreihen her. Die Rückkopplung zwischen einem
Interpolationsvorgang mit der jeweiligen Spalte der Zeitreihe erfolgt über die
Vorgangsnummer (int_interpolation_id), die dort der entsprechenden Messgröße
zugewiesen wird (zu TS_Description). Damit wird eine Suche von einer Zeitreihe
ausgehend und auch in Bezug auf ihre Verwendung beim Schließen von Lücken
vereinfacht. Die in Abbildung 23 als völlig unabhängig von allen anderen dargestellten
Entities Correlation und Limit values sind in Wirklichkeit entsprechend ihrer Attribute
ebenfalls abhängig. Auf die Darstellung dieser Beziehungen wurde aus Gründen der
Übersichtlichkeit verzichtet. Correlation enthält das Bestimmtheitsmaß r² (rsquared), das
sich aus den Werten der gleichen Messgrößen zweier Zeitreihen berechnet und den
Zusammenhang dieser beschreibt. Mit Limit values werden die Grenzwerte für die
Korrektur unrealistischer Interpolationsergebnisse verwaltet (siehe Abschnitt 4.4.2.4).
Im physischen Datenmodell enthalten alle Tabellennamen das Präfix int_, so dass
einerseits diese Tabellen eindeutig ihrer Funktion bzw. ihrem Modul zugeordnet werden
können. Anderseits stehen bei einer alphabetischen Sortierung diese Tabellen immer
zusammen, so dass die Navigation für den Datenbankadministrator erheblich vereinfacht
wird.
4.4.1.2
Speicherung der berechneten Werte
Die berechneten Werte werden in einer eigenen Tabelle in der Zeitreihendatenbank
abgespeichert, so dass die Daten getrennt von den Originaldaten gehalten werden. Diese
Tabelle wird angelegt, sobald Daten für identifizierte Lücken vorliegen. Dabei spielt es
keine Rolle, welchen Ursprung diese Werte haben (näheres über die verschiedenen
Varianten in Abschnitt 4.4.3). Der Name der Tabelle setzt sich aus calc_ und der ID der
Zeitreihe zusammen. Die Tabelle selbst besteht immer aus den drei Spalten timestamp
60
4 Verwaltung und Interpolation von Zeitreihen in RBIS
(Datum), value1 (Wert) und colnumber (Spaltennummer der dazugehörigen Daten in der
Originaldatentabelle) zusammen (Abbildung 24). Diese Aufteilung ermöglicht die
Speicherung aller aufgefüllten Werte in einer Tabelle, egal zu welcher Spalte sie in den
Originaldaten gehören. Dies soll verhindern, dass zu viele neue Tabellen angelegt werden,
wie das etwa bei einer Gewässergütezeitreihe mit 65 Messparametern der Fall sein könnte.
Abbildung 24: Beispiel für Tabelle (calc_504) mit berechneten Werten
Die Realisierung des Zugriffs auf die Daten über Views wird im Abschnitt 4.5.1 im
Zusammenhang mit dem Export der Daten näher erläutert.
4.4.2
Interpolationsvorgang und technische Umsetzung
Bei der Realisierung stellten sich eine Reihe von Problemen und Fragen. Zunächst galt es,
grundlegende Entscheidungen zu treffen, wie die Wahl der Ansätze für die Berechnungen,
auf die in Abschnitt 4.4.2.1 eingegangen wird. Anschließend wurden die in Abschnitt
4.4.2.3 beschriebenen Interpolationsverfahren einzeln umgesetzt und getestet. Bei der
darauf folgenden Einbettung in einen Interpolationsvorgang wurden diese weitestgehend
standardisiert und alle redundanten Bestandteile in eigene Funktionen ausgelagert. Für die
Anwendung der Interpolationsverfahren wurde ein regelbasierters Verfahren
implementiert. Hier ist es möglich spezifische Parameter der Interpolationsverfahren
anzugeben und diese auch beliebig zu ändern. Weiterhin können verschiedene Verfahren
miteinander kombiniert werden. Eine der größten Herausforderungen bei der
Zusammenstellung der SQL-Anweisungen stellte der zusammengesetzte Primärschlüssel
der einzelnen Spalten einer Zeitreihe dar. Zu einem Problem wird dies vor allem bei der
Verwendung in Unterabfragen (Subselects) in SQL-Anweisungen, da diese immer nur
einen Wert zurück liefern können. Auch der zusammengesetzte Primärschlüssel stellt
selbst eine potentielle Fehlerquelle dar. Beim Zeitschritt wurde immer von täglichen
Werten ausgegangen. Dies soll auch zunächst beibehalten und erst später um weitere
Zeitschritte ergänzt werden. Der Grund hierfür ist, dass verschiedene Zeitschritte als
zusätzliche Fehlerquelle vorerst ausgeschlossen werden sollen.
61
4 Verwaltung und Interpolation von Zeitreihen in RBIS
4.4.2.1
Berechnungsansatz
Bei der Umsetzung der Interpolationsverfahren bzw. der Berechnungen standen
grundsätzlich verschiedene Möglichkeiten zur Wahl. Die Berechnungen können
vollständig auf der Seite der Anwendung durchgeführt werden, d. h. alle benötigten Daten
werden ausgelesen und die Berechnungen finden ausschließlich außerhalb der Datenbank
statt. Diese Variante verursacht allerdings ein sehr großes Datenvolumen, welches
zwischen Anwendung und Datenbank ausgetauscht werden muss. Außerdem müssen hier
einige Funktionen, die in einem DBMS zur Verfügung stehen, erst auf der Seite der
Anwendung umgesetzt werden. Viele Programme, die Interpolationsverfahren für das
Schließen von Lücken in hydrologischen Zeitreihen anbieten, arbeiten auf der Basis von
Dateien, wodurch sich diese Problematik erst gar nicht ergibt. Eine weitere Variante
besteht darin, in der Datenbank gespeicherte Prozeduren (stored procedures) oder
Funktionen (user defined functions) anzulegen um somit fast alle Berechnungsvorgänge
direkt vom DBMS ausführen zu lassen. Diese Variante minimiert das Datenvolumen, das
zwischen Anwendung und DBMS ausgetauscht werden muss. Andererseits schränkt diese
Lösung die Flexibilität stark ein und ist nicht vom DBMS unabhängig. Auch das generelle
Problem, dass zur Berechnung fast immer sowohl auf die Metadatendatenbank und auf die
Zeitreihendatenbank zugegriffen werden muss und keine integrierten Abfragen an das hier
verwendete DBMS PostgreSQL gestellt werden können, kann damit nicht auf einem
einfachen Weg gelöst werden. Umfangreiche und möglichst flexible Funktionalitäten
komplett in die Datenbank zu verlegen, erscheint somit in der Implementierung recht
aufwendig. Einen ähnlichen Ansatz verfolgte auch Leonore ZINK (2000) in ihrer Arbeit
über die Einbettung von Interpolationsfunktionen in die Datenbanksprache SQL. Hier
wurde eine eigene Spracherweiterung für SQL entwickelt, die es ermöglicht, ausgewählte
Interpolationsverfahren direkt mit SQL aufzurufen und Parameter wie z. B. den Zeitschritt
für die Durchführung mitzugeben. Über die Weiterentwicklung des Prototypen ist nichts
bekannt.
Für die Umsetzung für das RBIS wurde die im Folgenden beschriebene Lösung gewählt.
Auf der Seite der Anwendung, die in PHP geschrieben ist, werden SQL-Anweisungen die
die Berechnungsvorschriften enthalten dynamisch zusammengestellt, so dass alle
Berechnungsvorgänge auf der Seite der Datenbank vom DBMS durchgeführt werden. Auf
diese Art und Weise können auch Zwischenergebnisse berechnet werden, die dann in die
Hauptberechnung integriert werden können. Endergebnisse eines Interpolationsvorgangs
werden nicht an die Anwendung zurückgegeben, sondern gleich direkt in der Datenbank
abgespeichert. Dadurch wird nur ein sehr geringes Datenvolumen zwischen Anwendung
und Datenbank ausgetauscht, welches sich im wesentlichen auf Anfragen selbst, die
Metadaten und Zwischenergebnisse beschränkt. Ein entscheidender Vorteil dieser Lösung
besteht darin, dass Aggregatfunktionen in SQL wie sum(), avg(), count(), max() oder min()
in Kombination mit einer from- und where-Klausel verwendet werden können. Dies ist
62
4 Verwaltung und Interpolation von Zeitreihen in RBIS
u. a. dann wichtig, wenn Fehlkennungen verwendet wurden oder Nullwerte auftreten.
Beispiele sind die Berechnung des Mittelwerts, der unter der Verwendung von
Fehlkennungen (z. B. -9999) einen falschen Wert liefern würde oder die Abfrage der
Anzahl der Werte, da mit count(*) alle Nullwerte einbezogen werden, bei allen übrigen
Aggregatfunktionen werden jedoch Nullwerte ignoriert (HEUER & SAAKE 2000:369).
Werden Join-Bedingungen in die Abfrage mit einbezogen, so ergeben sich hier viele
Möglichkeiten, auf eine einfache Art und Weise bestimmte Werte zu berechnen. Wie zum
Beispiel den jeweiligen Mittelwerten der Werte von zwei Zeitreihen aller
übereinstimmenden Zeitstempel, die nicht Null sind oder der Fehlkennung entsprechen.
Neben den Fehlkennungen spielt auch der Nullwert eine besondere Rolle. In skalaren
Ausdrücken ist das Ergebnis Null, wenn ein Nullwert in die Berechnung eingeht (HEUER &
SAAKE 2000:369). Dieses Verhalten eignet sich besonders gut, um Fehler bei der
Zusammenstellung der Berechnungsvorschrift oder im Endergebnis zu erkennen. Eine
Umsetzung mit PHP aller oder eines Teils der eben genannten Funktionen in der
Anwendung hätte viele ineinander geschachtelter Schleifen bedurft und wäre vermutlich
schnell unübersichtlich geworden. Ein weiterer Vorteil gegenüber einer Lösung in PHP ist
die geringere Wahrscheinlichkeit von Typinkompabilitäten, da im Vergleich zu PHP keine
automatische Typkonvertierung stattfindet.
4.4.2.2
Umsetzung und Ablauf von Interpolationen
Für alle Funktionen, die direkt oder indirekt mit einem Interpolationsvorgang verbunden
sind, wurde eine neue Klasse (Interpolation) in der Datei Interpolation.class.php angelegt.
Dabei wurde darauf geachtet Redundanzen zu vermeiden, die Wartbarkeit,
Übersichtlichkeit und Wiederverwendbarkeit das Quellcodes zu erhöhen und die
Fehleranfälligkeit zu reduzieren. Es entstanden eine Vielzahl von Funktionen, die für die
Erzeugung der Sichten benötigt werden (show_...), Werte berechnen (calc_...), Variablen
aus der Datenbank auslesen (get_...), Informationen in die Datenbank schreiben (write_...
oder create_...), ändern (update_...) oder löschen (delete_...). Ebenfalls gibt es Funktionen,
die SQL-Anweisungen erzeugen (create_query...).
Im Mittelpunkt eines Interpolationsvorgangs steht die Funktion interpolation_set()
(Quellcode im Anhang C - Abbildung 37), deren Ablauf am Ende dieses Abschnitts
dargestellt ist. Sie wird über die Anwendung in dem Moment gestartet, wenn der Nutzer
die Interpolation startet (siehe Abschnitt 4.4.3). Zu diesem Zeitpunkt sind lediglich die IDs
der Zielzeitreihe, Messgröße und Methodenkombination bekannt bzw. wurden übergeben.
Nach der Herstellung der Datenbankverbindung (Schritt 3) wird die verwendete
Fehlkennung (Schritt 4) und die Spaltennummer (Schritt 5) abgefragt, in dem sich die
Daten der Messgröße befinden. Diese Informationen sind essentiell, da der Zugriff auf die
Daten ausschließlich über die Spaltennummer und die Zeitreihen-ID erfolgt.
63
4 Verwaltung und Interpolation von Zeitreihen in RBIS
Im nächsten Schritt (Schritt 6) wird der Interpolationsvorgang erzeugt und die
entsprechende Vorgangsnummer (ID) abgefragt. Diese wird später für die Zuordnung
einzelner Aktionen benötigt. Anschließend wird in der Zeitreihendatenbank, falls noch
nicht vorhanden, die Tabelle für die berechneten Werte und der entsprechende View dazu
angelegt (Schritt 7). Weiterhin werden die Lückeninformationen (Schritt 8), bestehend aus
ID, Länge, Start und Ende sowie die Daten der Methodenkombination (Schritt 9)
(Verfahren, Position und Grenzwerte) aus der Metadatendatenbank gelesen.
Der folgende Schritt (Schritt 10) umfasst spezielle Vorbereitungen, die vor der Ausführung
der nach der gegebenen Methodenkombination potentiell möglichen Verfahren notwendig
sind. Diese müssen nur einmal, egal wie oft ein Verfahren zum Einsatz kommt, durchgeführt werden. Handelt es sich um die lineare Interpolation, muss das verwendete Zeitintervall in Sekunden ermittelt werden. Eine lineare Regression benötigt die Berechnung
der fehlenden Korrelationskoeffizienten zu den nächsten Stationen mit der gleichen
Messgröße, Einheit, Zeitschritt und erfolgreicher Lückenanalyse sowie eine Abfrage von
Metadaten und Grundparametern für die Ausgangszeitreihe. Die Verfahren IDW und
Nächster-Nachbar erfordern ebenfalls die Grundparameter der Ausgangszeitreihe.
Im Anschluss (Schritt 11) erfolgt die Suche nach einem passenden Verfahren für jedes
Lückenintervall den gegebenen Regeln folgend. Die Aufstellung der Regeln durch den
Nutzer wird in Abschnitt 4.4.3 beschrieben. Die Reihenfolge ihrer Anwendung richtet sich
nach der jeweiligen Positionsangabe der Interpolationsverfahren. Bei der Suche nach
einem Verfahren wird das Kriterium der maximalen Länge der Lücke als erstes geprüft.
Erst wenn dieses Kriterium erfüllt wurde (d. h. die Länge der aktuellen Lücke ist kleiner
als der angegebene Grenzwert), werden die anderen Grenzwerte für die Anzahl der
Stationen, r² und die Distanz abgefragt. Bei erfolgreichem Verlauf wird ein
Interpolationsverfahren aufgerufen. Aspekte zur Umsetzung der einzelnen
Interpolationsverfahren werden in Abschnitt 4.4.2.3 behandelt. Lag einer der
Vergleichswerte außerhalb der Grenzwerte, so wird mit den Grenzwerten des Verfahrens
an der nächsten Position gesucht. Wird auch hier kein passendes Verfahren gefunden, wird
nach Möglichkeit eine Fehlermeldung für die Beschreibung des Vorgangs erzeugt.
Der Rückgabewert jedes implementierten Interpolationsverfahrens (Beispielquellcode im
Anhang C - Abbildung 36) besteht immer aus einer SQL-Anweisung als INSERT mit der
Berechnungsvorschrift, sowie die INSERT- Anweisungen für die Metadaten über das
verwendete Interpolationsverfahren und die verwendeten Zeitreihen (Schritt 12). Diese
SQL-Anweisungen werden für jedes Lückenintervall erzeugt und in einem String
aneinander gefügt. Erst nach der Abarbeitung aller Lücken werden diese Anweisungen
komplett an die entsprechenden Datenbanken abgeschickt (Schritt 15/16). Das hat den
großen Vorteil, dass diese dann jeweils als eine Transaktion von der Datenbank ausgeführt
werden. Schlägt auch nur eine dieser SQL-Anweisungen bei einer der beiden Datenbanken
(Metadaten/ Zeitreihen) fehl, so werden alle anderen auch nicht ausgeführt.
64
4 Verwaltung und Interpolation von Zeitreihen in RBIS
Vor der Ausführung der Berechnungen werden alle alten Ergebnisse gelöscht, die zu den
aktuellen Lücken gehören (Schritt 14). Abschließend werden die berechneten Werte
korrigiert (näheres dazu in Abschnitt 4.4.2.4.) (Schritt 17) und die Information über den
Erfolg oder Misserfolg und die Beschreibung der aufgetretenen Fehler zu den Metadaten
des Interpolationsvorgangs hinzugefügt (Schritt 18).
Algorithmus eines Interpolationsvorgangs:
Zusammenstellung einer Methodenkombination (Eingabe von Benutzer)
Auswahl der Methodenkombination (Eingabe von Benutzer)
Datenbankverbindung herstellen
Abfrage der verwendeten Fehlkennung
Abfrage der Spaltennummer der zu schließenden Zeitreihe
Schreiben von Informationen über den Interpolationsvorgang (Erzeugung einer
Vorgangsnummer)
7. Anlegen von Tabelle und View für die berechneten Werte in der Datenbank
8. Abfrage der Lückeninformationen
9. Einlesen der Parameter der ausgewählten Methodenkombination
10. Vorbereitung:
● lineare Interpolation: Abfrage Zeitintervall in Sekunden
● lineare Regression: Berechnung der fehlenden Korrelationskoeffizienten
entsprechend der doppelten gegebenen Anzahl an Stationen mit der gleichen
Messung, Einheit, Zeitschritt und erfolgreicher Lückenanalyse und Abfrage
von Metadaten und Grundparametern für die Ausgangszeitreihe.
● IDW und nächster Nachbar: Abfrage von Metadaten und Grundparametern
für die Ausgangszeitreihe.
11. Durchsuchen der Methodenkombination nach passender Methode für jedes
einzelnes Lückenintervall
12. Zusammenstellung und Berechnung einzelner Komponenten für die Berechnung
13. Prüfen ob ein Verfahren erfolgreich ausgewählt werden konnte - bei Misserfolg
werden die entsprechenden Informationen zu den Metadaten geschrieben
14. Löschen aller bisherigen Berechnungsergebnisse
15. Ausführen der Abfragen zur Erzeugung des Berechnungsergebnisses
16. Ergänzen des verwendeten Verfahrens zu jedem einzelnen Lückenintervall
17. Überprüfen und Korrigieren der Ergebnisse zur Einhaltung von Minimal- und
Maximalwerten
18. Ergänzen von Metainformationen über den Interpolationsvorgang
19. Ausgabe der Informationen über den Interpolationsvorgang
1.
2.
3.
4.
5.
6.
4.4.2.3
Implementierte Interpolationsverfahren
Es wurde das Nächste-Nachbar-Verfahren, die lineare Interpolation, die lineare
Regression, die Inverse Distanzwichtung und die Inverse Distanzwichtung mit Höhenkorrektur implementiert. Jedes Verfahren wird innerhalb einer Funktionen ausgeführt. Die
benötigten Übergabewerte sind im Aufbau sehr ähnlich oder gleich. Als Rückgabewert
wird immer ein Array (queries[]) geliefert, dass zum einen die INSERT-Anweisung mit
den Berechnungen und zum anderen die INSERT-Anweisungen für die Metadaten sowie
die Information über Erfolg (true) oder Misserfolg (false) bei der Zusammenstellung
65
4 Verwaltung und Interpolation von Zeitreihen in RBIS
enthält. Werden weitere Verfahren implementiert, muss der Rückgabewert lediglich
ebenso aufgebaut sein. Dies könnte auch statt einer INSERT-Anweisung eine Liste von
INSERT-Anweisungen mit Werten (ohne Berechnung) beinhalten, die an andere Stelle
schon berechnet wurden. Die implementierten Verfahren greifen alle auf die gleiche
Funktion zurück, die bei der Bereitstellung verschiedener Datenanalysemöglichkeiten in
Abschnitt 4.3 bereits vorgestellt wurde. Je nach gewünschter Information werden die
Parameter entsprechend übergeben. Durch die Verwendung der gleichen Funktion im
Hintergrund ist das Ergebnis bei gleicher Parameterkombination auf jeden Fall identisch.
Die Steuerung der Interpolationsverfahren erfolgt über Regeln, die in einer
Methodenkombination angegeben werden. Hierbei können Werte für die Parameter Länge
der Datenlücke, maximale und minimale Stationsanzahl, r² und maximaler Distanz
angegeben werden. Die maximale Distanz entspricht hierbei genau der gleichen
maximalen Distanz wie bei der Suche nach umliegenden Stationen (siehe Abschnitt 4.3).
Die maximale und minimale Anzahl der Stationen entspricht der Anzahl der zu suchenden
Zeitreihen.
Nächster-Nachbar-Verfahren (nearest neighbour)
Die Umsetzung des Nächster-Nachbar-Verfahrens basiert auf der Suche nach der
geografisch am nächsten gelegenen Station, an der Messwerte für den gesuchten Zeitraum
vorhanden sind. Der Radius der räumlichen Suche kann durch die Angabe einer
maximalen Distanz beschränkt sein. Weitere Einschränkungskriterien gibt es nicht.
Das Verfahren übernimmt die Werte der ermittelten Quellstation, ohne diese zu verändern.
Die INSERT-Anweisung lautet:
insert into calc_1297
(select ref_86400.timestamp, ts_1649.value1 , 1
from ts_1649 RIGHT OUTER JOIN ref_86400 ON ref_86400.timestamp =
ts_1649.timestamp
where ref_86400.timestamp between 728524800 and 733536000);
Lineare Interpolation (linear interpolation)
Bei der linearen Interpolation ist die Suche nach umliegenden Stationen nicht erforderlich.
Die Entfernung, maximale und minimale Schwellwerte für Stationen bzw. r² haben keinen
Einfluss auf das Verfahren bzw. das Ergebnis. Der wichtigste Parameter ist die maximale
Länge der Lücke.
Bei der Berechnung werden Vorgänger und Nachfolger in Bezug auf das Lückenintervall
ermittelt und daraus die Parameter der Geraden, welche durch diese beiden Wertepaare
(Wert und Datum) verläuft. Diese werden dann bei der Berechnung der fehlenden Werte in
die Gleichung zur Berechnung der Zielwerte eingesetzt. Bei der Verwendung von UNIXZeit in einer Berechnung ist es immer erforderlich, das Format von bigint in float
umzuwandeln. Beispiel einer fertigen SQL-Anweisung:
66
4 Verwaltung und Interpolation von Zeitreihen in RBIS
insert into calc_1297
(select ref_86400.timestamp, 253.500000000000000039321600 +
-0.000001556513409961685824 * cast(ref_86400.timestamp as float), 1
from ts_1297 RIGHT OUTER JOIN ref_86400 ON ref_86400.timestamp =
ts_1297.timestamp
where ref_86400.timestamp between 160444800 and 162777600);
Inverse Distanzwichtung (IDW)
Bei der inversen Distanzwichtung werden die Stationen ermittelt, die am nächsten gelegen
sind und über Daten im gesuchten Zeitraum verfügen. Dabei entspricht der maximale
Grenzwert der gewünschten Anzahl an Stationen, die in die Berechnung einfließen sollen.
Wird diese Anzahl an Stationen nicht gefunden, so werden alle Ergebnisse bis zu der
Anzahl des minimalen Grenzwertes akzeptiert. Der maximale Suchradius wird durch die
maximale Distanz bestimmt.
Für die Umsetzung werden die Distanzen zwischen der Zielstation und den Quellstationen
benötigt. Diese gehen als Gewichte für jeden Wert in die Berechnung ein. Das Beispiel
zeigt IDW mit fünf Stationen:
insert into calc_1297
(select ref_86400.timestamp, ( ts_1649.value1 /4387.19^2 +
ts_1549.value1 /6937.98^2 + ts_1269.value1 /8204.52^2 +
ts_1308.value1 /10384.56^2 + ts_1631.value1 /11122.68^2 )
/(1.04941583612E-07 ), 1
from ts_1649 RIGHT OUTER JOIN ts_1549 ON ts_1649.timestamp =
ts_1549.timestamp RIGHT OUTER JOIN ts_1269 ON ts_1549.timestamp =
ts_1269.timestamp RIGHT OUTER JOIN ts_1308 ON ts_1269.timestamp =
ts_1308.timestamp RIGHT OUTER JOIN ts_1631 ON ts_1308.timestamp =
ts_1631.timestamp RIGHT OUTER JOIN ref_86400 ON ref_86400.timestamp =
ts_1631.timestamp
where ref_86400.timestamp between 728524800 and 733536000);
Inverse Distanzwichtung mit Höhenkorrektur (IDW & elevation correction)
Bei der inversen Distanzwichtung mit Höhenkorrektur werden ebenfalls die umliegenden
Stationen mit verfügbaren Daten gesucht. Der Maximal- sowie der Minimalwert haben die
gleiche Funktion wie bei IDW ohne Höhenkorrektur.
Bei der Umsetzung wurde ebenfalls versucht alle Berechnungen auf der Seite der
Datenbank zu realisieren. Diese Maßgabe führte zu einer recht aufwendigen
Implementierung gegenüber einer möglichen Umsetzung in PHP. Da für die Korrektur der
Quellwerte entsprechend ihrer Höhenlage viele Zwischenergebnisse benötigt werden, wird
eine temporäre Tabelle angelegt. Diese entspricht einer realen Tabelle, die nach
Beendigung des Berechnungsvorgangs gelöscht werden muss. In ihr werden der
Zeitstempel, die Werte und die Höhen der Quellstationen sowie der Mittelwert der Werte
als auch der Höhen eingefügt.
67
4 Verwaltung und Interpolation von Zeitreihen in RBIS
CREATE TABLE temp_113312812 as
select ref_86400.timestamp, (ts_1649.value1 + ts_1549.value1 +
ts_1269.value1 + ts_1308.value1 + ts_1631.value1 + 0.0) /(5) as
avg_val, (236 + 265 + 225 + 210 + 275 + 0.0) /(5) as avg_elevat ,236
as elevat_0 ,265 as elevat_1 ,225 as elevat_2 ,210 as elevat_3
,275 as elevat_4 , ts_1649.value1 as value_0 , ts_1549.value1 as
value_1 , ts_1269.value1 as value_2 , ts_1308.value1 as value_3 ,
ts_1631.value1 as value_4
from ts_1649 RIGHT OUTER JOIN ts_1549 ON ts_1649.timestamp =
ts_1549.timestamp RIGHT OUTER JOIN ts_1269 ON ts_1549.timestamp =
ts_1269.timestamp RIGHT OUTER JOIN ts_1308 ON ts_1269.timestamp =
ts_1308.timestamp RIGHT OUTER JOIN ts_1631 ON ts_1308.timestamp =
ts_1631.timestamp RIGHT OUTER JOIN ref_86400 ON ref_86400.timestamp
= ts_1631.timestamp
where ref_86400.timestamp between 728524800 and 733536000;
Das Ergebnis dieser CREATE-Anweisungen ist in Abbildung 25 dargestellt.
Abbildung 25: Temporäre Tabelle (temp_113312812) mit dem Zeitstempel
(timestamp), den Mittelwerten der Werte (avg_val) und der Höhe
(avg_elevat) und die Höhen (elevat_) und Werte (value_) der Quellstationen
Auf dieser Tabelle wird dann abgefragt, an welchen Zeitpunkten r² zwischen den
Messwerten und der Höhe den gegebenen Schwellwert überschreitet. Für diese werden
dann die Variablen für die Regressionsgleichungen berechnet. Ist der Durchschnittswert
Null, so führt die Berechnung zu einem Fehler, da die Division durch Null nicht erlaubt ist.
Aus diesem Grund wird der Wert von Null mit der Hilfe einer CASE-Anweisung
ausgeschlossen.
68
4 Verwaltung und Interpolation von Zeitreihen in RBIS
select timestamp, round(((value_0 - avg_val) * (elevat_0 avg_elevat) + (value_1 - avg_val) * (elevat_1 - avg_elevat) +
(value_2 - avg_val) * (elevat_2 - avg_elevat) + (value_3 - avg_val) *
(elevat_3 - avg_elevat) + (value_4 - avg_val) * (elevat_4 avg_elevat) + 0)/[...] as b ,
(CASE WHEN avg_val != 0 then ( [...] ) as a
from temp_113312812
where 0.7 <= (CASE WHEN avg_val != 0 then ( (((value_0 - avg_val) *
(elevat_0 - avg_elevat) + (value_1 - avg_val) * (elevat_1 avg_elevat) + (value_2 - avg_val) * (elevat_2 - avg_elevat) +
(value_3 - avg_val) * (elevat_3 - avg_elevat) + (value_4 - avg_val) *
(elevat_4 - avg_elevat) + 0))/sqrt(((value_0 - avg_val) * (value_0 avg_val) +(value_1 - avg_val) * (value_1 - avg_val) +(value_2 avg_val) * (value_2 - avg_val) +(value_3 - avg_val) * (value_3 avg_val) +(value_4 - avg_val) * (value_4 - avg_val) +0) * ((elevat_0
- avg_elevat) * (elevat_0 - avg_elevat) +(elevat_1 - avg_elevat) *
(elevat_1 - avg_elevat) +(elevat_2 - avg_elevat) * (elevat_2 avg_elevat) +(elevat_3 - avg_elevat) * (elevat_3 - avg_elevat)
+(elevat_4 - avg_elevat) * (elevat_4 - avg_elevat) +0)))^2 end)
Die berechneten Variablen für die Regressionsgleichung werden anschließend in die
entsprechenden INSERT-Anweisungen für jeden ermittelten Zeitpunkt eingesetzt, so dass
der Originalwert auf die Höhe der Zielstation korrigiert wird, bevor er in IDW verwendet
wird. Alle restlichen Zeitpunkte werden mit einem einfachen IDW berechnet.
insert into calc_1297
(select temp_113312812.timestamp, (((275 - elevat_0 )*0.02382 +
value_0 )/4387.19^2 +((275 - elevat_1 )*0.02382 + value_1 )
/6937.98^2 +((275 - elevat_2 )*0.02382 + value_2 )/8204.52^2 +((275
- elevat_3 )*0.02382 + value_3 )/10384.56^2 +((275 - elevat_4 )
*0.02382 + value_4 )/11122.68^2 +0)/(1.04941583612E-07 ), 1
from temp_113312812
where temp_113312812.timestamp = 729993600);
Lineare Regression (linear regression)
Eine lineare Regression wird mit der Zeitreihe durchgeführt, die der Zielzeitreihe am
ähnlichsten ist. Dies wird anhand von r² ermittelt. Mit der maximalen Distanz und
maximalen Anzahl an Stationen kann der Umkreis der Suche eingeschränkt werden. Die
Angabe von r² gibt einen minimalen Wert an, der erfüllt sein muss. Für die Suche nach r²
muss dieser zunächst berechnet werden. Es wird dabei davon ausgegangen, dass alle
potentiellen Zeitreihen bzw. Stationen innerhalb der doppelten maximalen Anzahl an
umliegenden Stationen liegen. Für diese muss zunächst, falls noch keine Werte vorliegen,
r² berechnet werden. Diese Beschränkung soll die Berechnung unnötiger Werte verhindern
und die Laufzeit der gesamten Funktion verkürzen. Wurde die maximale Anzahl nicht
angegeben, so wird r² für alle Zeitreihenpaare berechnet. Nach der Ermittlung der
Quellstation werden die Parameter der Regressionsgleichung berechnet und anschließend
die SQL-Anweisung zur Berechnung der Werte eingesetzt.
69
4 Verwaltung und Interpolation von Zeitreihen in RBIS
insert into calc_1297
(select ref_86400.timestamp, 0.187165872413 +
0.87686573986499650156173452064395 * ts_1549.value1, 1
from ts_1549 RIGHT OUTER JOIN ref_86400 ON ref_86400.timestamp =
ts_1549.timestamp
where ref_86400.timestamp between 728524800 and 733536000);
4.4.2.4
Prüfen und Korrigieren der interpolierten Messwerte
Die berechneten Werte müssen hinsichtlich ihrer Plausibilität geprüft werden, da einige
Interpolationsverfahren auch Werte außerhalb des zulässigen bzw. möglichen
Wertebereichs als Ergebnis liefern können. Ein Beispiel hierfür sind Niederschlagswerte
zwischen 0 und 0,1 mm oder eine Luftfeuchtigkeit unter 0 % bzw. über 100 %. Die
jeweiligen Grenzwerte für jeden erfassten Parameter werden in einer eigenständigen
Tabelle verwaltet und können über das Metadatenportal editiert werden (Abbildung 26).
Überschreiten die Interpolationswerte den Bereich, so werden sie durch den festgelegten
Minimal bzw. Maximalwert ersetzt. Die Korrektur der Werte erfolgt automatisch nach
jedem abgeschlossenen Interpolationsvorgang mit einem einfachen Update auf der Tabelle
mit den berechneten Werten.
Abbildung 26: Übersicht der Grenzwerte für Messgrößen und Einheiten
Für die Temperatur wurden keine Parametersätze angelegt, da hier zu große regionale
Unterschiede sowie Abhängigkeiten mit der Messhöhe bestehen und somit die Festlegung
fester und allgemein gültiger Grenzen nicht möglich ist.
70
4 Verwaltung und Interpolation von Zeitreihen in RBIS
4.4.3
Anwendung durch RBIS-Nutzer
Über einen Link in der Übersicht der Zeitreihendaten (genauere Beschreibung in Abschnitt
4.5.2) gelangt der Anwender zu der Interpolationsseite. Hier stehen zwei Möglichkeiten
zur Verfügung, um ermittelte Datenlücken zu schließen. Es kann zwischen internen
(Internal Interpolation Method Set) und externen (External Interpolation Method)
Verfahren unterschieden werden. Zu den internen gehören die im RBIS implementierten
Interpolationsverfahren. Als extern werden alle Verfahren bezeichnet, die außerhalb von
RBIS angewendet und die ermittelten Lückenwerte anschließend in RBIS importiert
wurden.
4.4.3.1
Verwendung interner Verfahren
Alle im RBIS implementierten Interpolationsverfahren (siehe vorheriger Abschnitt)
können eingesetzt werden. Dies erfolgt jedoch nicht durch die direkte Auswahl des
Verfahrens, sondern über eine Zusammenstellung von Verfahren (method set) (Abbildung
27) mit Interpolationsregeln (Abbildung 28). In einer solchen Zusammenstellung werden
die Regeln festgelegt, die nahezu beliebig geändert oder neu erstellt werden können.
Abbildung 27: Auswahl einer Zusammenstellung
von Interpolationsverfahren
Abbildung 28: Interpolationsregeln für IDW (5-3)
Der Wert in der ersten Spalte (Position/Order) gibt die Reihenfolge an, in der die
Verfahren angewendet werden sollen. In der zweiten Spalte (Max gap length) erfolgt die
Angabe über die maximale Länge des Lückenintervalls bis zu dem das entsprechende
Verfahren angewendet werden soll. Die Festlegung dieses Parameters empfiehlt sich
71
4 Verwaltung und Interpolation von Zeitreihen in RBIS
insbesondere bei der linearen Interpolation, da dieses Verfahren nicht über beliebig große
Zeiträume angewendet werden sollte. Die folgenden zwei Spalten beinhalten
Informationen über die minimale und maximale Anzahl an Stationen (Min / Max stations),
die den Suchradius bei bestimmten Verfahren, wie IDW oder einer linearen Regression,
beschränken. Der Wert der Spalte Min Rsquared gibt die Untergrenze für ein r² an, falls
das Verfahren diesen betrachtet. Beispiele sind IDW mit Höhenkorrektur oder die lineare
Regression. Die maximale Distanz in der letzten Spalten (Max distance) gibt an, wie weit
die Quellstationen von der Zielstation maximal entfernt sein dürfen. Nach der Auswahl
einer Zusammenstellung (Abbildung 27) wird diese mit Execute ausgeführt. Der Button
mit der Aufschrift Simulate ist im Moment noch ohne Funktion. An diese Stelle soll es in
einer späteren Version möglich sein, einen Interpolationsvorgang zu simulieren um zum
Beispiel Änderungen durch gelöschte oder hinzugefügte Zeitreihendaten zu erkennen.
Nach Abschluss eines Interpolationsvorgangs besteht die Möglichkeit, die Details zu
diesem anzuzeigen. Abbildung 29 zeigt das Ergebnis nach einem erfolgreich
abgeschlossenen Vorgang. Konnten nicht alle Lücken gefüllt werden, so besitzt das
Attribut Complete den Wert false und in der Zeile darüber die mögliche Ursache. Ein
Beispiel dafür ist, dass kein passendes Verfahren gefunden werden konnte. Der Link Show
used time series führt zu der Übersicht, bei der für jedes Lückenintervall die verwendeten
Zeitreihen aufgelistet werden.
Abbildung 29: Informationen zu einem Interpolationsprozess
72
4 Verwaltung und Interpolation von Zeitreihen in RBIS
4.4.3.2
Verwendung externer Verfahren
Wurde ein externes Verfahren zum Füllen der Datenlücken verwendetet, so muss dieses
ausgewählt oder neu beschrieben werden. Das Importieren der Lückendaten, funktioniert
genauso wie das von gesamten Zeitreihen. Hier muss ebenfalls das Zeitformat angegeben
werden (Abbildung 30). Dabei kann die Datei Werte von einer oder allen Lücken oder
auch Originaldaten enthalten. Die Importfunktion übernimmt dann nur die Werte, die
innerhalb eines identifizierten Lückenintervalls liegen und behandelt sie genauso wie
interpolierte Werte. Hierbei gilt, dass ein Lückenintervall entweder vollständig gefüllt wird
oder gar nicht, da nur zum Teil gefüllt Lücken nicht verwaltet werden können. Sobald auch
nur ein Wert fehlt, wird keiner der Werte innerhalb des betreffenden Lückenintervalls
übernommen. Beim Import kann zusätzlich zwischen dem Ergänzen von Daten (add) und
dem Hinzufügen mit vorherigem Löschen alter Werte (new) gewählt werden. Damit wird
die Möglichkeit geschaffen, nachträglich offen gebliebene Lücken aufzufüllen, ohne
bisherige Ergebnisse zu verlieren. Die Verwendung externer Daten wird genauso
dokumentiert, wie die Verwendung von internen Verfahren.
Abbildung 30: Importieren von extern gefüllten Datenlücken
73
4 Verwaltung und Interpolation von Zeitreihen in RBIS
4.5
Export und Darstellung von Zeitreihendaten
Abschließend wurden Funktionen zur Darstellung sowie zum Export von Zeitreihendaten
überarbeitet und den neuen zur Verfügung stehenden Möglichkeiten angepasst.
4.5.1
Export
Es gibt verschiedene Möglichkeiten, die Daten zu Exportieren. Die einfachste Form ist der
Export der Originaldatei mit ihrem ursprünglichen Dateinamen, da dieser beim Import der
Daten abgespeichert wird. Für den Altdatenbestand des Einzugsgebietes der Saale steht
diese Funktion nicht zur Verfügung, da die Daten aus einer bestehenden Datenbank
übernommen wurden (ZANDER 2006).
Bei allen weiteren Exportarten werden die Daten aus der Datenbank ausgelesen. Der
Export erfolgt immer als Tabstop getrennte Textdatei. Der Dateiname setzt sich aus data_,
den ersten 20 Zeichen des Datensatznamens und der Zeitreihen ID zusammen. Zu Beginn
der Datei werden wichtige Metainformationen hinterlegt, die auch später eine eindeutige
Identifizierung und die Reproduzierbarkeit der Daten ermöglichen sollen (Abbildung 31).
Abbildung 31: Dateianfang einer exportierten Datei
Zu diesen Informationen gehört:
●
der Name der Installation von RBIS, aus dem die Daten stammen
●
das Exportdatum
●
der Nutzer, vom dem dieser Export ausgeführt wurde
●
der Name des Datensatzes
●
die Zeitreihen- und die Metadaten-ID
●
Zuordnung der Messgrößen und Einheit zu den einzelnen Spalten
74
4 Verwaltung und Interpolation von Zeitreihen in RBIS
Handelt es sich um Daten, die Lücken aufweisen oder aufgewiesen haben wird zusätzlich
angegeben:
●
das verwendete Verfahren
●
das Interpolationsdatum
●
die Angabe über Vollständigkeit.
War das angegeben Verfahren bei irgendeiner Lücke nicht erfolgreich (complete: f(alse))
besteht die Möglichkeit, dass sich weiterhin noch Lücken in den Daten befinden. Details
müssen in der Anwendung nachgelesen werden. Beim Export der Daten kann
grundsätzlich zwischen einem vollständigen (gesamtes Zeitintervall und alle Messgrößen)
und einem Teilexport unterschieden werden sowie zwischen originalen und modifizierten
Daten. Der Zugriff auf die originalen Datenbestände ist sehr einfach, da hier die Daten nur
aus einer Tabelle ausgelesen werden müssen. Der Zugriff auf die modifizierten Daten
erfolgt über Views, die automatisch für jede Spalte bei einem Interpolationsvorgang oder
dem Hochladen von Daten angelegt werden. Dies ist die Viewdefinition für ts_all_1297_1:
SELECT
CASE
WHEN calc_1297.“timestamp“ IS NULL THEN ts_1297.“timestamp“::bigint
ELSE calc_1297.“timestamp“
END AS „timestamp“,
CASE
WHEN calc_1297.value1 IS NULL THEN ts_1297.value1
ELSE calc_1297.value1
END AS value1
FROM calc_1297
FULL JOIN is ts_1297 ON ts_1297.“timestamp“ = calc_1297.“timestamp“
WHERE calc_1297.colnumber = 1 OR calc_1297.colnumber IS NULL;
Diese Views sorgen dafür, dass über sie auf die Daten zugegriffen werden kann, so als ob
diese aus einer einzigen Tabelle stammen würden. Bei dem Join zwischen den einzelnen
Tabellen haben die Zeitpunkte (timestamp) als auch die Werte aus der ergänzenden Tabelle
(hier calc_1297) Vorrang vor den ursprünglichen Daten, da zum einen durch
Datumslücken Zeitschritte nicht vorhanden sind und zum anderen Fehlkennungen wie
-9999 oder Null durch einen berechneten Wert ersetzt werden. Realisiert wird dies durch
zwei CASE-Anweisungen.
75
4 Verwaltung und Interpolation von Zeitreihen in RBIS
4.5.2
Darstellung
Die Übersicht über die Daten einer Zeitreihe (Abbildung 32) wird über einen
entsprechenden Link von den Metadaten aus aufgerufen. Sie untergliedert sich in die drei
Abschnitte Overall statistics and actions, Interval statistics and actions und Edit.
Im ersten Bereich (Overall statistics and actions) werden Informationen und Funktionen,
bezogen auf den Gesamtzeitraum der Daten angeboten. Hierzu zählt der Zeitreihenname
mit einem Link zu den Metadaten, die Anzahl der enthaltenen Datensätze bezogen auf die
erfassten Zeitpunkte, Beginn und Ende sowie Links zum Export der gesamten Daten des
betreffenden Metadatensatzes aus der Datenbank oder der Originaldatei. Zusätzlich wird
hinter der Anzahl der Datensätze der Prozentsatz angezeigt, der sich aus der Summe der
möglichen Zeitschritte und der Summe der Zeitschritte der Lücken des Gesamtzeitraums
ergibt. Als Berechnungsgrundlage wird hier die tatsächliche Gesamtanzahl an Zeitschritten
verwendet, die sich aus der Differenz zwischen dem ersten und dem letzten Datum der
Zeitreihe berechnet. Somit bezieht sie sich nicht auf die vorhandene und angezeigte Anzahl
an Datensätzen, da diese aufgrund von Datumslücken wesentlich niedriger sein kann.
Weiterhin wird dem Nutzer angeboten, die Daten auch ohne Lücken (with filled gaps)
herunterzuladen, sofern bei einer der Messgrößen Lücken identifiziert und diese gefüllt
wurden. Darüber hinaus müssen alle bekannten Lücken als vollständig aufgefüllt gelten,
denn nur dann ist das Exportieren eines lückenlosen vollständigen Datensatzes
gewährleistet.
In Abbildung 32 sind diese Voraussetzungen erfüllt. Der Exportvorgang selbst wurde
bereits in Abschnitt 4.5.1 beschrieben.
Im zweiten Bereich kann ein Teilintervall des Gesamtzeitraums ausgewählt werden. Dies
erfolgt über die Eingabe eines Start- und Enddatums. Über set interval werden die
Einstellungen übernommen und die Anzahl der vorhandenen Datensätze, die sich
wiederum auf die Zeitpunkte und nicht auf die einzelnen Werte beziehen, aktualisiert. Der
ausgewählte Zeitraum mit den gewünschten Messgrößen, die über Checkboxen ausgewählt
werden können, bildet die Grundlage für die grafische Darstellung und für den Export der
ausgewählten Daten. Die Links hinter jeder Messgröße und ihrer Einheit werden
dynamisch den entsprechenden Gegebenheiten angepasst. Das erste Element beinhaltet
Informationen über die Gesamtlänge aller Lückenintervalle und die Anzahl dieser
Lückenintervalle. Im in Abbildung 32 dargestellten Beispiel fehlen insgesamt 87 Werte,
die sich auf zwei Lückenintervalle aufteilen. Der Link verweist auf die Detailansicht über
die Lücken (vgl. Abbildung 18). Die letzte Spalte dieser Ansicht gibt Auskunft über
verwendete Interpolationsverfahren oder den Misserfolg einer Interpolation (not filled).
Erfolgte noch kein Interpolationsvorgang ist diese Spalte leer. Der Link des folgenden
Elementes ([I]) führt zur Auswahl und Ausführung eines Interpolationsverfahrens für die
entsprechende Messgröße bzw. dem Hochladen von Werten für die entsprechenden
76
4 Verwaltung und Interpolation von Zeitreihen in RBIS
Lücken. Die Farbe des Buchstabens gibt Auskunft darüber, ob bereits ein kompletter Satz
an Daten für alle Lücken dieser Messgröße vorliegt (grün) oder nicht (rot). Das dritte
Element ([nST]) verweist auf die Übersicht der umliegenden Stationen mit Daten der
gleichen Messgröße (siehe Abbildung 20).
Das erste Element wird immer bei vorhandenen Lücken angezeigt, das zweite nur, wenn
Lücken und das Modul für die Interpolation vorhanden sind. Das letzte wird immer bei
einem aktivierten Modul für die Interpolation angezeigt.
Abbildung 32: Übersichtsansicht für die Daten vom Metadatensatz „Niederschlag
Frauensee“
Die Daten können den Einstellungen über den Zeitraum und der Messgrößen entsprechend
so exportiert werden, wie sie in der Datenbank gespeichert sind (Originaldaten). Nach
einem Schließen der Lücken, ist auch der Export mit geschlossenen Lücken möglich.
Dabei wird zwischen einer vollständig und unvollständig geschlossenen Zeitreihe
unterschieden (without gaps (unfilled) und with filled gaps (note: unfilled gaps are
possible!)). Eine Zeitreihe gilt als vollständig, wenn alle Lücken erfolgreich geschlossen
77
4 Verwaltung und Interpolation von Zeitreihen in RBIS
wurden. Tritt eine Kombination zwischen einer vollständig und einer unvollständig
geschlossenen Messgröße auf, so ist es nicht möglich vor dem Exportieren eine Aussage
darüber zu treffen, ob in der ausgewählten Kombination zwischen Messgrößen und dem
Zeitintervall Lücken auftreten werden oder nicht. Sobald Werte für die Lücken vorhanden
sind, werden diese statt der ursprünglichen Werte verwendet. Fehlen sie, so werden an
dieser Stelle die Originaldaten (i.d.R. der Wert für die Fehlkennung) eingesetzt (siehe
Abschnitt 4.5.1).
Die Daten können den Einstellungen entsprechend auch grafisch dargestellt werden (show
plot). Die Anzahl der maximal darstellbaren Messgrößen ist dabei auf 10 begrenzt.
Aufgefüllte Werte werden farblich hervorgehoben, damit diese von den Originaldaten
unterschieden werden können. Fehlkennungen, wie zum Beispiel -9999, werden nicht
angezeigt und als Fehlwert (Null) behandelt. Demzufolge wird der Graph an dieser Stelle
unterbrochen. Mit hide plot kann das Diagramm wieder aus der Übersicht entfernt werden.
Wird auf die Darstellung des Diagramms verzichtet, so verkürzt sich die Ladezeit der
Webseite erheblich.
Der dritte Bereich umfasst die Funktionen zum Editieren der Daten. Zum einem existiert
ein Link zum Importieren (siehe Abbildung 16) und zum anderen zum Löschen der Daten.
Beim Löschen werden alle mit diesen Metadaten assoziierten Daten, wie Lückenangaben
oder die berechneten r² Werte zu anderen Zeitreihen, sowie die Zeitreihendaten selbst
dauerhaft gelöscht.
4.6
Einbindung der entwickelten Funktionen in RBIS
Um das Interpolationsmodul in einer RBIS-Installation zu aktivieren, ist es notwendig,
dass zum einen die globale Variable $tsstat in der Datei config.php auf true gesetzt wird
und zum anderen, dass die PostGIS Funktionen der Metadatenbank hinzugefügt werden.
Ist die globale Variable $tsstat auf false gesetzt, erscheinen keine Links, die zu Funktionen
führen, die PostGIS verwenden. Das betrifft die Übersicht zur Datenanalyse, die
Interpolation selbst und alle Links zu Funktionen, die mit einer Interpolation im
Zusammenhang stehen. Alle beschriebenen Funktionen beim Import von Daten werden
hingegen immer ausgeführt.
4.7
Aufgetretene Probleme
Während der Umsetzung der Erweiterung von RBIS traten einige Probleme auf, die an
dieser Stelle Erwähnung finden sollen. Weiterhin werden auch Anregungen und Hinweise
für die zukünftige Weiterentwicklung der Anwendung gegeben. Ursache vieler
Schwierigkeiten bei der Umsetzung stellten die hier immer als Altdatenbestand des
Einzugsgebietes der Saale bezeichneten Daten dar. Hier treten Inkonsistenzen oder gar
78
4 Verwaltung und Interpolation von Zeitreihen in RBIS
fehlerhafte Datensätze auf, wie z. B. das Beispiel in Kapitel 4.3.2 eindrucksvoll zeigen
konnte. Solange Fehler, wie im beschriebenen Fall einer identischen Zeitreihe an
verschiedenen Stationen, im Datenbestand vorhanden sind, müssen alle berechneten Werte
kritisch und mit Vorsicht behandelt werden. Insbesondere fehlerhaft eingetragene
Koordinaten können die Berechnungsergebnisse verfälschen. Bei vielen Stationen ist
zudem die Höhenangabe entweder recht zweifelhaft oder gar nicht vorhanden. Ebenfalls
liegt ein großes Fehlerpotential in nicht erkannten Datenlücken durch eine falsche oder
fehlende Angabe der verwendeten Fehlkennungen. Dies führte auch zu einigen
Komplikationen bei der automatischen Lückenanalyse im Altdatenbestand, da hier
verschiedene Werte für die Fehlkennung verwendet wurden, die in den Metadaten nicht
erfasst waren. Auch die automatische Lückenanalyse selbst verlief nicht gleich korrekt, so
dass Lücken doppelt oder gar nicht identifiziert wurden. Dieser Fehler konnte jedoch
nachträglich korrigiert werden. Beim Importieren einer Zeitreihe kann dieser Fehler
ausgeschlossen werden. In der Praxis hat sich jedoch auch gezeigt, dass Anwender die
Bedeutung der Fehlkennung unterschätzen und sich selten die Mühe machen, einen
prüfenden Blick auf das Ergebnis der identifizierten Lücken zu werfen. Auch die
Zuordnung der Messgrößen zu den einzelnen Spalten wird teilweise recht nachlässig
behandelt, so dass hier Inkonsistenzen entstehen, die nicht nur eine mögliche Interpolation
behindern, sondern auch die Suche nach den entsprechenden Datensätzen erschweren. Aus
den eben genannten Gründen kann und darf nicht auf eine manuelle Überprüfung der
Metadaten verzichtet werden. Daher ist es beim Datenimport von RBIS unbedingt
notwendig, darauf zu achten und auch gegebenenfalls zu kontrollieren, dass Metadaten
vollständig und korrekt eingetragen werden.
Bei der technischen Umsetzung selbst traten neben den bereits erwähnten Problemen noch
weitere auf. So können sich bei der Entwicklung einer komplexen SQL-Abfrage schnell
Fehler entstehen, die augenscheinlich ein korrektes Ergebnis liefern. Auch wenn ein
richtiges Ergebnis erzielt wird, so kann dies in einer nicht akzeptablen Zeit geschehen sein.
Hier können kleine Fehler eine große Wirkung zeigen, wie etwa eine vergessene JoinBedingung. In einem Fall führte dies zu einer Gesamtlaufzeit der Abfrage von knapp 70
Sekunden, obwohl diese bei korrekter Angabe nur wenige Sekunden oder gar
Millisekunden benötigt. Aus diesem Grund wurde viel Zeit aufgewendet, um die
Ausführungszeit der Abfragen zu minimieren. Bei der Programmierung selbst traten
gelegentlich Schwierigkeiten mit einzelnen Datentypen oder -werten (z. B. Null) bzw. mit
der automatischen Typkonvertierung von PHP auf.
Alle genannten Probleme konnten vollständig behoben werden und treten nicht mehr auf.
79
5 Zusammenfassung und Ausblick
5 Zusammenfassung und Ausblick
Ausgehend von den Anforderungen, die IWRM an die Datenhaltung, Verwaltung und
Präsentation von Informationen stellt, wurde gezeigt, wie Zeitreihendaten im
Informationssystem RBIS verwaltet und umweltbezogene Daten so bereitgestellt werden
können, dass sie keine Lücken mehr aufweisen und somit direkt in hydrologischen
Simulationsmodellen verwendet werden können. Möglich wurde dies durch die
Erweiterung der bisher erfassten Metadaten um Informationen über die Datenlücken und
Datenzuverlässigkeit innerhalb der Zeitreihen. In der vorliegenden Arbeit wurde zunächst
auf den fachlichen Hintergrund von RBIS eingegangen, bevor aus technischer Sicht
gezeigt werden konnte, inwieweit eine zentrale Datenhaltung sowie die Entwicklung einer
Web-Anwendung in Bezug auf RBIS sinnvoll ist und welche Vorteile, aber auch
Nachteile, dies mit sich bringt. In Abschnitt 2.2.1 wurde zudem der Begriff
„Informationssystem“ eingeführt und der Einsatz von freier und Open-Source-Software
begründet. Besonders im Blickpunkt lagen dabei Datenbank-Management-Systeme, die
raumbezogene Datentypen und raumbezogene funktionelle Erweiterungen anbieten.
Darunter zählt auch das im RBIS verwendete DBMS PostgreSQL/PostGIS. Mit den
Ausführungen zu Meta- und Zeitreiheninformationssystemen in Abschnitt 2.3 wurde
gezeigt, welche Standards bereits für die Speicherung und Verwaltung von Metadaten und
Zeitreihen existieren. Im Bereich der Metadaten spielte ISO 19115 eine bedeutende Rolle.
Die Beispiele für Metainformationssysteme untermauern dies. Mit diesen konnte auch
gezeigt werden, welche Bedeutung, Nutzen und Anwendung Metainformationssysteme
generell innerhalb der Geodateninfrastruktur in Deutschland aufweisen. Die Betrachtung
von Zeitreiheninformationssystemen und der Entwicklung von Standards in diesem
Bereich verdeutlicht die enge Verzahnung zwischen diesen beiden Informationssystemen.
Hier lohnt es sich, die Entwicklungen im Bereich der Meta- und
Zeitreiheninformationssysteme im Auge zu behalten, um die Entwicklung von RBIS in
Hinblick auf Standards und neue Techniken abzustimmen. Mit Abschnitt 2.4 wurde eine
Einführung in den Lückenersatz umweltbezogener Zeitreihen gegeben, angefangen bei
möglichen Ursachen bis hin zu verschiedenen Interpolationsverfahren zum Schließen der
Lücken. Im Anschluss wurde ein Überblick über die Verwaltung der Metadaten und
Zeitreihen in RBIS gegeben. Dabei wurden sowohl anwendungsinterne, als auch Aspekte
aus der Sicht eines Nutzers behandelt. Ausgehend davon wurden die entwickelten
Erweiterungen von RBIS ausführlich beschrieben. Dies bezog sich zunächst auf die
Überarbeitung der Importfunktion. Beim Import von Daten ist es nun möglich, Lücken zu
identifizieren und bedeutende Metainformationen wie Beginn und Ende einer Zeitreihe
automatisch zu erzeugen und den Metadaten hinzuzufügen. Der Vorgang selbst erfolgt
innerhalb einer Datenbanktransaktion und beinhaltet eine detaillierte Fehlererkennung und
-behandlung. Auf Grundlage der erfassten Metainformationen über Datenlücken und der
Zeitreihen wurde eine Möglichkeit geschaffen, diese zusammen mit der räumlichen
80
5 Zusammenfassung und Ausblick
Verteilung der Stationen, an denen die Zeitreihen erfasst wurden, unter verschiedenen
Aspekten integriert auszuwerten. Hierfür steht eine tabellarische und eine grafische
Darstellung der Ergebnisse zur Verfügung. Für die Interpolation der identifizierten
Datenlücken wurde ein regelbasiertes System eingeführt, welches einen flexiblen und
leicht
konfigurierbaren
Einsatz
verschiedener
im
RBIS
implementierter
Interpolationsverfahren ermöglicht. Damit wird auch den verschiedenen Einsatzmöglichkeiten der Interpolationsverfahren in Abhängigkeit der jeweiligen Messgröße, der
Einheit, dem Zeitschritt und andere Einflussfaktoren ( wie z. B. der Größe des
Einzugsgebietes oder der Größe der Datenlücke) Rechnung getragen, da die
Zusammenstellung und Anwendung der Regeln durch den fachkundigen Anwender erfolgt.
Auch eine Möglichkeit zum Import von Werten extern geschlossener Datenlücken wurde
eingerichtet. Der gesamte Vorgang zum Schließen von Datenlücken wird umfangreich
dokumentiert. Abschließend wurde der Export und die Darstellung der Zeitreihendaten
angepasst.
Mit den vorgestellten Erweiterungen konnte RBIS um wesentliche Funktionalitäten
ergänzt werden, die sich in laufenden und zukünftigen Forschungsprojekten als äußerst
hilfreich erweisen und erweisen werden. Hervorzuheben ist hier insbesondere die
Bereitstellung lückenfreier Datenreihen für deren Anwendung in Simulationsmodellen. In
RBIS selbst steckt noch großes Potenzial für eine zukünftige Weiterentwicklung. Dies
umfasst nicht nur eine Erweiterung des Funktionsumfangs für die Interpolation, sondern
auch die Ermittlung statistischer Lageparameter, Durchführung von Plausibilitäts- und
Homogenitätstests oder die Bereitstellung von Diensten, um z. B. eine direkte Anbindung
an das Modellsystem JAMS zu ermöglichen.
81
Anhang A: Datenmodelle
Anhang A: Datenmodelle
DS_Station – konzeptionelles Modell
Abbildung 33: konzeptionelles Modell für DS_Station
82
Anhang A: Datenmodelle
TS_TimeSeries – konzeptionelles Modell
Abbildung 34: konzeptionelles Modell für TS_TimeSeries
83
Anhang B: XML-Schema von RBIS (rbis.xsd)
Anhang B: XML-Schema von RBIS (rbis.xsd)
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="view">
<xs:complexType>
<xs:sequence>
<xs:element ref="id"/>
<xs:element ref="group" maxOccurs="unbounded"/>
<xs:element ref="association" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="table" maxOccurs="unbounded"/>
<xs:element ref="join" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="basedir" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value=".."/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="name" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="variable"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="title" type="xs:string" use="required"/>
<xs:attribute name="template" type="xs:boolean" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="table">
<xs:complexType>
<xs:sequence>
<xs:element ref="mandatory" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="mandatory">
<xs:complexType>
<xs:sequence>
<xs:element ref="attribute" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="join">
<xs:complexType>
<xs:attribute name="from_table" type="xs:string" use="required"/>
<xs:attribute name="from_key" type="xs:string" use="required"/>
<xs:attribute name="to_table" type="xs:string" use="required"/>
<xs:attribute name="to_table_alias" type="xs:string"/>
<xs:attribute name="to_key" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="id">
<xs:complexType>
<xs:attribute name="name" use="required"/>
</xs:complexType>
</xs:element>
84
Anhang B: XML-Schema von RBIS (rbis.xsd)
<xs:element name="group">
<xs:complexType>
<xs:attribute name="title" type="xs:string" use="required"/>
<xs:attribute name="name" use="required">
<xs:simpleType>
<xs:restriction base="gruppe"/>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="attribute">
<xs:complexType>
<xs:attribute name="name" type="xs:string" use="required"/>
<xs:attribute name="title" type="xs:string" use="required"/>
<xs:attribute name="type" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value=""/>
<xs:enumeration value="date"/>
<xs:enumeration value="float"/>
<xs:enumeration value="id"/>
<xs:enumeration value="integer"/>
<xs:enumeration value="text"/>
<xs:enumeration value="email"/>
<xs:enumeration value="hidden"/>
<xs:enumeration value="bool"/>
<xs:enumeration value="timestamp"/>
<xs:enumeration value="serialized"/>
<xs:enumeration value="password"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="size" type="xs:string"/>
<xs:attribute name="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="mandatory"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="pk" type="xs:string"/>
<xs:attribute name="default" type="xs:string"/>
<xs:attribute name="dateformat">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Y-m-d"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="update">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="dropdown"/>
<xs:enumeration value="false"/>
<xs:enumeration value="insert"/>
<xs:enumeration value="true"/>
<xs:enumeration value="dropdownrightjoin"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="check">
<xs:simpleType>
<xs:restriction base="radio"/>
</xs:simpleType>
</xs:attribute>
85
Anhang B: XML-Schema von RBIS (rbis.xsd)
<xs:attribute name="order" type="xs:integer"/>
<xs:attribute name="group">
<xs:simpleType>
<xs:restriction base="gruppe"/>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="overview" type="xs:integer"/>
<xs:attribute name="sort">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="key"/>
<xs:enumeration value="name"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="association">
<xs:complexType>
<xs:attribute name="title" type="xs:string" use="required"/>
<xs:attribute name="edit" type="xs:boolean" use="optional"/>
<xs:attribute name="code" type="xs:string" use="required"/>
<xs:attribute name="overview" type="xs:integer"/>
</xs:complexType>
</xs:element>
<xs:simpleType name="gruppe">
<xs:restriction base="xs:string">
<xs:pattern value="(g)?[0-9]+"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="radio">
<xs:restriction base="xs:string">
<xs:pattern value="(radio)?[0-9]+"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Abbildung 35: XML-Schema von RBIS
86
Anhang C: Auszüge aus dem Quellcode
Anhang C: Auszüge aus dem Quellcode
create_query_linear_interpolation()
Der Quellcode der Funktion create_query_linear_interpolation() für die lineare
Interpolation ist hier stellvertretend für alle anderen Verfahren angegeben. Vom Aufbau
her sind diese immer identisch.
1 function create_query_linear_interpolation($gap,$int_id, $tablename,
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
$col_a, $seconds ){
$db_ts = $this->db_ts;
$ts = "ts_".$this->ts_a_id;
$gap_start = $gap[0]-$seconds;
$gap_end =
$gap[1]+$seconds;
$value = "value$col_a";
$query ="select ((select $value from $ts where timestamp =
$gap_end)-(select $value from $ts where timestamp = $gap_start))/
($gap_end-$gap_start),(select $value from $ts where timestamp =
$gap_start)-((select $value from $ts where timestamp = $gap_end)(select $value from $ts where timestamp = $gap_start))/ ($gap_end$gap_start)*$gap_start";
$db_ts->sql_query($query);
$result = $db_ts->sql_fetchrow();
$error = $db_ts->sql_error();
if(!empty($error['message'])) {return $queries[2] = false;}
$m = $result[0];
$n = $result[1];
$equation .= $n." + " .$m." *
float)";
cast(ref_86400.timestamp as
$query = "insert into $tablename (select ref_86400.timestamp,
".$equation.", $col_a from $ts RIGHT OUTER JOIN ref_86400 ON
ref_86400.timestamp = ".$ts.".timestamp where ref_86400.timestamp
between ".$gap[0]." and ".$gap[1].");";
$log_ts_ids[$this->ts_a_id] = 0;
$log_query .= $this->create_gapfilled($int_id, $gap[2],
$log_ts_ids, 1 );
$queries[0] = $query;
$queries[1] = $log_query;
$queries[2] = true;
return $queries;
}
Abbildung 36: Quellcode der Funktion: create_query_linear_interpolation()
87
Anhang C: Auszüge aus dem Quellcode
interpolation_set()
Die Funktion interpolation_set() ist die zentrale Funktionen eines Interpolationsvorgangs.
Hier werden alle in Kapitel 4.4.2.2 beschriebenen Arbeitsschritte nacheinander aufgerufen.
Die Ausführung der Berechnungen findet unter 11. (Zeile 149) statt, indem alle INSERT
-Anweisungen auf der Zeitreihendatenbank ausgeführt werden.
1 function interpolation_set($method_set_id){
2
3
$db_ts = $this->db_ts;
4
$db = $this->db;
5
6 #1.----Get default value & colnumber for original TS
7
$miss_val = $this->get_miss_val($this->ts_a_id);
8
$col_a = $this->get_colnumber($this->ts_a_id, $this->ts_type_id);
9
10 #2.----Log interpolation process
11
$int_id = $this->write_interpolation($this->ts_a_id, $col_a,
$method_set_id, " " );
12
13 #3.----Create View & Table / Get tablename
14
$tablename = $this->createViewandTable($this->ts_a_id, $int_id,
$col_a);
15
16 #5.----Get all gaps
17
$gaps = $this->get_gaps($this->ts_a_id, $this->ts_type_id);
18
19 #6.----Get Method Set
20
$methods = $this->get_method_set($method_set_id);
21
$method_set = $methods[0];
22
$method_ids = $methods[1];
23
24 #7.----Preparation
25
foreach ($method_ids as $key=>$values){
26
switch ($key){
27
28
case 1: $seconds = $this->get_seconds($this->ts_a_id);
29
break;
30
31
case 2: foreach ($method_set as $pos=>$methods){
32
33
34
35
36
37
38
39
40
41
42
if($methods['int_method_id'] == "2"){$number =
$methods['max_parameter']*2;} }
$this->correlation($this->ts_a_id, $this->ts_type_id,
$number);
$tsstat_lr = new TSStatInterface($this->db, $this>db_ts, $this->ts_a_id, $this->ts_type_id, "0", 0, 1);
break;
case 3:
case 4:
case 6:
$tsstat_idw = new TSStatInterface($this->db,
$this->db_ts, $this->ts_a_id, $this->ts_type_id, "-1", 0, 1);
break;
default:
break;
}
}
88
Anhang C: Auszüge aus dem Quellcode
43 #8.----Create calc-query for every gap
44 foreach($gaps as $key =>$gap){
45
while ($i <= 10) {
46
if($gap[3] <= $method_set[$i]['max_gap_length'] or empty(
$method_set[$i]['max_gap_length'])){
switch ($method_set[$i]['int_method_id']) {
case 1:
//linear interpolation
$queries = $this>create_query_linear_interpolation($gap,$int_id, $tablename,
$seconds);
50
break 2;
47
48
49
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
$col_a,
case
2: //linear regression
$nogap_ts = $tsstat_lr->get_surrounding_ts_nogap(
$method_set['max_distance'], $method_set['max_parameter'] , $gap[0],
$gap[1]);
if(count($nogap_ts['rsquared']) == 0){
$queries[2] = false;
$error_message = "No matching time series found!.";
break 1;
}
$key =array_search(max($nogap_ts['rsquared']),
$nogap_ts['rsquared']);
if(max($nogap_ts['rsquared']) <
$method_set[$i]['min_rsquared']){
$queries[2] = false;
$error_message = "To high r²!.";
break 1;
}
else{
$best_corr[0]['ts_timeser_id'] = $nogap_ts['ts_id'][$key];
$best_corr[0]['colnumber'] = $nogap_ts['colnumber'][$key];
$queries = $this->create_query_linear_regression(
$gap,$int_id, $tablename, $miss_val, $col_a, $best_corr);
break 1;
}
case 3:
//IDW
$nogap_ts = $tsstat_idw->get_surrounding_ts_nogap(
$method_set['max_distance'], $method_set[$i]['max_parameter'] ,
$gap[0], $gap[1]);
if(count($nogap_ts['distance_arr']) == 0){
$queries[2] = false;
$error_message = "No matching time series found!.";
break 1;
}
$nogap_ts[11] = $gap;
if(intval(count($nogap_ts['ts_id']))-1 <
intval(($method_set[$i]['min']))) {
$queries[2] = false;
$error_message = "No enough matching time series
found!."; break 1;
}
else{
$queries = $this->create_query_IDW($nogap_ts,
$int_id, $tablename, $col_a); break 1;
}
89
Anhang C: Auszüge aus dem Quellcode
//nearest neighbour
$nogap_ts = $tsstat_idw>get_surrounding_ts_nogap($method_set['max_distance'], 1 , $gap[0],
$gap[1]);
91
$nogap_ts[11] = $gap;
92
if(count($nogap_ts['ts_id']) == 0){
93
$queries[2] = false;
94
$error_message = "No matching time series found!.";
95
break 1;
96
}
97
else{
98
$queries = $this>create_query_nearest_neighbour($nogap_ts, $int_id, $tablename,
$col_a);
99
break 1;
100
}
89
90
case
4:
101
102
103
case 6:
//IDW & elevat
$nogap_ts = $tsstat_idw>get_surrounding_ts_nogap($method_set['max_distance'],
$method_set[$i]['max_parameter'] , $gap[0], $gap[1]);
104
if(count($nogap_ts['distance_arr']) == 0){
105
$queries[2] = false;
106
$error_message = "No matching time series found!.";
107
break 1;
108
}
109
foreach ($nogap_ts['elevation'] as $x => $elevation){
110
if(!isset($elevation)){
111
$queries[2] = false;
112
$error_message = "Incorrect elevation found!.";
113
break 2;
114
}
115
}
116
$nogap_ts[11] = $gap;
117
if(intval(count($nogap_ts['ts_id']))-1 <
intval(($method_set[$i]['min']))) {
118
$queries[2] = false;
119
break 1;
120
}
121
else{
122
$source_elevation = $this->get_elevation($this>ts_a_id) ;
123
$queries = $this->create_query_IDW_elevat($nogap_ts,
$int_id, $tablename, $col_a, $source_elevation);
124
break 1;
125
}
126
127
default:
128
break;
129
} //end switch
130
if ($queries[2] == true) break;
131
$i++;
132
} //end if gap length
133
else $i++;
134}//end while
90
Anhang C: Auszüge aus dem Quellcode
if ($queries[2] == false){
$log_query .= $this->write_not_filled_gap($int_id, $gap,
$error_message);
$complete = false;
137
$error_message .= "No matching method found!.";
138
}
139
else{
140
$query_all .= $queries[0];
141
$log_query .= $queries[1];
142
}
143
} //end for gap
135
136
144
145#10.----Delete old data
146
$this->delete_calc($this->ts_a_id, $col_a);
147
148#11.----Execute
149
$db_ts->sql_query($query_all);
150
$error = $db_ts->sql_error();
151
$error['message'] ;
152
if(!empty($error['message'])){
153
$error_message = "Unexpected Error! Please contact
your application administrator (".$error['message'].")";
$log_query = "UPDATE int_interpolation SET complete =
false where int_interpolation_id = $int_id;";
155
}
156
else{}
154
157
158
$db->sql_query($log_query);
159
160#12.----Check and Update
161
$this->check_and_update_results($tablename, $col_a, $this-
>ts_type_id, $this->ts_a_id);
162
163#13.---UPDATE ts_description -> int_interpolation_id,
164
165
$this->update_ts_description($this->ts_a_id, $col_a, $int_id);
166
$this->update_interpolation($int_id, $error_message);
167
168 return $int_id;
169}
Abbildung 37: Quellcode der Funktion: interpolation_set()
91
Literatur
Literatur
AGRAR (2007): agrar.de - Informations- und Internetdienstleistungen. Dokumente zur
Agrar- und Umweltpolitik.
www.agrar.de
(letzter Zugriff am 01.11.2007)
ALLEN, R.G., L.S. PERIERA, D. RAES, & M. SMITH (1998): Crop evapotranspiration.
Guidelines for computing crop water requirements. - FAO Irrigation and drainage
paper, 56. Logan, USA.
AHRENS, B. (2005): Distance in spatial interpolation of daily rain gauge data. In:
Hydrology and Earth System Science Discussion, 2,S. 1893–1923.
AQUAPLAN (2002): Zeitreihen und ihre Benutzung. Analyse und Design des
Datenmodells. Aachen.
AQUAPLAN (2007): Professionelle Zeitreihenverwaltung und -auswertung für alle
zeitabhängigen Daten. Faltblatt.
BEHRENDS, K. W. CZEGKA & S. BRAUNE (2006): Metadateneditoren für geowissenschaftliche
Daten. In: STROBL, J., T. BLASCHKE & G. GRIESEBNER (Hsrg.): Angewandte
Geoinformatik 2006. Beiträge zum 18. AGIT-Symposium Salzburg, S. 41-46.
BKG (2007): GeoPortal.Bund. (BKG - Bundesamtes für Kartographie und Geodäsie).
http://geoportal.bkg.bund.de
(letzter Zugriff am 30.07.2007)
BILL, R. (1999): Grundlagen der Geo-Informationssysteme. Bd. 1, Hardware, Software und
Daten. Heidelberg.
BURROUGH, P.A. & R.A. MCDONNELL (1998): Principles of Geographical Information
Systems. New York.
CEGI (2007): CE°GI' GEOcatalog.
www.geocatalog.de
(letzter Zugriff am 30.07.2007)
CEN (2007): Europäisches Komitee für Normung.
www.cenorm.be
(letzter Zugriff am 07.08.2007)
CON
(2004): News: Open Geospatial Consortium verabschiedet neue Catalog
Services Specification 2.0. Datum: 04.10.2004.
www.conterra.de/de/service/news/
TERRA
COX, S. (2006): Oberservation and Measurement. Version 0.14.7. OGC 05-087r4.
OpenGIS® Best Practise. Draft.
92
Literatur
DEUTSCH, C.V. & JOURNEL, A.G. (1998²). GSLIB – Geostatistical software library and
user’s guide. Applied geostatistics series. Oxford University Press, New York.
ENGLUND, E & A. SPARKS (1991): GEO-EAS 1.2.1. Geostatitical environmental assessment
software. Users's guide. EPA 600/8, 91-008. EPA Environmental Monitoring
Systems Laboratory. Las Vegas.
FAMILI A., W.-M. SHEN, R. WEBER & E. SIMOUDIS (1997): Data preprocessing and intelligent
data analysis. In: FAMILI, A. (Hrsg.): Intelligent Data Analysis 1, Vol.1, No.1, S. 323.
FDGC (1998): Content Standard for Digital Geospatial Metadata. FGDC-STD-001-1998.
www.fgdc.gov/metadata/csdgm
FDGC (2007a): The Federal Geographic Data Committee.
www.fgdc.gov/
(letzter Zugriff am 07.08.2007)
FDGC (2007b): Geospatial Metadata Standards.
www.fgdc.gov/metadata/geospatial-metadata-standards
(letzter Zugriff am 07.08.2007)
FLÜGEL, W.-A., B. BÖHM, C. BUSCH & KRALISCH, S. (2005): Tisza River Information System
(TRIS) - A GeoData Server and Spatially Enabled Internet Applications for Water
Resources Management. 31st International Symposium on Remote Sensing of
Environment, Saint Petersburg, Russian Federation, June 20-24, 4pp. (CDROM)
FLÜGEL, W.-A. (2006): The adaptive integrated data information system (AIDIS) for global
water research. In: Water Resources Management (2007) Vol. 21. S. 199–210.
FSU (2007a): Integriertes Landschafts-Managementsystem (ILMS) für Wasserwirtschaft,
Kommunal- und Regionalplanung.
http://ilms.uni-jena.de
(letzter Zugriff am 25.09.2007)
FSU (2007b): Brahmatwinn. Twinning European and South Asian River Basins to enhance
capacity and implement adaptive management approaches.
www.brahmatwinn.uni-jena.de
(letzter Zugriff am 25.09.2007)
GERLACH, N. (2001): Ein Vergleich räumlicher Interpolationsverfahren für die
Windgeschwindigkeitsdaten in komplexen Gelände mit besonderem Bezug zur
Windkraftnutzung. Diplomarbeit.
GELOG (2006): HydroZIS. Zeitreiheninformationssystem.
www.eg-wrrl.de/downloads/zeitreiheninformationssystem.pdf
93
Literatur
GHOSH, R. A. (2006): Economic impact of open source software on innovation and the
competitiveness of the Information and Communication Technologies (ICT) sector
in the EU. Final report. 20.11.2006.
GISPUNKT (2007): Geo-Metadaten.
http://gis.hsr.ch/wiki/Geo-Metadaten
(letzter Zugriff am 29.07.2007)
GWP (2000): Integrated Water Resources Management. TAC Background Paper 4. Global
Water Partnership, Stockholm.
HANSEN, H. R. & G. NEUMANN (20018): Wirtschaftsinformatik 1. Stuttgart.
HERZOG, A. (2005): Zeitreihenanalyse.
www.stochastik.tu-clausthal.de
(letzter Zugriff am 26.09.2007)
HEUER, A. & G. SAAKE (2000²): Datenbanken. Konzepte und Sprachen. Landsberg.
HILLMAN, D. (2005): Using Dublin Core.
http://dublincore.org/documents/usageguide
(letzter Zugriff am 06.08.2007)
HINTERDING, A (2003): Entwicklung hybrider Interpolationsverfahren für den automatischen
Betrieb am Beispiel meteorologischer Größen. Münster.
HORSTMANN, J. (2006): Freie Datenbanken im Unternehmenseinsatz. Analyse und Vergleich
der wichtigsten Open-Source-Datenbanken. In: LUTTERBECK, B., BÄRWOLFF M. &
R.A. GEHRING (Hrsg.): Open Source Jahrbuch 2006.
IEEE & THE OPEN GROUP (2004): The Open Group Base Specifications Issue 6, IEEE Std
1003.1-2001.
IS 19115 (2003): ISO 19115 – Geographic information – Metadata. ISO 19115:2003(E).
ISO/TC 211 (2007): ISO/TC 211 Geographic Information / Geomatics.
www.isotc211.org
(letzter Zugriff am 07.08.2007)
JASPER, K. & J. SCHULLA (2007): Das hydrologische Modellsystem WaSiM-ETH.
http://homepage.hispeed.ch/wasim
(letzter Zugriff am 26.09.2007)
KAZAKOS, W. (2006): ISO 19115 Metadatenverwaltung als zentraler Bestandteil von
Geodateninfrastrukturen (GDI). In: STROBL, J., T. BLASCHKE & G. GRIESEBNER (
Hsrg.): Angewandte Geoinformatik 2006. Beiträge zum 18. AGIT-Symposium
Salzburg, S. 284-289.
94
Literatur
KISTERS AG (2007): WISKI - Wasserwirtschaftliche InformationsSystem KISTERS.
www.kisters.de
(letzter Zugriff am 07.08.2007)
KLINKENBERG, B. (1997): Spatial Interpolation 1.
www.geog.ubc.ca/courses/klink/gis.notes/ncgia/u40.html#SEC40.7
(letzter Zugriff am 14.07.2007)
KLOSSEK, M. (2004): Vor- und Nachteile von Webanwendungen im Vergleich zu Lösungen
auf Office Software Basis.
www.eworks.de/research/2004/05/Web_vs_Office/Web_vs_Office.pdf
KNIESS, A. & J. SCHERZER (2003): Plausibilitätsprüfung und Lückenersatz meteorologischer
Daten. In: BMVEL Wasserhaushalt von Waldökosystemen: Methodenleitfaden zur
Bestimmung der Wasserhaushaltskomponenten auf Level II - Fläche.
Bundesministerium für Verbraucherschutz, Ernährung und Landwirtschaft, Bonn.
KRUSE, F. (2007): PortalU - Umweltportal Deutschland. Herausgeber: Koordinierungsstelle
PortalU im Niedersächsischen Umweltministerium.
www.portalu.de
(letzter Zugriff am 07.08.2007)
LORUP, E. & J. FISLER (2006): Kontinuierliche Räumliche Variablen.
http://gitta.info/ContiSpatVar/de/html/index.html
(letzter Zugriff am 16.07.2007)
LUBW (2002): Aufbereitung von Wasserstandsdaten. Landesanstalt für Umweltschutz
Baden-Württemberg (LUBW). Karlsruhe.
MÜLLER, U., REMKE, A. & VOGES, U. (2005): Katalogdienste und Metainformation. In: L.
BERNARD, J. FITZKE & R. M. WAGNER (Hrsg.): Geodateninfrastruktur – Grundlagen
und Anwendungen, S. 126-133.
MÜLLER-WESTERMEIER, G. (2003):Verfügbarkeit und Qualität flächenbezogener Klimadaten.
www.dwd.de
(letzter Zugriff 20.07.2007)
OLAYA, V. (2004): A gentle introduction to SAGA GIS. Edition 1.1.
OGC (2007a): OGC Inititives - Interoperability Program.
www.opengeospatial.org/initiatives/
(letzter Zugriff am 27.07.2007)
OGC (2007b): Documents.
www.opengeospatial.org/specs/
(letzter Zugriff am 27.07.2007)
95
Literatur
OGC (2007c): About us.
www.opengeospatial.org/about
(letzter Zugriff am 27.07.2007)
PEBESMA, E.J. (2006): Waht is it?
www.gstat.com
(letzter Zugriff am 17.07.2007)
POSTGRESQL (2007): PostgreSQL 8.2.5 Documentation.
www.postgresql.org/docs/8.2/
(letzter Zugriff am 24.09.2007)
RAMSEY, P. (2007): PostGIS Manual. Version 1.2.2.
RAPP, J. (2001): Probleme bei der Analyse von Klimatrends auf der Basis von
Stationszeitreihen.
http://www.dwd.de/de/FundE/Klima/KLIS/prod/KSB/ksb00/proana.pdf
(letzter Zugriff am 13.07.2007)
SAAKE, G., A. HEUER & K.-U. SATTLER 2005²: Datenbanken: Implementierungstechniken. Landsberg.
SCHERZER, J. (2007): Modellierung meteorologischer Fehlwerte (Lückenersatz).
www.udata.de/Meteodata.htm
(letzter Zugriff am 01.10.2007)
SCHÖNAU, S. (2003): Regionalisierung von Klimaelementen für die hydrologische
Modellierung. Diplomarbeit.
SCHULLA , J. (1997): Hydrologische Modellierung von Flussgebieten zur Abschätzung der
Folgen von Klimaänderungen. Dissertation.
SCHWARZE, J. (20005): Einführung in die Wirtschaftsinformatik. Herne.
STOLL, B.L. (2006): Spass und Software-Entwicklung. Zur Motivation von Open-SourceProgrammierern. Dissertation.
STREIT, U. (1998): Einführung in die Geoinformatik.
http://ifgivor.uni-muenster.de/vorlesungen/Geoinformatik
(letzter Zugriff am 21.09.2007)
SYDRO (2007): Zeitreihenmanagement. SYDRO Ingenieurgesellschaft für Systemhydrologie, Wasserwirtschaft, Informationssysteme.
www.sydro.de
(letzter Zugriff am 27.07.2007)
Wikipedia (2007): GeoMIS.
http://de.wikipedia.org/wiki/GeoMIS
(letzter Zugriff am 30.07.2007)
96
Literatur
WSV (2007): Pegelonline: Informationen. Bundesanstalt für Wasserbau. Fachstelle der
Wasser- und Schifffahrtsverwaltung für Informationstechnik (F-IT), Referat IT2
Gewässerkunde.
www.pegelonline.wsv.de
(letzter Zugriff am 07.08.2007)
WRIGHT, P. (1998): The Significance of the Missing Data Problem in Knowledge
Discovery. In: Proceedings of the First Southern Symposium on Computin.
University of Southern Mississippi. 4.-5.12.1998.
WYTZISK, A.& I., SIMONIS (2005): Einbindung von Sensoren und Simulatoren in Geodateninfrastrukturen. In: L. BERNARD, J. FITZKE & R. M. WAGNER (Hrsg.):
Geodateninfrastruktur – Grundlagen und Anwendungen, S. 235 – 246.
YOU, J, K. G. HUBBARD & S. GODDARD (2004): Comparison of Estimates from Spatial
Regression and Inverse Distance Method. J. Atmos. Oceanic Tech., submitted.
ZANDER, F. (2006): Anwendung aktueller Standards für die datenbankbasierte Speicherung
von Geodaten am Beispiel der Saale. Studienprojekt (unveröffentlicht).
ZAPPA, M. & D. VIVIROLI (2005): Das PREVAH-Modellsystem – Konzept und
Anwendungsdemonstration.
Hydrologische
Einzugsgebietsmodellierung:
Ergebnisse und Anwendungspotential für die Praxis, Fachtagung an der
Eidgenössichen Forschungsanstalt für Wald, Schnee und Landschaft (WSL),
03.05.2005. Abstracts.
ZINK, L. (2000): Einbettung von Interpolationsverfahren in die Datenbanksprache SQL.
Datenbankunterstützung für die Umweltforschung. Dissertation.
97
Selbstständigkeitserklärung
Hiermit bestätige ich, dass ich diese Diplomarbeit selbständig und nur unter Verwendung
der angegebenen Quellen und Hilfsmittel angefertigt habe. Ich habe aus anderen Werken
entnommene Daten, Abbildungen sowie wörtliche oder sinngemäße Zitat mit
Quellenangaben gekennzeichnet.
Jena, den