Verwaltung von Zeitreihen in datenbank-basierten Informationssystemen am Beispiel von RBIS (River Basin Information System)

Transkript

1 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

2 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.

3 Inhaltsverzeichnis Verzeichnisse III Abkürzungsverzeichnis III Abbildungsverzeichnis IV 1 Einführung und Problemstellung 1 2 Grundlagen Einordnung von RBIS IWRM Integrated Water Resources Management AIDIS Adaptive Integrated Data Information System RBIS River Basin Information System Datenhaltung und -verwaltung Informationssystem Datenhaltung und Anwendung Einsatz von Open-Source Meta- und Zeitreiheninformationssysteme Metadaten für räumliche Informationen Metadatenstandards Metadateneditoren Metainformationssysteme für Geodaten Verwaltung von raum-zeitlichen Informationen Standards für Zeitreihen und Sensoren Zeitreiheninformationssysteme Zeitreihen und Datenlücken Zeitreihenarten Ursachen für Datenlücken in Zeitreihen Umgang mit Datenlücken Interpolationsverfahren Zeitliche Interpolationsverfahren Räumliche Interpolationsverfahren 28 3 Metadaten- und Zeitreihenverwaltung in RBIS Datenbankschema Grundlegende interne Funktionsweise XML-Dokumente Sicherheit Datenintegrität Funktionsumfang aus der Sicht der Anwender Aktueller Datenbestand im RBIS-IMTIS Anforderungen für zukünftige Erweiterungen 41 4 Verwaltung und Interpolation von Zeitreihen in RBIS Problemstellung und Ausgangssituation 42 I

4 4.2 Metadaten über Zeitreihen Anpassung des Datenmodells für die Verwaltung Erweiterung des Import-Formulares Überarbeitung der Upload-Funktion Transaktionen Qualitätsprüfung Datenlückenanalyse Bereitstellung verschiedener Datenanalysemöglichkeiten Allgemeine Funktionsweise und Voraussetzungen Anwendung durch RBIS-Nutzer Implementierung und Anwendung verschiedener Interpolationsverfahren Datenmodell und Datenhaltung Datenmodell für die Metadaten Speicherung der berechneten Werte Interpolationsvorgang und technische Umsetzung Berechnungsansatz Umsetzung und Ablauf von Interpolationen Implementierte Interpolationsverfahren Prüfen und Korrigieren der interpolierten Messwerte Anwendung durch RBIS-Nutzer Verwendung interner Verfahren Verwendung externer Verfahren Export und Darstellung von Zeitreihendaten Export Darstellung Einbindung der entwickelten Funktionen in RBIS Aufgetretene Probleme 78 5 Zusammenfassung und Ausblick 80 Anhang A: Datenmodelle 82 DS_Station konzeptionelles Modell 82 TS_TimeSeries konzeptionelles Modell 83 Anhang B: XML-Schema von RBIS (rbis.xsd) 84 Anhang C: Auszüge aus dem Quellcode 87 create_query_linear_interpolation() 87 interpolation_set() 88 Literatur 92 II

5 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 Content Standard for Digital Geospatial Metadata CSW Catalog-Service-Web DBMS Datenbank-Management-System DBS Datenbanksystem DCMI Dublin Core Metadata Initiative FGDC Federal Geographic Data Committee FOSS Freie und Open-Source-Software GDI-DE Geodateninfrastruktur - Deutschland GeoMIS.Bund Metainformationssystem für Geodaten des Bundes GIS Geoinformationssystem GWP Global Water Partnership IDW Inverse Distanzwichtung ILMS Integriertes Landschafts-Managementsystem IMTIS 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 Observation and Measurement OGC Open Geospatial Consortium OWS OGC Web Service PortalU Umweltportal Deutschland RBIS River Basin Information System RDBMS relationale Datenbank-Management-System SensorML Sensor Model Language SWE Sensor Web Enablement TRIS Tisza River Information System UDK Umweltdatenkatalog III

6 Abbildungsverzeichnis Abbildung 1: Aufbau von RBIS mit den Anwendungen Metadaten- und Zeitreihenverwaltung und Kartenserver sowie den Datenbanken...6 Abbildung 2: ISO 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 bis 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_ ) 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 Abbildung 33: konzeptionelles Modell für DS_Station Abbildung 34: konzeptionelles Modell für TS_TimeSeries Abbildung 35: XML-Schema von RBIS Abbildung 36: Quellcode der Funktion: create_query_linear_interpolation() Abbildung 37: Quellcode der Funktion: interpolation_set() IV

7 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 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

8 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 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

9 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

10 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 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

11 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) 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 (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

12 2.1.3 RBIS River Basin Information System 2 Grundlagen 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

13 2.2 Datenhaltung und -verwaltung 2 Grundlagen 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 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 Geo- Informationssystem 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

14 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) 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 oder CD. Auch ein 8

15 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 Desktop- Anwendung 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. Desktop- Anwendungen 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

16 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 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

17 2 Grundlagen Entwicklern und in Folge dessen eine deutlich höhere Motivation bei der Arbeit an Open- Source-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-Source- Datenbanksystemen. 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

18 2.3 Meta- und Zeitreiheninformationssysteme 2 Grundlagen 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 Geodaten- Produzenten, 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

19 2.3.1 Metadaten für räumliche Informationen 2 Grundlagen 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 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 Metadatenstandards Für Geodaten gibt es mehrere Dokumentationsstandards. Der wichtigste Standard für Metadaten im Geoinformationswesen ist ISO 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 FGDC- Standard 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

20 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 ISO 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 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 Metadaten- Norm (ENV 12657: 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 , FDGC 2007b). Abbildung 2: ISO Profil für bestimmte Nutzergruppen oder Länder community profile (Quelle: ISO 19115:2003) 14

21 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) 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 Zu den Desktop-Anwendungen zählt der kommerzielle ArcCatalog und die ArcView Metadata Extension von der Firma ESRI, die den FGDC-Standard und ISO abdecken. Ein weiteres kommerzielles Produkt ist Infopath von Microsoft. Zu den kommerziellen Web- und Desktop-Anwendungen, die ISO 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

22 2 Grundlagen 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 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

23 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 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-Web- Schnittstelle (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 in Kraft getretenen Verwaltungsvereinbarung UDK (seit : 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

24 2.3.2 Verwaltung von raum-zeitlichen Informationen 2 Grundlagen 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 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

25 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) Observations & Measurements (O&M) Sensor Model Language (SensorML) Transducer Markup Language (TML) Sensor Alert Service (SAS) Sensor Planning Service (SPS) Bereitstellung von Messergebnissen (standardisierte, webbasierte Schnittstelle für Zugriff auf Sensoren und Sensordatenarchive) Modellierung und Codierung von Messergebnissen (Modell zur Abbildung räumlich und zeitlich varianter Größen; XML basiertes encoding) Beschreibung der Sensoren (Beschreibungssprache zur eindeutigen Referenzierung und Definition von Sensoren) Charakterisierung der Sensoren (Modellierung und Codierung für Datenströme von Sensoren; Beschreibung von System und Daten encoding) Alarmmeldungen der Sensoren (Anzeigen, Abonnieren und Veröffentlichen von Warnungen) Planung von Messexperimenten (standardisierte Schnittstelle zur Informationsbeschaffung für Mess- und Simulationsaufgaben) (Draft OpenGIS Implementation Specification) (Draft OpenGIS Best Pratices Document) (OpenGIS Implementation Specification ) (OpenGIS Implementation Specification ) (Candidate OpenGIS Implementation Specification (Request for Comments OpenGIS Best Pratices Document) Web Notification Service (WNS) Benutzerbenachrichtigung (Schnittstelle zur Kapselung von Funktionen für Benachrichtigung von Nutzern und Diensten) (Draft OpenGIS Best Pratices Document) (Quellen: OGC 2007b, WYTZISK & SIMONIS 2005:235ff, Stand: ) 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

26 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 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 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

27 Zeitreiheninformationssysteme 2 Grundlagen 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

28 2.4 Zeitreihen und Datenlücken 2 Grundlagen 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

29 2.4.1 Zeitreihenarten 2 Grundlagen 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

30 Momentan-Zeitreihen 2 Grundlagen 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 Momentan- Zeitreihen 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 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

31 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 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 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 WaSiM- ETH (JASPER & SCHULLA 2007) oder PREVAH (WINMET)(ZAPPA & VIVIROLI 2005), stellen ebenfalls Interpolationsverfahren zur Verfügung. 25

32 2.4.4 Interpolationsverfahren 2 Grundlagen 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ächster- Nachbar-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) 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

33 Lineare Interpolation 2 Grundlagen 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

34 Räumliche Interpolationsverfahren 2 Grundlagen 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

35 IDW Inverse Distanzwichtung 2 Grundlagen 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 (w i ) für jeden Messwert zum Ausdruck gebracht (1). 1 wi = d p (1) x w n i i= 1 = n ( x w ) i= 1 w i 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

36 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

37 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

38 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

39 3.1 Datenbankschema 3 Metadaten- und Zeitreihenverwaltung in RBIS Das Datenbankschema für die Datenbank von RBIS-IMTIS beinhaltet eine vollständige Umsetzung des ISO Standards und verschiedene allgemeine Erweiterungen. Eine global eindeutige Metadaten-ID verbindet die ISO 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

40 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 (Abschnitt ) 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 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

41 3.2 Grundlegende interne Funktionsweise 3 Metadaten- und Zeitreihenverwaltung in RBIS 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 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 XML- Dokumente 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

42 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 XML- Dateien 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 Join- Bedingungen 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

43 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 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

44 3.2.3 Datenintegrität 3 Metadaten- und Zeitreihenverwaltung in RBIS Für die Datenintegrität im RBIS-IMTIS sorgen mehrere Mechanismen. Die Formate der Eingabewerte werden hinsichtlich ihres korrekten Typs (Datum, Float, Integer, 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

45 3.3 Funktionsumfang aus der Sicht der Anwender 3 Metadaten- und Zeitreihenverwaltung in RBIS 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

46 3.4 Aktueller Datenbestand im RBIS-IMTIS 3 Metadaten- und Zeitreihenverwaltung in RBIS 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 :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 Brahmatwinn- Forschungsprojekt getestet. 40

47 3.5 Anforderungen für zukünftige Erweiterungen 3 Metadaten- und Zeitreihenverwaltung in RBIS 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

48 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

49 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

50 4 Verwaltung und Interpolation von Zeitreihen in RBIS 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 UNIX- Zeit 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 ). 44

51 4 Verwaltung und Interpolation von Zeitreihen in RBIS Abbildung 15: Datenzuverlässigkeitsmodul (physisches Datenmodell) 45

52 4.2.2 Erweiterung des Import-Formulares 4 Verwaltung und Interpolation von Zeitreihen in RBIS 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 )(Abbildung 16). Abbildung 16: Import-Formular für Zeitreihendaten Ü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

53 4 Verwaltung und Interpolation von Zeitreihen in RBIS 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

54 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 Error- Protokoll 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

55 4 Verwaltung und Interpolation von Zeitreihen in RBIS 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 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 auf den , 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

56 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 beginnt, jedoch erst ab dem Messwerte beinhaltet. Abbildung 18: Lücken der Niederschlagszeitreihe Eich 50

57 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

58 4 Verwaltung und Interpolation von Zeitreihen in RBIS 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

59 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 RBIS- Benutzer 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 Ist auch der verwendete Zeitschritt ohne Bedeutung entfällt der Inhalt der Zeile 48 ebenfalls. 1 SELECT a.statname, 2 b.statname, 3 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)), 4 ts.startdatetime, 5 ts.enddatetime, 6 citation.restitle, 7 b.md_metadata_id, 8 ts.md_metadata_id, 9 a.md_metadata_id, 10 ts.ts_timeser_id, 11 fp_featpar.featpar, 12 b.elevat, 13 ts.missing_value, 14 ts_desc.colnumber, 15 round((select rsquared FROM int_correlation where int_correlation.fp_featpar_id = ' ' 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

60 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 = and ts_desc.fp_featpar_id = ' ' 39 and ts.ts_timeser_id!= 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 = ' ' and dr_datagaps.startgap between and or dr_datagaps.endgap between and or (dr_datarelia.gapanalysis = false or dr_datarelia.gapanalysis is null) ) 46 and ts.startdatetime <= and ts.enddatetime >= 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 = ' ') 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

61 4.3.2 Anwendung durch RBIS-Nutzer 4 Verwaltung und Interpolation von Zeitreihen in RBIS Ü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

62 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 ( ) ü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