Weiterentwicklung eines kontinentalen Wasser-Informationssystems zu einem Umweltinformationssystem Prof. Dr. Ralf Denzer PIM-PA WS 2015/2016 Aufgabenstellung Für die Beobachtung und das Management von Wasser-Ressourcen werden umfangreiche Datensammlungen benötigt. Diese werden in Europa zum Teil lokal, zum Teil national und auch grenz-überschreitend erhoben. Diese Datensätze beinhalten komplexe raum-zeitliche Konzepte und haben einen zum Teil erheblichen Umfang, der mit traditionellen GIS- Systemen schlecht bearbeitet werden kann. Im WS 2014-2015 wurde im Rahmen eines Masterprojekts die Konzeption und prototypische Realisierung eines Wasser-Informationssystems für Europa durchgeführt. Dabei standen Interaktivität, Visualisierung und Benutzerfreundlichkeit im Vordergrund. Dieses System soll zu einem föderierten Umweltinformationssystem auf der Basis einer Servisce-Orientierten Architektur weiterentwickelt werden. Auch bei dieser Weiterentwicklung spielt die Interaktivität eine Hauptrolle. Die Gewässerinformation soll nun mit allgemeinen topographischen Informationsquellen wie Strassennetzen, NUTS (administrative Einheiten) und Klimawandelinformation verknüpft werden, was zu komplexen raum-zeitlichen Queries führen kann, die zu bewältigen sind. Vorgängerprojekt Die Dokumentation des Vorgängerprojekts ist angehängt.
HTW SAAR Dokumentation Masterprojekt Analyse und Softwareentwicklung im Umfeld des europäischen Flussdatenbestandes ECRINS Alexei Felberg, René Hauck, Kevin Roos, Eugen Weisbeck, Steffen Zuber 31.03.2015
Inhalt Abbildungen... 3 Einleitung... 4 Ziel... 4 Organisatorisches... 4 Grundlagen... 4 Geodaten... 4 Formate... 5 Verwandte Arbeiten... 5 QGIS... 5 Datenbankanalyse... 7 EcrRiv... 7 Wichtige Felder in C_Tr... 8 Wichtige Felder in C_Node... 8 Beispielaufrufe... 8 EcrFEC... 9 Wichtige Felder in C_ZHYD... 9 Beispielaufrufe... 9 EcrGaz... 9 Wichtige Felder in RivNames... 10 Wichtige Felder in RivNamesAlias... 10 Beispielaufrufe... 10 Catchment eines Flusses... 10 Beispiele... 11 Anforderungsanalyse... 13 Architektur... 14 Web-Architektur... 14 Web-Java-Architektur... 15 API... 16 Allgemeines... 16 Verwendete Bibliotheken... 16 Aufbau... 16 de.htwsaar.keras.db... 17 de.htwsaar.keras.exceptions... 17 de.htwsaar.keras.generators... 17 de.htwsaar.keras.logic... 17 1
de.htwsaar.keras.multithreading... 18 Server... 19 GUI und Benutzung... 19 Schnittstellen... 19 Bibliotheken... 20 Client... 21 Bibliotheken... 21 OpenLayers... 21 AngularJS... 21 Grafische Oberfläche... 21 Beispielprozess... 23 Programmierung... 28 Fazit... 30 Ergebnis... 30 Schwierigkeiten... 30 Ausblick... 30 Schlussbetrachtung... 31 Quellen... 32 2
Abbildungen Abbildung 1: QGIS-Benutzeroberfläche... 6 Abbildung 2: Alle ECRINS-Nodes... 6 Abbildung 3: FECs für einen Fluss anhand der zhyd... 11 Abbildung 4: FECs eines Flusses anhand der code_arbo... 12 Abbildung 5: Ein Segment, ein Catchment... 12 Abbildung 6: Zwei Segmente, zwei Catchments... 13 Abbildung 7: Mehrere Segmente, ein Catchment... 13 Abbildung 8: Web-Architektur... 14 Abbildung 9: Web-Java-Architektur... 15 Abbildung 10: API-Struktur in Eclipse... 16 Abbildung 11 Package db... 17 Abbildung 12: Package exceptions... 17 Abbildung 13: Package generators... 17 Abbildung 14: Package logic... 18 Abbildung 15: Package Multithreading... 18 Abbildung 16: Server-GUI... 19 Abbildung 17: Dynamisches Laden der Handler... 20 Abbildung 18: Server-Bibliotheken... 20 Abbildung 19: Client-Oberfläche beim Start... 22 Abbildung 20: Hauptmenü des Clients... 23 Abbildung 21: Dialogfenster Flussname... 23 Abbildung 22: Ladebalken während Prozessierung... 24 Abbildung 23: Ergebnisdarstellung... 24 Abbildung 24: Satelliten-Layer... 25 Abbildung 25: Funktion "WMS-Optionen"... 25 Abbildung 26: Layerliste... 26 Abbildung 27: Styling-Optionen Layerliste... 26 Abbildung 28: Abfragen der Capabilities... 27 Abbildung 29: Basisinformationen Capabilities... 27 Abbildung 30: Konkrete Capabilities als Funktionen... 28 Abbildung 31: Export als Bilddatei... 28 Abbildung 32: Funktionsregistrierung im Controller... 30 3
Einleitung 2012 wurde ein europäisches Datenbanksystem veröffentlicht, das European catchments and rivers network system (kurz: ECRINS) [1]. Es beinhaltet Geodaten zu Flüssen und Einzugsgebieten für ganz Europa. Um die Daten verarbeiten zu können, beschäftigte sich eine Projektgruppe im Zuge des Masterstudiums der Praktischen Informatik an der HTW Saar mit zwei grundlegenden Themen: 1. Datenbankanalyse 2. Konzeption und prototypische Implementierung von Softwarelösungen zum Zugriff a. Java-API zum Bereitstellen der relevanten Daten b. Webserver zum generischen Zugriff auf die Java-API c. Client, welcher die Anzeige der Geodaten ermöglicht Ziel Das Ziel dieses Projektes besteht aus Konzeption und Entwicklung eines dreiteiligen Management- Tools, um mit den komplexen und umfangreichen ECRINS-Daten arbeiten zu können. Es existieren natürlich schon traditionelle Geoinformationssysteme (kurz: GIS), die diese Daten verarbeiten können. Solche Systeme bieten aber meist keine bequemen Filtermöglichkeiten und können beispielsweise nur komplette Datenlayer anzeigen, was sowohl die Nutzerfreundlichkeit, als auch die Performanz der Anwendung beeinträchtigt. Organisatorisches Die Projektgruppe bestand aus folgenden Personen: Alexei Felberg René Hauck Kevin Roos Eugen Weisbeck Steffen Zuber Diese Projektarbeit fand im Rahmen des Masterprojekts des Studiengangs Praktische Informatik an der HTW Saar im Wintersemester 2014 / 2015 statt. Intern wurden folgende Milestones gesetzt, welche grob den zeitlichen Projektablauf beschreiben: Meilenstein Abschlussdatum Grundlagen Projektgründung 21.10.2014 Requirements specification 15.11.2014 Datenbankanalyse 20.11.2014 Softwarearchitektur 20.12.2014 Implementierung und Test 15.03.2015 Dokumentation 31.03.2015 Geodaten Als Geodaten bezeichnet man Daten, welche räumliche Lagen und Beziehungen beschreiben und sich im Allgemeinen auf Kartenmaterial der Erde abbilden lassen. ECRINS beschreibt die Flüsse und 4
Einzugsgebiete in verschiedenen Dimensionen, so zum Beispiel als NODE (Knoten), SEGMENT (Fläche) oder CATCHMENT (Einzugsgebiet). Formate Auf technischer Ebene können Geodaten mit klassischen Datenformaten abgebildet werden. Hierbei sind z.b. folgende zu nennen: JSON bzw. GeoJSON XML bzw. GML Verwandte Arbeiten Es existiert eine Reihe von GIS-Softwares, die zu den verabschiedeten Standards des OGC (Open Geospatial Consortium) kompatibel sind. Das OGC liefert eine Beschreibung für das Verhalten und Funktionsweise eines dienstbasierten GIS [2]. Es gibt eine Reihe von standardisierten Services, wie sie OGC beschreibt, dazu gehören unter anderem: WMS, WFS, WCS, WPC und CSW [3]. Der WFS ( Web Feature Service ) bietet das Abfragen von Features an, mit denen erweiterte Informationen einer Geometry bereitgestellt werden. Damit ließe sich mit einem WFS eine Ausgabe aller Flüsse bewerkstelligen. Sollen jedoch einzelne Flüsse ausgegeben werden, müssen alle Flüsse an den Client gesendet und dort gefiltert werden. Die dabei zu verwaltende Datenmenge ist enorm und beträgt mehrere hundert Megabyte an Information, was bei einer Übertragung über das Internet, zu besonders langen Wartezeiten führt. Damit nur die gewünschten Informationen an den Client gesendet werden, müssen neue Funktionen eingeführt werden, die außerhalb des OGC-Standards liegen. Diese neuen Funktionen sind wie die Featuretypes eines WFS individuell an eine Datenbank angepasst. Für die ECRINS-Datenbanken gibt es jedoch keine WFS-Variante mit Funktionen für die Suche von individuellen Flüssen oder deren Nebenflüssen. Zu den populärsten GIS-Programmen gehört QGIS als Visualisierungstool, was nachfolgend kurz vorgestellt wird. QGIS QGIS ist ein geografisches Open-Source-Informationssystem (GIS), das unter der GNU General-Public- License steht. QGIS ist ein offizielles Mitglied der Open-Source-Geospatial-Foundation (OSGeo). Es läuft unter Linux, Unix, Mac OSX, Windows und Android und unterstützt eine Vielzahl von Vektor-, Raster-und Datenbankformaten und hat einen großen Funktionsumfang [4]. Diese Tatsache erwies sich aber als Hindernis bei der Arbeit mit ECRINS, da sich die schiere Masse der Daten äußerst ungünstig auf die Laufzeit der Darstellung auswirkt. 5
Abbildung 1: QGIS-Benutzeroberfläche QGIS bietet viele generelle GIS-Funktionen, welche durch Kernfunktionen und Erweiterungen bereitgestellt werden. Eine kurze Zusammenfassung der wichtigsten Funktionen wird im Folgenden dargestellt. Visualisierung Es ist möglich, Vektor- und Rasterdaten in unterschiedlichen Formaten und aus verschiedenen Projektionen anzuschauen und zu überlagern, ohne die Daten selbst in irgendeiner Art und Weise konvertieren zu müssen. Nachfolgende Abbildung visualisiert alle in der ECRINS-Datenbank enthaltenen Objekte des Typs Node. Abbildung 2: Alle ECRINS-Nodes 6
Daten abfragen und Karten layouten Man kann Karten zusammenstellen und interaktiv räumliche Daten mit einer benutzerfreundlichen GUI erkunden. Daten erstellen, editieren, verwalten und exportieren Man kann Vektor- und Rasterlayer erstellen, bearbeiten und in zahlreiche Formate exportieren. Daten analysieren Man kann Datenanalysen auf räumliche Datenbanken und andere OGR-unterstützte Formate anwenden. QGIS bietet zur Zeit Vektoranalysen, Sampling, Geoverarbeitung sowie Geometrie und Datenbankmanagementwerkzeuge. Man kann auch die integrierten GRASS Werkzeuge, die die komplette GRASS Funktionalität von mehr als 400 Modulen beinhalten, benutzen. Alternativ ist das Verarbeitungs-Plugin nutzbar, welches eine mächtige Analyseumgebung zur Verfügung stellt, mit dem man native oder Drittanbieter-Algorithmen aus QGIS heraus aufrufen kann, z.b. GDAL, SAGA oder ftools. [5]. Fazit QGIS diente während des Projekts als erste Zugangsmöglichkeit zu ECRINS, sodass die Teilnehmer ein Gefühl für Umfang und Beschaffenheit erlangen konnten. Nichtsdestotrotz erwies sich QGIS als Standardsoftware nicht als optimales ECRINS-Werkzeug, was die Notwendigkeit einer ECRINSspezialisierten Softwarelösung bestätigte. Datenbankanalyse Bei ECRINS handelt es sich um einen hydrologischen Datenbestand. Dieser wurde erstellt um verschiedenen Institutionen und Nutzern, die in einem ökologischen Umfeld arbeiten, ein kostenloses System von Flüssen und deren Einzugsgebieten zur Verfügung zu stellen. Die darin enthaltenen Daten sind einsatzbereit, komplett und offiziell anerkannt. Desweiteren können die Daten manipuliert und für Berechnungen verwendet werden. ECRINS setzt sich aus mehreren Datenbanken zusammen. Nach anfänglicher Analyse stellte sich heraus, dass nur drei davon für dieses Projekt relevant sind: EcrRiv EcrFEC EcrGaz Im Folgenden werden die einzelnen Datenbanken genauer beschrieben. EcrRiv Die Datenbank EcrRiv enthält die beide wichtigsten Tabellen C_Tr und C_Node. In C_Tr befinden sich die Flusssegmente und in C_Node die Flussknoten. Jedes Segment befindet sich zwischen zwei Knoten. Zusätzlich ist jedem Segment ein Functional Elementary Catchment, kurz FEC, zugewiesen. Dabei handelt es sich um das elementarste Einzugsgebiet, welches dem Segment zugeordnet werden kann. Die Zuordnung funktioniert über das Feld ZHYD, welches die Tabelle C_Tr mit der Tabelle C_ZHYD der Datenbank EcrFEC verknüpft. Die Flussnamen wurden bewusst in einer anderen Datenbank gespeichert, da es sehr wahrscheinlich ist, dass dieser Datenbestand noch erweitert wird. 7
Wichtige Felder in C_Tr Feld TR ZHYD FNode TNode L_Seg L_T2MOUTH STRAHLER RivRank River_ID Geometry Bedeutung Eindeutige ID des Segments ID des FEC, zu welchem das Segment gehört ID des Knotens, von dem das Segment ausgeht ID des Knotens, zu dem das Segment hinführt Länge des Segments Distanz des Segments zur Flussmündung Flussordnungszahl Flussordnung ID des Flusses, zu dem das Segment gehört Beinhaltet eine Sammlung von Punkten, die das Segment darstellen Wichtige Felder in C_Node Feld Bedeutung NodId Geometry Eindeutige ID des Knotens Beinhaltet Koordinaten als Pointer und kann in Längen- und Breitengrade umgewandelt werden Beispielaufrufe Alle Linien des Rheins: SELECT * FROM C_tr WHERE River_ID LIKE '%Z_C0000934%' Alle Knoten des Rheins: SELECT * FROM C_Node WHERE NodID IN ( SELECT FNode FROM c_tr WHERE River_ID LIKE '%Z_C0000934%') 8
OR NodID IN ( SELECT TNode FROM c_tr WHERE River_ID LIKE '%Z_C0000934%') Länge der Saar: SELECT SUM (L_SEG) FROM C_Tr WHERE River_ID LIKE "%Z_C0000892% EcrFEC Die Datenbank EcrFEC beinhaltet alle wichtigen Daten der Flusseinzugsgebiete( Catchments ). Diese befinden sich in der Tabelle C_ZHYD. Wie schon weiter oben beschrieben, sind die Catchments mit den Segmenten über das Feld ZHYD verknüpft. Wichtige Felder in C_ZHYD Feld ZHYD Nextdown_ID Bas0_ID Outlet Surf Surfc Surffinal Geometry Code_Arbo Bedeutung Eindeutige ID des Catchments ID des nächsten stromabwärts liegenden FECs ID des übergeordneten Einzugsgebiets ID des letzten FECs (Mündung) des Basin Fläche des FECs in km² Summierte Fläche der stromaufwärts liegenden FECs in km² Surf + Surfc Enthält eine Sammlung von Polygonen, anhand derer das FEC dargestellt werden kann Berechneter String, der die Position des FECs im Basin Netzwerk beschreibt Beispielaufrufe Größe des Wisla -Einzugsgebietes in km 2 : SELECT SUM(Surf) FROM C_ZHYD WHERE Basinname= 'Wisla' EcrGaz Diese Datenbank umfasst alle relevanten Flussnamen und wird dafür verwendet, um die Internationalisierung der Flussnamen zu gewährleisten. Hier werden die Flüsse mit zugeordneten 9
festen IDs so verknüpft, dass für ausgewählten Sprachen Flussnamen zugewiesen werden. Die Datenbank EcrGaz hat zwei wichtige Tabellen: RivNames und RivNamesAlias. Wichtige Felder in RivNames Feld Riv_ID IntRname RivNameInSour Lge_RNIS Bedeutung ID des Flusses Internationaler Flussname (meist Englisch) Flussname in der Landessprache, in der die Quelle liegt Landessprache der Quelle Is_Main Flusslänge > 500 km? Len_ecrKm Len_2SeaKm Nb_Seg Is_exu RivLevel Flusslänge Entfernung bis zum Meer Anzahl der Segmente Erreicht der Fluss das Meer? Flusslevel (1 = Hauptfluss, 2 = Nebenfluss, ) ReceivingID ID des empfangenden Flusses; leer, wenn der Fluss ins Meer fließt Wichtige Felder in RivNamesAlias Diese Tabelle enthält alternative Namen für Fluss-IDs. Ein Fluss kann mehrere Namen haben, je nachdem aus welcher Quelle die Daten stammen. Deshalb können in dieser Tabelle zu einer Fluss-ID einer oder mehrere Einträge gefunden werden. Beispielaufrufe Alle Flüsse, deren Name Rhein beinhaltet: SELECT * FROM RivNames WHERE IntRname LIKE '%Rhein%' Catchment eines Flusses 1. Für jedes Segment eines Flusses (EcrRiv) wird das zugehörige Catchment aus der Datenbank EcrFEC gelesen. Man erhält alle Catchments zu dem Fluss (aber ohne die Catchments der Nebenflüsse). 2. Anhand der Code_Arbo -Spalte kann man das gesamte Einzugsgebiet eines Flusses berechnen. Dazu benötigt man den Wert der Code_Arbo -Spalte des letzten Catchments des Flusses. Die Code_Arbo -Werte aller flussaufwärts gelegenen Catchments haben diesen Wert als Basis, d.h. man kann Catchments aufgrund dieses Wertes selektieren. Rein technisch betrachtet ist diese Zuordnung derart gelöst, dass der Code-Arbo des letzten 10
Catchments (d.h. am nächsten zur Mündung) der Präfix aller weiterer stromaufwärts liegender Catchments ist. Beispiele Wie erhalte ich das Catchment zu einem Fluss anhand des Flussnamens? Möchte man nur das Catchment für den Fluss an sich haben, also ohne die Catchments der Nebenflüsse, kann man dies auf folgende Weise ermitteln: 1. Als Erstes wird aus der Tabelle RivNames der Datenbank EcrGaz die zugehörige river_id des Flusses ausgelesen. 2. Mit Hilfe der river_id kann man jetzt alle Segmente des Flusses auswählen. Dazu filtert man die Einträge der Tabelle C_Tr in der Datenbank EcrRiv nach dieser ID. 3. Für jedes Segment kann man nun das entsprechende Catchment aus der Tabelle C_Zhyd der Datenbank EcrRiv auslesen. Da jedes Segment über das Attribut zhyd mit dem zugehörigen Catchment verknüpft ist, kann man die Tabelle C_Zhyd danach filtern. Abbildung 3: FECs für einen Fluss anhand der zhyd So erhält man alle Catchments für den gesuchten Fluss, aber nicht unbedingt das komplette Einzugsgebiet. Denn die Catchments seiner Nebenflüsse werden unter Umständen nicht alle erfasst. Interessiert man sich hingegen für das gesamte Einzugsgebiet des Flusses, kann man die dazugehörigen Catchments auch auf eine andere Weise erhalten: 1. Analog zu dem obigen Beispiel benötigt man zuerst die river_id des Flusses. 2. Dann werden alle Segmente des Flusses ausgelesen. 3. Als nächstes wählt man das letzte Segment des Flusses, d.h. das Segment, das sich am weitesten stromabwärts befindet. 4. Von diesem Segment wählt man jetzt das zugehörige Catchment anhand der Spalte zhyd. 5. Dann liest man die code_arbo Spalte des eben selektierten Catchments aus. Der Wert dieser Spalte dient nämlich als Basis für alle stromaufwärts liegenden Abzweigungen, zuzüglich einer 1 oder 2 je nachdem welcher Zweig zuerst entdeckt wurde. 6. Nun erhält man alle Catchments, indem man die code_arbo Spalte nach dem entsprechenden Muster filtert. 11
Abbildung 4: FECs eines Flusses anhand der code_arbo Auf diese Art erhält man das komplette Einzugsgebiet des Flusses. Dasselbe Ergebnis bekommt man, wenn man für alle Nebenflüsse des gesuchten Flusses die Catchments ausliest, wie es im ersten Beispiel getan wurde. Abbildung 5: Ein Segment, ein Catchment 12
Abbildung 6: Zwei Segmente, zwei Catchments Abbildung 7: Mehrere Segmente, ein Catchment Anforderungsanalyse Eine der wichtigsten Anforderungen ist die Möglichkeit, Datensätze zu filtern. Es muss möglich sein, Flüsse nach Namen bzw. ID zu filtern. Diese Daten sollen auch mittels einer grafischen Oberfläche darstellbar sein, ohne dass komplette Datenlayer geladen werden müssen. Dies gilt ebenso für die Einzugsgebiete (Catchments) eines Flusses. Auch diese sollen gefiltert und angezeigt werden können. 13
Eine weitere Anforderung besteht darin, Nebenflüsse eines Flusses zu finden. Umgekehrt soll auch möglich sein, den Hauptfluss eines Flusses zu ermitteln (der Fluss, in den der Ursprungsfluss mündet). Weitere Themen sind zum Beispiel die Längenberechnung von Flüssen und Flächenberechnung von Catchments. Zusätzlich zu den oben genannten Anforderungen sollen die Datensätze und die Datenbankzugriffe so optimiert werden, dass für einzelne Anfragen möglichst wenig Zeit benötigt wird. Außerdem soll die finale Lösung plattformunabhängig und ohne kostenpflichtige Software umgesetzt werden. Eine genaue Aufstellung der Anforderungen an die Software ist im mitgelieferten Dokument Requirements.xlsx zu finden. Architektur Parallel zur Datenbankanalyse wurde die Softwarearchitektur erstellt. Der endgültigen Fassung wurde sich in mehreren Iterationen angenähert, sodass die Architektur bestmöglich den fortschreitenden Kenntnisstand der Projektgruppe bezüglich des Datenbanksystems widerspiegelte. Web-Architektur Bei der ersten Architektur handelte es sich um eine Web-Realisierung. Hierbei sollten Client und Server vollständig mit Web-Technologien umgesetzt werden. Folgende Abbildung verdeutlicht das Zusammenspiel der einzelnen Komponenten: Abbildung 8: Web-Architektur Auf der linken Seite ist der Client abgebildet, welcher aus mehreren Schichten besteht. Jede Schicht übernimmt eine eigens vorgesehene Aufgabe. Dabei wurde darauf geachtet, dass die Schichten auch unabhängig voneinander arbeiten können. Der Client-Controller sollte alle Informationen 14
verarbeiten, die er nach einem Request an den Server von diesem als Response erhält. Die verarbeiteten Informationen werden dann an das Frontend weitergeleitet und anschließend in der View angezeigt. Die zum damaligen Zeitpunkt verwendeten APIs sind links unten zu sehen. Der Server stellt die eigentliche Funktionalität zur Verfügung. Er besitzt auch mehrere Schichten, die nicht nur die Datenbankverbindungen und -anfragen regeln, sondern auch Programmlogik beinhalteten, um Berechnungen durchzuführen. Nachdem es sich aus dem Projektverlauf ergeben hatte, dass der Serverteil in Server und Java-API aufgespalten werden sollte, stellten wir die Webarchitektur auf eine Java-zentrierte Variante um. Web-Java-Architektur Als zweiten Ansatz realisierten wir die ehemalige Server-Architektur in Java, was in folgender Abbildung zu sehen ist: Abbildung 9: Web-Java-Architektur Im rechten Teil ist zu sehen, dass die Service- und Persistenz-Layer als einzelne Java APIs realisiert wurden. Der Persistenz-Layer kann in jedem beliebigen Java-Projekt eingebunden werden. Das Service-Layer-API beinhaltet mehrere Handler, welche verschiedene Protokolle bzw. Services nach außen anbietet. Die Clientarchitektur wurde nicht verändert. Da der Server mehrere Protokolle zur Verfügung stellt, spielt es keine Rolle, welchen GIS-Client man zur Abfrage und Anzeige der Daten verwendet. 15
API Allgemeines Das API (Application Programming Interface) dient als Schnittstelle zwischen Server und den zugrunde liegenden Datenbanken. Es stellt verschiedene Methoden zur Verfügung, mit denen die Daten selektiert werden können. Dazu bietet es mehrere Handler, welche eingehende HTTP- Requests behandeln und die gewünschten Daten zurück liefern. Aktuell verwendet das API die Spatialite-Dateien, die von ECRINS zur Verfügung gestellt werden und greift somit auf SQLite Datenbanken zu. Die Schnittstelle zu den Datenbanken wurde aber so implementiert, dass es ohne großen Aufwand möglich ist, eine andere Datenbank, wie zum Beispiel PostgreSQL, einzubinden. Rein technisch handelt es sich um ein JAVA-Projekt, welches als jar exportiert wurde und so als Bibliothek in jedes Projekt eingebunden werden kann. In diesem Fall wurde die Bibliothek in den Server eingebunden. Verwendete Bibliotheken Um auf die Datenbanken zuzugreifen und die Geometrie-Daten entsprechend aufzubereiten, wurden folgende Bibliotheken verwendet: sqlite-jdbc-3.8.7.jar: Hierbei handelt es sich um den SQLite-JDBC-Treiber, der notwendig ist um auf SQLite-Datenbanken über das JDBC API zuzugreifen. Die Bibliothek muss einfach in den Classpath aufgenommen werden und kann ohne weitere Einstellungen verwendet werden [6]. json-simple-1.1.1.jar: Stellt verschiedene Funktionen zu Verfügung, um mit JSON-Texten zu arbeiten. Wird verwendet um die Resultate der Abfragen in GeoJSON umzuwandeln [7]. guava-18.0.jar: Das Guava-Projekt enthält mehrere Core-Libraries von Google. Wir verwenden diese Bibliothek um die Ergebnisse eines HTTP-Requests im Cache zwischenzuspeichern, damit sie bei erneuter Abfrage schnell wieder verfügbar sind [8]. Aufbau Das API hat folgende Struktur: Abbildung 10: API-Struktur in Eclipse Im Folgenden wird genauer auf die einzelnen Packages und deren Inhalt eingegangen: 16
de.htwsaar.keras.db In diesem Package befinden sich alle relevanten Klassen um eine Verbindung mit der Datenbank aufzubauen und um die Anfragen an diese weiterzuleiten: Abbildung 11 Package db Die wichtigste Klasse ist EcrConnector. Dabei handelt es sich um eine abstrakte Klasse, welche die Methoden zum Aufbau einer Datenbankverbindung und zum Selektieren deiner Datenbank bereitstellt. Alle anderen Klassen erweitern diese abstrakte Klasse. de.htwsaar.keras.exceptions Dieses Package enthält eigene definierte Exceptions. Diese waren nötig, um im Fehlerfall genauer unterscheiden zu können, welcher Fehler vorliegt. Es wurden folgende neue Exceptions eingeführt: Abbildung 12: Package exceptions de.htwsaar.keras.generators Wie der Name des Packages schon vermuten lässt, enthält es die Generatoren, mit denen die Ergebnisse in das gewünschte Format umgewandelt werden können. Abbildung 13: Package generators Die Klasse GeoJSONGenerator kann die Ergebnisse in ein JSONObjekt umwandeln, welches sich an der Struktur von GeoJSON orientiert. Außerdem bietet die Klasse Funktionen um mit JSON-Objekten zu arbeiten. Die Klasse StringGenerator stellt hingegen Methoden zur Verfügung um die reinen Ergebnisse aus den Datenbanken in einen String umzuwandeln, welcher der Visualisierung während des Testens dient. de.htwsaar.keras.logic Dieses Package beinhaltet die Logik unserer API. Die hier enthaltenen Klassen stellen die Verbindung nach außen dar. 17
Abbildung 14: Package logic Die wichtigste Klasse ist RequestHandler. Nur die Methoden, die hier implementiert worden sind, sind nach außen hin sichtbar. Je nachdem welche Methode aufgerufen wird, baut der RequestHandler eine Verbindung zu der entsprechenden Datenbank auf, führt auf dieser die Abfrage aus und liefert das Ergebnis im gewünschten Format zurück. Bei den Klassen DBs und GeometryTypes handelt sich um Enums, die wir zur einheitlichen Benennung eingeführt haben. Die Klasse ForRequest implementiert einen neuen AnnotationType. Dieser wird verwendet, um alle Funktionen, die ausgeführt werden können, zu markieren. Diese können dann dementsprechend einer Anwendung, die diese API einbindet, geliefert werden (hier: die Serverkomponente). Bei dem RequestHandlerSingleDB handelt es sich um den Versuch, die Abfragen an die Datenbanken zu optimieren und das Problem zu lösen, welches auftritt, wenn man Tabellen von verschiedenen Datenbanken miteinander vereinigen will. Dazu wurde eine neue Datenbank angelegt, in der die drei Datenbanken EcrRiv, EcrFEC und EcrGaz enthalten sind. Außerdem wurde die neu entstandene Datenbank in den Hauptspeicher geladen. de.htwsaar.keras.multithreading Um die Performanz der Abfragen weiter zu optimieren haben wir schließlich einen RequestHandler implementiert, der in der Lage ist, Abfragen auf mehrere Anwendungsthreads zu verteilen. Dies ist möglich, da eine SQLite Datenbank bis zu 64 offene Verbindungen auf einmal verarbeiten kann. Um die Ergebnisse den richtigen Abfragen wieder zuordnen zu können, nutzen wir das Observer-Pattern. Alle Klassen, die mit dem Thema Multithreading zusammenhängen befinden sich in diesem Package. Abbildung 15: Package Multithreading Die Klasse MultiRequestHandler stellt analog zu den anderen RequestHandlern die Methoden zur Verfügung, die von außen aufgerufen werden können. Die tatsächliche Arbeit findet in den Klassen Operations und Selects statt. Der MultiRequestHandler startet für jeden Aufruf eine neue Operations-Instanz. Diese startet wiederum für jede Abfrage, die ausgeführt werden soll, eine Instanz der Klasse Selects. Jedes Select läuft in einem eigenen Thread, wodurch zeitgleich mehrere Abfragen auf einmal behandelt werden können. Mithilfe des Observer- Patterns, das in Operations und Selects implementiert wurde, können die Ergebnisse der einzelnen Threads erfasst und an die richtige Stelle zurück gegeben werden. 18
Die Klasse OperationsForOptDB ist analog zu der oben beschriebenen Operations Klasse aufgebaut, nur dass sie im Gegensatz dazu nicht auf die normalen Datenbanken zugreift, sondern auf von uns erzeugte. Server GUI und Benutzung Beim Server handelt es sich um einen HTTP-Server, welcher IP und Port zur Initialisierung benötigt. Bei der IP-Adresse handelt es sich um die lokale Adresse des Rechners, welche automatisch übernommen wird. Wurde der Port eingetragen, so müssen noch die Pfade für die SQLite- Datenbanken eingefügt werden. Nach Klick auf den Start-Button zeigt der Funktionen -Reiter alle zu Verfügung gestellten Methoden des Requesthandlers des APIs an. Wird eine Funktion angeklickt, so öffnet sich der Standardbrowser mit geladener URL zu dieser Funktion. Diese URL kann mit Argumenten parametriert werden. Im Anfragen -Reiter erscheinen alle Anfragen mit Funktionen, die an diesen Server gestellt wurden (dient also als Logfunktion). Der Error -Reiter ist im Moment deaktiviert. Alle Fehler, die im Server auftreten, werden in der Datei err.txt protokolliert. Die GUI wurde mit JavaFX-Technologie, namentlich dem JavaFX- Scene Builder 2.0 entworfen [9]. Abbildung 16: Server-GUI Schnittstellen Damit die Schnittstellen unabhängig voneinander funktionieren können, lädt der Server mit Hilfe der Reflection-Methoden alle implementierten Handler: 19
Abbildung 17: Dynamisches Laden der Handler Diese Handler stehen für verschiedene Services wie WMS, JSON oder XML. Damit diese Services korrekt funktionieren, müssen die konkreten Handler erst fertig implementiert oder erweitert werden. Im Moment bietet der Server nur den JSON Service als proof of concept an. Bibliotheken Im Server wurden mehrere APIs verwendet. Alle sind open source und können frei verwendet werden: Abbildung 18: Server-Bibliotheken KerasDB bezeichnet das eigens entwickelte Java-API, welches keine weiteren Abhängigkeiten aufweist. 20
Client Der entwickelte Client ist eine Web-Anwendung, welche mit einem regulären Internetbrowser benutzt werden kann (auch auf mobilen Geräten). Er hat die Aufgabe, Daten in verschiedenen Formaten (GeoJSON, JSON, XML, etc.) zu interpretieren und auf einer Hintergrundkarte darzustellen, oder dem Benutzer sonstige in den Daten enthaltene Informationen zu visualisieren. Um dies zu realisieren, sendet der Client nach Benutzereingaben einen Request an einen Server, welcher diesen Request mit einem Datenresponse beantwortet. In unserem Fall erfüllt der im vorigen Abschnitt beschriebene Server in Kombination mit dem Java-API diese Aufgabe. Bibliotheken Der Client verwendet zwei Bibliotheken, welche im Folgenden kurz erläutert werden. OpenLayers OpenLayers ist in der Programmiersprache Javascript entwickelt und durch die Implementierung mehrerer Schnittstellen unabhängig von der eingesetzten Serversoftware. Das Programm stellt typische Webmapping-Elemente bereit, wie zum Beispiel eine Skala zum Verändern des dargestellten Maßstabs [10]. Mittels Editierelementen können dargestellte Karten konfiguriert werden. Beispielsweise kann ein Marker platziert werden. Als Zielgruppe gibt OpenLayers Anwender und Entwickler an, welche eine Karte im Internet darstellen oder eine kartenbasierte Anwendung erstellen möchten. Es wurde jahrelang auf der Startseite von OpenStreetMap und unter anderem bei dem schweizerischen Geoportal des Bundes verwendet. Im Jahr 2008 wurde OpenLayers als Projekt bei der Open Source Geospatial Foundation aufgenommen und ist open source. Die Kommunikation im Projekt erfolgt über Mailinglisten in englischer Sprache. AngularJS AngularJS oft einfach als Angular bezeichnet ist ein open-source-framework von Google. Mit AngularJS kann man in HTML und Javascript single-page-webanwendungen nach einem Model-View- ViewModel-Muster erstellen [11]. Die Softwareentwicklung und das Testen von Komponenten können damit vereinfacht werden. Grafische Oberfläche Auf der Hauptoberfläche sieht man im Standard zentral eine OpenStreetMap-Karte von Deutschland, welche auf Köln zentriert ist. Es besteht die Möglichkeit, die Ansicht zu zoomen, indem man einen der +/- Buttons im linken oberen Bereich der Karte drückt. Dort gelangt man auch in das Hauptmenü der Anwendung. 21
Dieses Menü besteht aus folgenden Punkten: Abbildung 19: Client-Oberfläche beim Start Zeige Fluss: Direkter Zugriff auf die Flusssuche anhand des Flussnamens. Zeige CapabilitiesDialog: Öffnet ein Fenster, welches den Server nach den verfügbaren Capabilities abfragt und diese in einem gesonderten Fenster darstellt. Allgemeine Optionen: Hier sind bisher nur IP und Port des Servers einstellbar. Es werden in naher Zukunft weitere Einstellmöglichkeiten wie Farben, Ansicht etc. verfügbar sein. WMS-Optionen: Hier können verfügbare Layer beim Server abgefragt und bei Bedarf als Kartenmaterial verwendet werden. WFS-Optionen: Hier ist es möglich, sechs Operationen an den Server zu stellen o GetCapabilities: Hierbei wird nach den Fähigkeiten des WFS gefragt. Als Antwort wird ein XML-Dokument an den Client zurückgeschickt, das neben allgemeinen Angaben zum Anbieter des WFS die abfragbaren Feature Types und die möglichen Operationen beinhaltet. o DescribeFeatureType: Bei dieser Anfrage werden Informationen zur Struktur der einzelnen Feature Types zurückgegeben. o GetFeature: Mit diesem Request werden die einzelnen Feature-Instanzen, d.h. die eigentlichen Daten zurückgegeben. Es sollte möglich sein, dass bei der Anfrage näher spezifiziert wird, welche Eigenschaften des Features zurückgegeben werden und ob diese räumliche Informationen beinhalten. o GetGmlObject: Eine WFS-Abfrage ist im Ergebnis immer eine GML-Datei. Mit dieser Anfrage ist es möglich, einzelne Elemente aus der GML-Datei per XLink zu erhalten. o Transaction: Ein WFS kann Anfragen der Transaktion bereitstellen, d.h. hat die Möglichkeit die eigentlichen Features in der Datenbasis zu ändern. Darunter fällt das Anlegen, die Aktualisierung und das Löschen geographischer Features. o LockFeature: Hiermit wird vom WFS gewährleistet, dass bei einer Operation auf einem Feature Type, dieser nicht während der Transaktion von einer anderen Instanz geändert wird. 22
LayerListe: Hier werden alle auf der Karte eingeblendeten Layer gelistet. Es besteht die Möglichkeit diese ein- und auszublenden oder beispielsweise die Farbe des Elemente innerhalb des jeweiligen Layers zu ändern. Zum jetzigen Zeitpunkt unterstützt der Server bei den WFS-Optionen nur GetCapabilities, die anderen Funktionen sind aber bereits angedacht und in ihrer Struktur vollständig in die Client- Architektur integriert. Abbildung 20: Hauptmenü des Clients Beispielprozess Im Folgenden wird ein beispielhafter Ablauf veranschaulicht, bei welchem ein Benutzer sich unter danderem alle Knoten des Flusses Saar visualisieren lassen möchte. Klickt der Benutzer auf den Button Zeige Fluss, wird ein neues Dialogfenster geöffnet, mit dem es möglich ist, einen Flussnamen einzugeben: Abbildung 21: Dialogfenster Flussname 23
Gibt der Benutzer dort Saar ein, wird folgender Request an den Server gesendet: http://127.0.0.1:8000/json?request=getgeometrybyname&names=[saar]&ge ometrytypes=[node] Wenn die Client-Server-Kommunikation beendet ist (Ladebalken verschwunden), wird das Ergebnis auf der standardmäßig eingestellten Karte visualisiert: Abbildung 22: Ladebalken während Prozessierung Abbildung 23: Ergebnisdarstellung Anschließend besteht die Möglichkeit, im unteren Teil der Oberfläche einen anderen Kartenlayer auszuwählen, hier Satellit. 24
Abbildung 24: Satelliten-Layer Über den Menüpunkt WMS-Optionen können weitere Layer hinzugefügt werden: Abbildung 25: Funktion "WMS-Optionen" Will man nun den Layer, welcher den Fluss enthält, ausblenden oder bearbeiten, ist dies über den Menüpunkt LayerListe möglich. Hier findet man den entsprechenden Request( Saar ) und die Möglichkeit, diesen ein- und auszublenden. Soll der jeweilige Layer bearbeitet werden, genügt ein einfacher Klick auf den jeweiligen Request innerhalb der Liste. Dieses Vorgehen ermöglicht das schrittweise Zuschalten weiterer Flussdaten. Außerdem lassen sich grundlegende visuelle Eigenschaften wie Farbe und Dicke der Daten auf der Karte ändern. 25
Abbildung 26: Layerliste Abbildung 27: Styling-Optionen Layerliste Ein weiterer Menübutton im Hauptmenü ist Zeige Capabilities Dialog. Er ermöglicht, die Funktionen des Servers abzufragen: 26
Abbildung 28: Abfragen der Capabilities Das entsprechende Request hat folgenden Aufbau: http://127.0.0.1:8000/json?request?request=getcapabilities Der Server antwortet mit einem XML-Dokument worin er alle Informationen auflistet, die er zur Verfügung hat. Der Client interpretiert diese und baut anhanddessen ein Fenster auf. Am Anfang stehen alle allgemeinen Informationen: Abbildung 29: Basisinformationen Capabilities Es folgen alle verfügbaren Methoden, welche natürlich auch voll funktionsfähig vom Client ausgeführt werden können: 27
Abbildung 30: Konkrete Capabilities als Funktionen Am unteren Ende des Hauptfensters ist darüber hinaus noch ein Button zu finden, welcher die aktuelle Sicht auf die Karte als Bilddatei auf das lokale Dateisystem des Benutzers exportiert. Abbildung 31: Export als Bilddatei Programmierung Hier soll grob erläutert werden, welchen Konzepten die Client-Programmierung zugrunde liegt. Da Angular nach best practice einer gewissen Projektstruktur unterliegt, wurde diese auch innerhalb dieser Projektarbeit beibehalten. Es wurde sich darüber hinaus für ein Tool entschieden, welches eine Art Skelett für die eigentliche Web-App darstellt ( angular-seed ) [12]: app/ app.css components/ --> all of the source files for the application --> default stylesheet --> all app specific modules 28
version/ --> version related components version.js --> version module declaration and basic "version" value service version_test.js --> "version" value service tests version-directive.js --> custom directive that returns the current app version version-directive_test.js --> version directive tests interpolate-filter.js --> custom interpolation filter interpolate-filter_test.js --> interpolate filter tests view1/ --> the view1 view template and logic view1.html --> the partial template view1.js --> the controller logic view1_test.js --> tests of the controller view2/ --> the view2 view template and logic view2.html --> the partial template view2.js --> the controller logic view2_test.js --> tests of the controller app.js --> main application module index.html --> app layout file (the main html template file of the app) index-async.html --> just like index.html, but loads js files asynchronously karma.conf.js --> config file for running unit tests with Karma e2e-tests/ --> end-to-end tests protractor-conf.js --> Protractor config file scenarios.js --> end-to-end scenarios to be run by Protractor Das Projekt selber besteht bisher aus 8 Javascript-Klassen: 1. AppFunctions: Hier sind alle Hauptfunktionen wie der Konstruktor der Map und die Funktionalität von modalen Dialogen hinterlegt. 2. Layers: o Normal Open StreetMap o Satellite o Satellite + Open StreepMap 3. StyleFunctions: Alle Funktionen, die zum Stylen der App dienen, unter anderen auch die der einzelnen Layer. 4. App: Enthält den Starter von angularjs. 5. Controller: Hier sind alle Controller und Directives hinterlegt. 6. Exception: Alle Fehlermeldungen und deren Prüfung. 7. GuiBuilder: Eine Klasse, die aus einem XML-Dokument eine Web-Oberfläche aufbauen kann. Wird beispielsweise bei GetCapabilities benötigt. 8. HTTPCommunication: Enthält alle Abfragen, welche mittels Ajax an den Server gesendet werden. Alle Funktionen sind wie von Angular verlangt in der Klasse Controller hinterlegt und dem jeweiligen Template zugeordnet: 29
Fazit Abbildung 32: Funktionsregistrierung im Controller Ergebnis Analog zu der eingangs formulierten Aufgabenstellung und dem Ziel dieses Masterprojektes lassen sich die erarbeiteten Ergebnisse in zwei Bereiche einteilen: einerseits die Datenbankanalyse als Wissensgrundlage und andererseits die Softwareentwicklung, welche wiederum die Einzelprodukte Java-API, Webserver und Client hervorgebracht hat. Jede der drei Softwares ist alleine lauffähig und funktional. Den besten Eindruck von der Funktionalität bzw. der webbasierten Kommunikation der drei Systeme erhält man natürlich nur im Zusammenspiel der Komponenten. Es konnte der komplette Informationsfluss von Eingabe des Benutzers im Client, Requesthandling im Server und Datenbeschaffung bzw. Berechnungen im API implementiert werden, sodass das Projektziel erfüllt werden konnte. Schwierigkeiten In zwei Bereichen traten während des Projektes Schwierigkeiten auf. Zuerst ist hier die Datenbankanalyse zu nennen, da ECRINS als Info-System unseres Erachtens nach nicht besonders zugänglich ist, sondern eine sehr empirische Herangehensweise durch konsequentes Ermitteln und Überprüfen von Daten erfordert. Auf technischer Ebene existiert das Problem der verschiedenen Technologien. Es wurde eine Kombination von Java-Software ohne GUI (API), Java-Software mit GUI (Server) und einer Web-Anwendung (Client) entwickelt, was jeweils ganz eigene Herausforderungen bot. Hilfreich dabei war die Heterogenität des Teams mit spezialisierten Mitgliedern im Desktopbzw. Web-Bereich, sodass die Verteilung von Zuständigkeiten leicht fiel. Ausblick Im Anschluss an die Projektarbeit können verschiedene kleinere Punkte optimiert und erweitert werden. Dies betrifft beispielsweise das Hinzufügen neuer Funktionen und Algorithmen in der Datenbanklogik. Ein großer Fokus lag während der Software-Konzeption aber auf einer generischen Architektur, sodass solche Erweiterungen in äußerst kurzer Zeit umgesetzt und integriert werden können. 30
Schlussbetrachtung Abschließend betrachtet ist festzustellen, dass das Projekt aufgrund seiner breiten Natur eine besondere Herausforderung darstellte. Bereits die Datenbankanalyse beanspruchte aufgrund des Umfangs der Datenbanken einen Großteil der verfügbaren Zeit. Gleichzeitig war sie in ihrer Detaillierung notwendig, da die Struktur der Datenbanken direkt Konzeption, Entwicklung sowie das Zusammenspiel der Softwareprodukte mitbestimmte. Obwohl, wie bereits im Abschnitt Ausblick geschildert, noch Erweiterungsbedarf der Software besteht, sind alle drei Produkte implementiert, lauffähig und dokumentiert. Mit ihnen lassen sich bereits grundlegende Datenbankalgorithmen und Abfragefunktionen durchführen. Ihre Schnittstellen sind generisch gehalten, sodass vor allem Client und API auch in weitergehenden Projekten benutzt werden können. Uns persönlich hat das Projekt geholfen, unsere Kenntnisse im Bereich der Interoperabilität von Software, sowie der Analyse komplexer Datenmodelle zu vertiefen und außerdem ein Gefühl für die massiven Datenmengen eines realen ökologischen Informationssystems zu bekommen. 31
Quellen [1] E. E. Agency, European catchments and Rivers network system, 20 März 2015. [Online]. Available: http://www.eea.europa.eu/data-and-maps/data/european-catchments-and-riversnetwork. [2] Open Geospatial Consortium, 20 März 2015. [Online]. Available: http://www.opengeospatial.org/. [3] OGC Standards and Supporting Documents, 20 März 2015. [Online]. Available: http://www.opengeospatial.org/standards. [4] Home, [Online]. Available: http://www.qgis.org/de/site/about/index.html. [Zugriff am 20 März 2015]. [5] QGis, Funktionalität, 20 März 2015. [Online]. Available: http://docs.qgis.org/2.6/de/docs/user_manual/preamble/features.html. [6] SQLite JDBC Driver, 20 März 2015. [Online]. Available: https://bitbucket.org/xerial/sqlite-jdbc. [7] Json-Simple, 20 März 2015. [Online]. Available: https://code.google.com/p/json-simple/. [8] Guava: Google Core Libraries for Java, 20 März 2015. [Online]. Available: https://github.com/google/guava. [9] JavaFX, 20 März 2015. [Online]. Available: http://docs.oracle.com/javase/8/javaseclienttechnologies.htm. [10] Open Layers 3, 20 März 2015. [Online]. Available: http://openlayers.org/. [11] Angular JS, 20 März 2015. [Online]. Available: https://angularjs.org/. [12] A. Seed, Directory Layout, 20 März 2015. [Online]. Available: https://github.com/angular/angular-seed#directory-layout. 32