Diplomarbeit: Geografische Informationssysteme zur
Werbung
Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Diplomarbeit bei Firma TechniData AG Dornierstr. 3 D-88677 Markdorf vorgelegt von Ralf Bierig an der Fachhochschule Furtwangen Fachbereich Informatik Studiengang Allgemeine Informatik 28. August 2002 Betreuer der Firma TechniData AG: Betreuer der Fachhochschule: Jörg. Beier Prof. Dr. Mohsen Rezagholi Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Inhaltsverzeichnis Abbildungsverzeichnis...............................................................................................................5 Tabellenverzeichnis....................................................................................................................6 1 Allgemeines ........................................................................................................................7 1.1 Firmenprofil ..............................................................................................................................7 1.2 Aufgabenstellung.......................................................................................................................7 2 Einführung in Geografische Informationssysteme ..........................................................9 2.1 Begriffsdefinition.......................................................................................................................9 2.2 Welche Möglichkeiten eröffnet GIS? ....................................................................................11 2.3 GIS Einsatzgebiete ..................................................................................................................12 2.4 Datenarten ...............................................................................................................................12 2.4.1 Geometriedaten .............................................................................................................................. 12 2.4.1.1 Rasterdaten ................................................................................................................................ 13 2.4.1.2 Vektordaten ............................................................................................................................... 13 2.4.1.3 Fazit Vektor / Rasterdaten ......................................................................................................... 14 2.4.2 Attributdaten .................................................................................................................................. 14 2.4.3 Zeitdaten ........................................................................................................................................ 15 2.4.4 Prozessdaten................................................................................................................................... 15 2.5 Datenstrukturierung mit Layern ...........................................................................................16 2.6 Datenorganisation ...................................................................................................................17 2.6.1 2.6.2 2.6.3 3 Einzelplatzsystem .......................................................................................................................... 17 Mehrplatzsysteme .......................................................................................................................... 17 Intra-/Internet ................................................................................................................................. 17 Produktanalyse.................................................................................................................19 3.1 Altsysteme von TechniData ....................................................................................................19 3.1.1 3.1.2 3.1.3 Das OBLIS System ........................................................................................................................ 19 INES RAD ..................................................................................................................................... 20 UGI GISView von WiGeoGIS....................................................................................................... 20 3.2 ENVINET NMC von TechniData ..........................................................................................21 3.2.1 Einführung ..................................................................................................................................... 21 3.2.2 Der Aufbau von ENVINET-NMC ................................................................................................. 22 3.2.2.1 Presentation Layer ..................................................................................................................... 23 3.2.2.2 Data Access Layer..................................................................................................................... 24 3.2.2.3 Business Layer .......................................................................................................................... 24 3.3 ENVINET DAISY von TechniData .......................................................................................25 3.3.1 3.3.2 DAISY Client Komponenten ......................................................................................................... 25 DAISY Server Komponenten ........................................................................................................ 26 3.4 Grobevaluierung freier und kommerzieller Java GIS API‘s ..............................................27 3.4.1 Freie Java GIS ................................................................................................................................ 27 3.4.1.1 DEMViewer mit VisAD Bibliothek .......................................................................................... 27 3.4.1.2 GISToolkit ................................................................................................................................ 27 3.4.1.3 JaGo .......................................................................................................................................... 28 3.4.2 Kommerzielle Java GIS ................................................................................................................. 28 3.4.2.1 ActiveMaps ............................................................................................................................... 28 3.4.2.2 GISTerm.................................................................................................................................... 28 3.4.2.3 Map Objects for Java................................................................................................................. 29 3.5 Feinevaluierung anhand einer Featureübersicht .................................................................29 Seite 2 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 3.5.1 Featuretabelle ................................................................................................................................. 29 3.5.2 Featurebeschreibung ...................................................................................................................... 33 3.5.2.1 Navigation ................................................................................................................................. 33 3.5.2.2 Visualisierung ........................................................................................................................... 33 3.5.2.3 Selektion.................................................................................................................................... 34 3.5.2.4 Attributdatenabfrage.................................................................................................................. 34 3.5.2.5 Layerfeatures ............................................................................................................................. 34 3.5.2.6 Datenformate / Schnittstellen .................................................................................................... 35 3.5.2.7 Sonstige Features ...................................................................................................................... 36 3.5.3 Fazit ............................................................................................................................................... 36 4 Spezifikation des Prototypen............................................................................................37 4.1 Anforderungen und Rahmenbedingungen ...........................................................................37 4.1.1 Einordnung des Prototyps in NMC / DAISY ................................................................................. 37 4.1.2 Anwendungsfallanalyse ................................................................................................................. 39 4.1.3 Pflichtenheft ................................................................................................................................... 41 4.1.4 Architekturanalyse ......................................................................................................................... 41 4.1.5 Evaluierung verschiedener Kernkonzepte ...................................................................................... 42 4.1.5.1 Grafische Repräsentation von Stationspunkten ......................................................................... 42 4.1.5.2 Erkennung eines Mausklicks auf einem Stationspunkt ............................................................. 44 4.2 Objektorientiertes Design.......................................................................................................47 4.2.1 UML Klassendiagramme ............................................................................................................... 47 4.2.1.1 Hauptapplikation ....................................................................................................................... 48 4.2.1.2 DrawLayer................................................................................................................................. 49 4.2.1.3 Kartenkonfigurations- und Modelklassen ................................................................................. 51 4.2.1.4 Storeklassen............................................................................................................................... 52 4.2.2 Datenmodel der Kartenkonfiguration ............................................................................................ 53 5 Implementierung ..............................................................................................................54 5.1 Implementierung der logischen Klassen ...............................................................................54 5.1.1 Modelklassen LayerSource und MapConfigurationModel ............................................................ 54 5.1.2 DrawLayer und GISFeature ........................................................................................................... 54 5.1.2.1 Synchronisation mit der Hauptselektion ................................................................................... 54 5.1.2.2 Grafische Repräsentation von Stationspunkten ......................................................................... 55 5.1.2.3 Verwaltung der Stationspunkte als GISFeature Objekte ........................................................... 56 5.1.2.4 Laden einer ValueSeries aus der Datenbank ............................................................................. 56 5.1.3 Storeklassen ................................................................................................................................... 57 5.2 Implementierung der grafischen Klassen .............................................................................57 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 MapConfigurationFrame und SubPanelLayerChooser .................................................................. 57 FeaturePopupMenu und PropertyDialog ........................................................................................ 58 SelektionToolBar ........................................................................................................................... 59 TimeToolBar .................................................................................................................................. 59 MapShowFrame und MapShowFrameUI ...................................................................................... 60 5.3 Datenbankeinträge zur Visualisierung im NMC Explorer .................................................61 5.4 Review des Pflichtenheftes .....................................................................................................62 6 Zusammenfassung und Ausblick ....................................................................................64 6.1 Bewertung der MapObjects Java API ..................................................................................64 6.1.1 6.1.2 6.1.3 Pro .................................................................................................................................................. 64 Contra............................................................................................................................................. 65 Fazit: Pro MapObjects Java ........................................................................................................... 66 6.2 Ausblick ...................................................................................................................................66 6.2.1 6.2.2 6.2.3 6.2.4 Schnittstellenerweiterungen ........................................................................................................... 66 Verbesserung der Konfigurierbarkeit ............................................................................................. 66 Automatische Generierung von Bildern ......................................................................................... 67 Automatische Generierung einer Animation.................................................................................. 67 Literaturverzeichnis.................................................................................................................68 Seite 3 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Internetquellen.........................................................................................................................69 Eidesstattliche Erklärung........................................................................................................70 Seite 4 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Abbildungsverzeichnis Abbildung 2-1: Realwelt / Modellwelt ......................................................................................10 Abbildung 2-2: Layerkonzept (Quelle: [http://www.gis.com/whatisgis/index.html])...............16 Abbildung 3-1: TechniData Messnetzsysteme und GIS ............................................................19 Abbildung 3-2: INES RAD von DIC Solutions Augsburg .........................................................20 Abbildung 3-3: NMC Funktionalität (Quelle: [NMC]) ............................................................22 Abbildung 3-4: NMC Komponenten (Quelle: Eigene Darstellung in Anlehnung an [NMC]) .23 Abbildung 4-1: Java GIS Prototyp in NMC / DAISY (Quelle: Eigene Darstellung in Anlehnung an [NMC]) ..............................................................................................................37 Abbildung 4-2: NMC Präsentation Layer Oberfläche .............................................................38 Abbildung 4-3: Anwendungsfalldiagramm ...............................................................................39 Abbildung 4-4: Layer in MapObjects (Quelle: [MapO]) .........................................................42 Abbildung 4-5: DrawLayer generiert temporäre Shape Datei .................................................44 Abbildung 4-6: Algorithmus zur Featureerkennung .................................................................46 Abbildung 4-7: Beispiele für Stationspunkterkennung .............................................................46 Abbildung 4-8: UML Klassendiagramm der Hauptapplikation ...............................................48 Abbildung 4-9: UML Klassendiagramm des DrawLayer .........................................................49 Abbildung 4-10: UML Klassendiagramm der Kartenkonfiguration mit Modellklassen ..........51 Abbildung 4-11: UML Klassendiagramm der Storeklassen .....................................................52 Abbildung 4-12: Datenmodell zur Speicherung der Kartenkonfiguration ...............................53 Abbildung 5-1: MapConfigurationFrame mit SubPanelLayerChooser ...................................57 Abbildung 5-2: FeaturePopupMenu .........................................................................................58 Abbildung 5-3: PropertyDialog ................................................................................................59 Abbildung 5-4: SelectionToolBar .............................................................................................59 Abbildung 5-5: TimeToolBar ....................................................................................................60 Abbildung 5-6: Java GIS Prototyp Screenshot .........................................................................63 Abbildung 6-1: Fehlende Unterstützung von Koordinatentransformationen (Quelle: http://forums.esri.com/Thread.asp?c=9&f=1193&t=69344&mc=10)....................................65 Seite 5 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Tabellenverzeichnis Tabelle 2-1 Bezeichnungen für Geografische Informationssysteme........................................11 Tabelle 2-2: Speicherplatzbedarf für Karten (Quelle: [Saur97], S. 70) ..................................13 Tabelle 2-3: Vor- und Nachteile von Vektor- und Rastermodell (Quelle: [Saur97] Seite 77) .14 Tabelle 3-1: Featuretabelle ......................................................................................................32 Tabelle 4-1: Pflichtenheft des Prototypen ................................................................................41 Tabelle 4-2: Zuordnung von Modellklassen, Storeklassen und DB-Tabellen ..........................52 Tabelle 5-1: NMC Datenbankeinträge .....................................................................................61 Tabelle 5-2: Review des Pflichtenheftes ...................................................................................62 Seite 6 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 1 Allgemeines 1.1 Firmenprofil Die Firma TechniData AG ist der international führende Anbieter von EH&S ® (Environment, Health & Safety) – Lösungen. Bereits seit 1985 beschäftigt sie sich mit der Entwicklung innovativer Softwarelösungen und Dienstleistungen im Bereich Umwelt- und Sicherheitsmanagement. Ihre umfassende Erfahrung bei der Vernetzung aller umwelt- und sicherheitsrelevanten Daten in Unternehmen hat sie zum Entwicklungspartner der SAP gemacht. Hinter jeder SAP EH&SLösung finden Sie somit auch immer das Know-how und die Kompetenz von TechniData. Neben der Industrie vertrauen auch Behörden und öffentliche Institutionen auf TechniData’s EH&S-Lösungen. Mit ENVINET hat sie auf der ganzen Welt Messnetze geschaffen, mit deren Hilfe die entsprechenden Behörden der einzelnen Länder und Regionen umweltrelevante Daten aus den Bereichen Luft, Radioaktivität, Wasser und Meteorologie messen, zusammenführen, interpretieren und präsentieren können. TechniData beschäftigt heute mehr als 220 Mitarbeiter an den Standorten Markdorf, Frankfurt, Karlsruhe, Kirchdorf und München. Mehrheitsbeteiligungen an drei weiteren Unternehmen formieren die TechniData-Gruppe 1. 1.2 Aufgabenstellung Geografische Informationssysteme gewinnen zunehmend an Bedeutung, da sie sich gut für die Visualisierung umfangreicher georefenzierbarer Daten eignen. Im Bereich der Visualisierung spielen Java GIS eine zunehmend wichtigere Rolle. Die Diplomarbeit soll zeigen, welche Möglichkeiten Java basierte GIS Systeme bieten, welche Funktionen im Bereich der Visualisierung von Umweltmessdaten möglich sind und ob eine gewinnbringende Integration in die bestehende Messnetzsoftware von TechniData möglich ist. Dies soll anhand eines Prototypes gezeigt werden. Die Diplomarbeit schließt folgende Teilaufgaben ein: 1. Erstellung einer Übersicht allgemeiner GIS Begriffsdefinitionen und Funktionalitäten als theoretisches Fundament der Diplomarbeit. 2. Erstellung einer Zusammenfassung über die von TechniData eingesetzten Messnetzsysteme und GIS Lösungen. 1 Vgl. [http://www.technidata.de] Seite 7 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 3. Erstellen einer Marktübersicht aktueller, verfügbarer Java GIS Klassensammlungen. Der Funktionsumfang der von TechniData bislang eingesetzten GIS soll dabei die Grundlage für die Bewertung liefern. Basierend auf dieser Übersicht soll eine Java GIS API ausgewählt werden, die dann für die Implementierung des Prototypes verwendet werden soll. 4. Spezifikation und Erstellung des Prototypes mit Implementierung, Integration und Anpassung an NMC / DAISY. 5. Bewertung der Möglichkeiten der gewählten Java GIS API im Hinblick auf Umsetzbarkeit und Aufwand. 6. Ausblick Seite 8 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 2 Einführung in Geografische Informationssysteme 2.1 Begriffsdefinition Bevor festlegt werden kann, was ein Geografisches Informationssystem (kurz GIS) ist, muss zuvor definiert werden, was man sich unter einem Informationssystem generell vorstellen kann. Informationssysteme modellieren immer einen Teil unserer realen Welt, da eine vollständige Betrachtung auf Grund der hohen Komplexität nicht möglich und meist auch nicht notwendig ist. Diese Modellierung vollzieht sich durch Sammlung von Informationen und der Anwendung geeigneter Methoden, diese Daten auszuwerten. Göpfert leitet den Begriff des Informationssystems sehr schön über den der Daten bzw. Datenbanken her: „Eine digitale Information über ein Objekt wird als Datensatz bezeichnet. Fachliche und sachlich zusammengehörige Datensätze ... werden mit dem Ausdruck Datenbank belegt. Die Gesamtheit mehrerer Datenbanken in Verbindung mit geeigneten Datenverwaltungs- und Datenbearbeitungsprogrammen bilden ein Informationssystem.“ 2 Nach Sauer/Behr liegt die Aufgabe eines Informationssystems in der „Verwaltung von Primärinformation und der Ableitung von implizit darin enthaltener Sekundärinformation“ 3, was geschickt an die vorherige Definition anknüpft. Mit diesen beiden Definitionen kommt man zum Schluss, dass ein Informationssystem die Erweiterung einer oder mehrerer Datenbanken um zusätzliche Software darstellt, die aus den bestehenden Daten neue Erkenntnisse erzielt. Ein GIS stellt eine Spezialisierung eines Informationssystems für räumlich assoziierte Daten dar. 2 3 [Goepf87] [Saur97], Seite 4f Seite 9 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Abbildung 2-1: Realwelt / Modellwelt Dieter Fritsch stellt in seinem Buch fest: „Ein Geo-Informationssystem ist ein rechnergestütztes System, das aus Hardware, Software, Daten und den Anwendungen besteht. Mit ihm können raumbezogene Daten digital erfasst und redigiert, gespeichert und reorganisiert, modelliert und analysiert sowie alphanumerisch und grafisch präsentiert werden.“ 4 Eine weitere gute Definition für ein GIS kommt von Wilkinson, der es als „system containing a spatial database representing aspects of the cultural and physical environment of a particular geographic region together with precedures for analysing combinations of attributes and generating graphical or statistical products“ 5 beschreibt. Hier muss angemerkt werden, dass viele GIS ihre gesamten Daten nicht in einer zentralen Datenbank halten, sondern oft hybride Datensysteme existieren. Meist werden Kartendaten dateibasiert verwaltet und mit Datenbankdaten kombiniert. 4 5 [Frit94], S. 5 [Wilk86], S. 1-1 Seite 10 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Zusammenfassend komme ich schließlich zur folgenden Definition: Ein geografisches Informationssystem ist ein Computersystem, das in der Lage ist, geografisch referenzierte Informationen zu verarbeiten. Um diese Aufgabe adäquat zu lösen, besteht ein GIS aus folgenden Komponenten: • Software • Hardware • Daten (Karten-, Objekt-, Prozess- und Zeitdaten) Da geografische Informationssysteme nicht zu den typischen Standardapplikationen gehören, ist es außerdem noch notwendig, über das entsprechend ausgebildete Fachpersonal zu verfügen, das in der Lage ist das System zu bedienen. Für geografische Informationssysteme existieren noch weitere Begriffe, die sich in der einschlägigen Literatur 6 finden und z. T. spezielle GIS Anwendungen darstellen. Abkürzung FIS KIS NIS RIS UIS Bedeutung Fachinformationssystem Kommunales Informationssystem Netzinformationssystem Rauminformationssystem Umweltinformationssystem Tabelle 2-1 Bezeichnungen für Geografische Informationssysteme 2.2 Welche Möglichkeiten eröffnet GIS? a) Lokationsbasierte Datenabfrage: Generell ermöglicht GIS die Abfrage, was sich wo befindet. Es können Daten ermittelt werden, die sich in einem bestimmten Gebiet oder Umkreis befinden. b) Effektlokation: Effekte, die in einer Datentabelle nur sehr schlecht erkannt werden können, werden durch die kartenbasierte, räumliche Darstellung eines GIS schneller sichtbar und können durch die vielfältigen Visualisierungsmöglichkeiten übersichtlicher dargestellt werden. c) Zeitliche Veränderung: Der zeitliche Verlauf von Effekten, wie z.B. Hochwasser, kann durch regelmäßige Messungen ermittelt und somit beobachtet werden. d) Mustererkennung: Wiederkehrende Erscheinungen und Abläufe können erkannt und z.B. zur Früherkennung einsetzt werden. 6 z.B. für Netzinformationssysteme in [Saur97], S. 190-193 Seite 11 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten e) Tests und Experimente: Wenn ausreichend Daten vorhanden sind, können mögliche Szenarien simuliert werden um evtl. Auswirkungen auf die Umwelt im Voraus zu erkennen. 2.3 GIS Einsatzgebiete Geografische Informationssysteme finden überall dort Anwendung, wo mit räumlich referenzierten Daten gearbeitet wird. Entsprechend vielseitig sind die möglichen Anwendungsgebiete. GIS findet man z.B. in a) b) c) d) e) f) g) h) Umweltschutz und -überwachung Verkehrs/Routenplanung Rettungswesen Telekommunikation Bergbau und Mineralölindustrie Transportlogistik Land- u. Forstwirtschaft Marketing 2.4 Datenarten Die Daten eines GIS bilden seinen Kern, da von ihnen die Qualität aller darauf aufbauenden Arbeitsschritte und deren Ergebnisse abhängt. GIS Daten kann man grob in vier Gruppen unterteilen: a) b) c) d) Geometriedaten Attributdaten Zeitdaten Prozessdaten 2.4.1 Geometriedaten Geometriedaten sind notwendig um die Lage eines Objektes im Raum zu beschreiben. Dies wird meist mit Koordinaten gelöst. Auch ist es möglich, Adressen oder andere eindeutige Abbildungen zu verwenden. Das Ziel ist es, den Objekten eine räumliche Referenz zuzuweisen, mittels derer sie z.B. in eine Karte eingezeichnet und wiedergefunden werden können. Eng verknüpft mit den Geometriedaten sind auch die räumlichen Eigenschaften eines Objektes wie z.B. Abmessungen oder topologische Anordnungen. Um geometrische Daten zu speichern, gibt es das Raster- oder Bitmapverfahren und das vektorielle Verfahren. Diese beiden Möglichkeiten haben je nach Beschaffenheit der Daten ihre Vor- oder Nachteile und werden meist auch gemischt angewendet. Seite 12 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 2.4.1.1 Rasterdaten Rasterdaten sind Felder aus Bildelementen gleicher Größe, die in einer Matrix aus Reihen und Spalten angeordnet sind. Rasterdaten haben eine Reihe verschiedenster Vorteile. Bestehende Papierkarten können sehr einfach durch Scannen in ein digitales Rasterformat überführt werden. Viele Datenarten (z.B. Fernerkundungsdaten) liegen bereits in Rasterform vor. Rasterdaten bieten sich besonders an, wenn es darum geht, kontinuierliche Phänomene mit häufig wechselnden Werten (z.B. Höhenwerte einer Landschaft) zu modellieren. Auch ist die Positionsbestimmung über die Koordinate und die Auflösung des Rasters sehr einfach. Die Topologie der Objekte ist bereits in der Rasterstruktur enthalten und muss nicht erst hinterher, wie bei Vektorgrafiken, extrahiert werden. Des Weiteren ist es sehr einfach, Rasterdaten des gleichen Maßstabes zu überlagern um eine Karte aufzubauen. Der Nachteil dieses Verfahrens ist die Tatsache, dass man sich bei der Erstellung dieser Rasterdaten auf eine bestimmte Auflösung festlegen muss. Wenn man entsprechend tief in das Bitmap zoomt, bemerkt man, dass die Linien eigentlich Treppen sind und Punkte zu quadratischen Pixeln werden und somit Genauigkeitsgrenzen aufweisen. Diesem Effekt kann entgegengewirkt werden, indem man die Auflösung entsprechend hoch wählt, was natürlich automatisch zu einer größeren Datenmenge führt. Maßstab 1 : 10.000 1 : 50.000 1 :100.000 Speicherplatz bei Vektordaten [MB] Ca. 1,2 Ca. 1,0 Ca. 0.9 Speicherplatz bei Rasterdaten [MB] ca. 420 ca. 168 ca. 17 Tabelle 2-2: Speicherplatzbedarf für Karten (Quelle: [Saur97], S. 70) Ein gutes Beispiel findet sich in [Saur97] (S. 70), wo die Speicherung der Gemeindeflächen im Freiburger Umkreis jeweils als unkomprimierte Rasterdaten und als Vektordaten bei verschiedenen Maßstäben gegenüber gestellt wird. Die dort ebenfalls gezeigte Karte (auf die hier verzichtet wird) ist sehr homogen, was für die Speicherung im Vektorformat spricht. Stark inhomogene Daten können diesen Effekt durchaus umkehren und die Rasterdaten speichertechnisch zur besseren Alternative werden lassen. Natürlich kann diese Datenmenge durch verschiedenste Komprimierungsverfahren stark reduziert werden. Bekannte Algorithmen sind z.B. die Lauflängenkodierung oder Quadtree, auf die aber an dieser Stelle nicht weiter eingegangen wird. Der interessierte Leser sei hiermit auf weiterführende Literatur verwiesen. 2.4.1.2 Vektordaten Bei Vektordaten werden sämtliche Positionsangaben mit den genauen Koordinaten beschrieben. Dazugehörige Attributinformationen werden meist über einen eindeutigen Schlüssel hinzugefügt. Seite 13 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Hier liegt ein klarer Vorteil gegenüber den Rasterdaten. Die geometrische Dimension bleibt in jedem Maßstab erhalten. Somit bieten Vektordaten eine hervorragende Grundlage für Karten und Pläne mit hohem Präzisionsanspruch. Außerdem ist die Datenmenge bei homogenen Daten wesentlich geringer. Ein Nachteil von Vektordaten ist die fehlende Topologieinformation, die bei Bedarf noch nachträglich erstellt werden muss (z.B. um benachbarte Objekte zu finden). Die Erstellung vektorieller Karteninformation ist wesentlich aufwendiger und fehleranfälliger als die Digitalisierung von Karten zu Rasterinformation. Es gibt zwar Verfahren, die Objekte aus Bildern erkennen (z.B. Flüsse, Straßen oder Grenzlinien), die Fehleranfälligkeit ist aber sehr hoch. Verschmutzungen oder aufgedruckte Daten werden ebenso als Objekte „erkannt“ und stellen Fehler dar, die in mühevoller Kleinarbeit entfernt oder korrigiert werden müssen. Werden Karten vollständig mit Digitalisierungsbrett und Maus erfasst, können sich natürlich auch Erfassungs- und Genauigkeitsfehler einschleichen. 2.4.1.3 Fazit Vektor / Rasterdaten Wie aus der vorgegangenen Gegenüberstellung ersichtlich ist, hängt es stark von den eigenen Ansprüchen und der Art der Daten ab, welche Darstellungsform gewählt werden sollte. Die nachfolgende Tabelle soll die einzelnen Stärken und Schwächen beider Modelle noch einmal zusammenfassen. Genauigkeit von Koordinaten Verknüpfungsalgorithmen (Rechenzeit) Speicherplatzbedarf für Datensätze mit geringer räumlicher Inhomogenität der Werte Speicherplatzbedarf für Datensätze mit großer räumlicher Inhomogenität der Werte Qualität kartographischer Darstellungen Maßstabsbindung Vektor hoch komplex Raster gering einfach gering hoch hoch gering hoch bei angepaßtem Maßstab hoch hoch gering Tabelle 2-3: Vor- und Nachteile von Vektor- und Rastermodell (Quelle: [Saur97] Seite 77) Durch die geschickte Anwendung bei Modelle kann mit mehreren Schichten (oder Layern) eine Karte aufgebaut werden. 2.4.2 Attributdaten Attributdaten werden auch Sach- oder Objektdaten genannt und beschreiben das Objekt bzw. seine Eigenschaften. Diese Eigenschaften ermöglichen eine Klassifizierung verschiedener Objekte. Die Stärke einer geografischen Anwendung liegt in der Verbindung von Sachdaten mit Geometriedaten. Attributdaten werden oft innerhalb einer Datenbank verwaltet, Seite 14 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten wohingegen Geometriedaten wie z.B. Karten von vielen Systemen noch als externe Dateien in einem Dateisystem gehalten und verwaltet werden. 2.4.3 Zeitdaten Die beiden bisher behandelten Datenarten beschreiben den statischen Zustand eines Objektes. Eine besondere Stärke eines GIS ist aber die Fähigkeit, Veränderungen festzustellen und aufzuzeichnen. Dieser Wunsch bringt uns direkt zu der Zeit als variable Größe. Besonders im Umweltdatenbereich, wo Messdaten den größten Teil der Daten darstellen, ist der Messzeitpunkt natürlich von entscheidender Wichtigkeit. Die Historisierung der Messnetzdaten muss also möglich sein. Um eine solche Historie seiner Daten zu führen, gibt es eine Reihe verschiedener Methoden, auf die hier kurz eingegangen wird. a) Einfache Kopie: Hierbei werden durch eine vollständige Sicherung alle alten Daten gerettet. Diese Methode ist recht ineffektiv, wenn die Daten im Allgemeinen wenig variieren. Im Messnetzbereich ist diese Methode jedoch durchaus üblich. Wenn z.B. jeden Tag eine Messwertreihe eintrifft, ist diese sehr wahrscheinlich ungleich der alten Datenreihe. b) Speicherung der Änderung: Hier werden nur die Unterschiede zu den alten Daten aufgezeichnet, was die Datenredundanz erheblich minimieren kann, wenn die Daten nur geringfügig variieren. 2.4.4 Prozessdaten Prozessdaten sind Modelle, die eine Simulation von Änderungen und Vorgängen ermöglicht. Sie stellen eine Abbildung dar, mit dessen Hilfe das Verhalten oder eine Veränderung abgebildet werden kann. Das generelle Problem dabei ist natürlich diese Abbildung zu kennen. Was bei Systemen mit wenigen physikalischen Gesetzmäßigkeiten noch einfach sein mag, kann in Systemen, die einige unbekannte Parameter besitzen, sehr kompliziert sein. Gelingt eine solche Simulationsvorschrift, ist es möglich die Veränderung der Daten erst herbeizuführen, wenn ein konkreter Bedarf danach besteht. Seite 15 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 2.5 Datenstrukturierung mit Layern Bei geografischen Informationssystemen werden Daten meist in verschiedene thematische Gruppen, sog. Layer 7, unterteilt. Diese Layer werden dann wie Folien übereinander gelegt und ergeben zusammen eine Karte (s. Abb. 2-2). Damit unterscheiden sie sich von konventionellen Papierkarten, die sämtliche Informationen enthalten. Abbildung 2-2: Layerkonzept (Quelle: [http://www.gis.com/whatisgis/index.html]) Vorteile von Layern: 1. Hohe Datendichte: Es besteht die Möglichkeit der Abspeicherung hoher Datenmengen durch die Zuordnung zahlreicher, unterschiedlichster Daten zu einem bestehenden Koordinatensystem. 2. Visualisierungsvielfalt und –vereinfachung: Die Darstellung kann an die jeweiligen Anforderungen angepasst werden, indem z.B. Layer mit unwichtigen Teilaspekten ausgeblendet oder alternative Varianten wahlweise dazugenommen werden. 3. Kartenalgebra: Layer können mathematisch verknüpft werden. Durch das Verschneiden bestehender Layer ist es möglich neue zu berechnen. Z.B. könnte man das Durchschnittsalter der Bevölkerung verschiedener Länder mit der Qualität medizinischer Versorgung verschneiden um evtl. Zusammenhänge sichtbar zu machen. 4. Wiederverwendbarkeit: Einmal erfasste Daten können, als Layer gekapselt, für verschiedene Zwecke (wieder)verwendet werden. Die Fähigkeit, Informationen in Layer zu partitionieren und nach Bedarf beliebig zu kombinieren, eröffnet viele Möglichkeiten für die Entscheidungsfindung, birgt gleichzeitig 7 oder deutsch: Schichten oder Ebenen Seite 16 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten aber auch hohe Risiken. Daten können für die eine Anwendung ideal, für eine andere jedoch völlig ungeeignet sein. Die Kartenalgebra eröffnet vielfältige Möglichkeiten, von denen viele nicht sinnvoll sind. Deshalb sollte der jeweilige Datenkontext immer berücksichtigt werden. 2.6 Datenorganisation Die GIS Datenorganisation ist ein vielfältiges Gebiet, die hier anhand einiger topologischer Anordnungen bewertet wird. 2.6.1 Einzelplatzsystem Viele GIS Programme bieten die Möglichkeit, Attributdaten in einem relationalen Datenbanksystem abzulegen. Geometriedaten werden jedoch oft noch separat in einer dateiorientierten Datenhaltung verwaltet. Die Verwaltung beschränkt sich oft nur auf die einfache Lese- und Schreibgrundfunktionalität. Die Sicherheitspolitik wird bei diesem Ansatz vollständig an der Betriebssystem delegiert. Für Einzelplatzsysteme ist dieser Ansatz durchaus befriedigend. 2.6.2 Mehrplatzsysteme Sobald man jedoch ein GIS verteilt und Daten im Netzwerk verteilt werden, genügt dieser Ansatz nicht mehr den Anforderungen hinsichtlich Nebenläufigkeit und Konsistenz. Es wird ein Management für geografische Daten notwendig und man kommt schließlich zu dem Ansatz, auch die geografischen Daten in einem RDBMS unterzubringen und zu verwalten. Viele Datenbankhersteller bieten deshalb einen spatialen 8 Aufsatz für ihre Produkte an. Dabei handelt es sich im Wesentlichen um neue Datentypen und Verarbeitungsmöglichkeiten (z.B. Berechnungsroutinen für Abstandsmessungen zweier Punkte). Dazu zählen IBM’s UDB (früher DB/2) , Informix und Oracle. 2.6.3 Intra-/Internet Überall wo Daten sehr aktuell und einem breiten Publikum zugänglich gemacht werden sollten, kommt auch das Intra- oder Internet als Verteilungsmedium zum Zuge. Der Kartenzugriff im Intra/Internet kann in drei Kategorien 9 hinsichtlich ihrer Fexibilität unterschieden werden: 1. Statisch 2. Interaktiv 3. Dynamisch 8 9 spatial bedeutet räumlich oder geografisch Vgl. [http://gio.uni-muenster.de/beitraege/ausg97_2/stahl/stahl.htm] Seite 17 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Beim statischen Ansatz bietet ein Webserver den Zugriff auf festes Kartenmaterial, das in einem Dateisystem abrufbereit liegt und auf Wunsch übertragen wird. Oft werden Übersichtskarten verwendet, die mit detaillierteren Karten verlinkt sind. Auf diese Weise kann sich der Benutzer schrittweise z.B. durch eine Stadtkarte bewegen. Mit Webformularen kann die Auswahl des Kartenausschnitts noch beschleunigt werden. Eine interaktive Lösung bietet weitere Gestaltungsmöglichkeiten für den Benutzer. Hier werden spezielle Webserver, sog. Mapserver, eingesetzt. Die Darstellung kann an eigene Bedürfnisse angepasst werden, der Mapserver generiert die Karte aus einem GIS, das auf der Serverseite läuft und sendet das Ergebnis meist als komprimierte Bilddatei über den Ether. Dieser Ansatz ist natürlich überall angebracht, wo keine einheitlichen Karten oder Kartenausschnitte festgelegt werden können, da das Kartenmaterial nicht normierbar ist. Der dynamische Ansatz eröffnet erst die vollständige GIS Funktionalität, die man bei GIS Software gewöhnt ist. Dies wird i.d.R. durch Java Applets oder ActiveX Controls bereitgestellt, die mittels Webbrowser Plugins geladen und ausgeführt werden können. Seite 18 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 3 Produktanalyse In diesem Kapitel wird eine Übersicht über die von TechniData eingesetzten Softwareprodukte erstellt (s. auch Abbildung 3-1). Diese Produktübersicht schließt sowohl Messnetzsoftware als auch GIS ein. Der Funktionsumfang der existierenden GIS dient als Grundlage für die anschließende Marktübersicht aktueller, verfügbarer Java basierter GIS Klassensammlungen und deren Bewertung für eine Entscheidungsfindung. Das ausgewählte Produkt wird dann zur Umsetzung des Prototyps verwendet. Abbildung 3-1: TechniData Messnetzsysteme und GIS 3.1 Altsysteme von TechniData 3.1.1 Das OBLIS System Das OBLIS System ist der historische Vorgänger von NMC / DAISY. Das Programmpaket besteht aus mehreren eigenständigen, miteinander in Verbindung stehenden Komponenten. Alle Komponenten sind um eine Datenbank angeordnet und laufen auf dem Betriebssystem VMS und diversen Unixen. Auch hier stellen die Daten das zentrale Element dar. Das AKS (Auskunftssystem) ist ein Modul in OBLIS und besitzt eine grafische Oberfläche, die mit X-Windows / OSF-Motif Komponenten realisiert ist. AKS enthält ein kleines GIS, dass allerdings nur sehr elementar ist. Im Wesentlichen besteht es aus Rasterkarten und Buttons, mittels derer man einzelne Messstationen selektieren bzw. abfragen kann. Da OBLIS in Zukunft vollständig von NMC / DAISY ersetzt werden soll, bei verschiedenen Projekten der TechniData aber noch eingesetzt wird, sei es hier nur der Vollständigkeit halber erwähnt. Seite 19 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 3.1.2 INES RAD Abbildung 3-2: INES RAD von DIC Solutions Augsburg INES RAD ist ein Java und C++ basiertes System zur Steuerung, Überwachung, und Datenakquisition in verteilten Messnetzen und stellt ein weiteres Altsystem dar, dass TechniData von der Firma DIC Solutions Augsburg übernommen hat. Viele Teile davon sind in NMC / DAISY eingeflossen und machen es somit ebenso zu einem historischen Vorgänger. INES RAD ist noch im Einsatz, wird aber in absehbarer Zeit durch NMC / DAISY ersetzt werden. INES RAD besitzt ein elementares GIS, dass es ermöglicht, Messstationen grafisch auf einer Karte anzeigen, wo sie auch selektiert und angesteuert werden können. 3.1.3 UGI GISView von WiGeoGIS Bei UGI GISView handelt es sich um ein Produkt, dass mit ESRI‘s MapObjects für Windows API arbeitet und ist ein externes Produkt der Firma WiGeoGIS GmbH 10. Die MapObjects Windows API stellt eine Vielzahl von GIS Funktionalität bereit und erleichtert die Entwicklung von GIS Applikationen auf Windows Basis mit Visual Basic. GISView ist ebenso ein VB Produkt und nutzt diese API bzw. erweitert die Funktionalität um zusätzliche Fähigkeiten. Mit einer DCOM / CORBA Bridge ist GISView mit NMC / DAISY verbunden. Bei Bedarf wird es von NMC aus gestartet und über diese Schnittstelle mit Daten versorgt. Es arbeitet intern mit einer temporären Access Datenbank für die Zwischenspeicherung von Tabellen, die es über diese Bridge von NMC erhält. GISView bietet zur Zeit die umfangreichste GIS Funktionalität. 10 [http://www.wigeogis.com] Seite 20 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 3.2 ENVINET NMC11 von TechniData 3.2.1 Einführung ENVINET-NMC (Network Managment Centre) ist ein Produkt der TechniData und erfüllt die Funktionalität einer Umweltüberwachungs- und Messnetzzentrale neuster Generation. NMC besteht aus zahlreichen Softwarekomponenten, die in Ihrer Gesamtheit den Datenfluss von der Erfassung über die Speicherung und Auswertung bis hin zur Datenweitergabe sicherstellen. Dieses Leistungsspektrum ermöglicht den Einsatz von NMC in den Bereichen der Luftqualitätsmessung, Meteorologie, Hydrologie sowie zur Überwachung von Radioaktivität. NMC besitzt im wesentlichen drei Grundeigenschaften, die ein Maximum an Variabilität ermöglichen: 1. Konfigurierbarkeit: Die einzelnen Komponenten können dynamisch an die speziellen Anforderungen angepasst und konfiguriert werden. 2. Modularität: Das komponentenbasierte System ermöglicht es, speziell zugeschnittene Lösungen anzubieten. 3. Adaptierfähigkeit: NMC kann gut in bestehende Umgebungen integriert werden. Oft existieren umfangreiche Altsysteme, die aus Kosten- oder Kompatibilitätsgründen nicht ersetzt werden können oder sollen. Durch dieses Design ist es möglich, NMC als kompakte Messnetzzentrale mit geringer Basisfunktionalität ebenso wie als vollständig ausgebautes Messnetzzentralsystem in einem ausfallsicheren Umfeld zu betreiben. Ein normiertes Datenmodell stellt die zentrale und homogene Datenhaltung sicher. NMC ist ein reines Java Produkt und kann deshalb auf einer Vielzahl möglicher Plattformen eingesetzt werden. Unterstützt werden zur Zeit die Betriebssysteme Unix, Linux, Windows NT und Windows 2000. Die einheitlich gestaltete Benutzeroberfläche ermöglicht die Abbildung der organisatorischen Messnetzstruktur und dient als zentrale Oberfläche für Steuerung und Zugriff. 11 [NMC] Seite 21 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 3.2.2 Der Aufbau von ENVINET-NMC Abbildung 3-3: NMC Funktionalität (Quelle: [NMC]) Der zentrale Kern von NMC sind seine Daten, die üblicherweise sehr umfangreich sind. Um diese Daten scharen sich die einzelnen modularisierten Funktionsgruppen, die in einem DreiSchichten-Modell unterteilt sind. Seite 22 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Abbildung 3-4: NMC Komponenten (Quelle: Eigene Darstellung in Anlehnung an [NMC]) Der Presentation Layer stellt die Benutzerschnittstelle dar. Im Data Access Layer werden die Daten und ihre Zugriffssteuerung organisiert. Im Business Layer sind alle Softwarekomponenten enthalten, die für die Steuerung und Verarbeitung der Daten notwendig sind. 3.2.2.1 Presentation Layer Diese Schicht stellt eine einheitliche Benutzerschnittstelle bereit und dient als zentrales Steuerelement. Über eine Menü- und Baumstruktur werden alle Vorgänge überwacht und gesteuert. Das Benutzersystem ermöglicht die Ansteuerung folgender Funktionalität: a) Administration: Benutzer- u. Stammdatenverwaltung sowie Operating. b) Datenvisualisierung: Darstellung von Daten sowie kartografisch basierte Messstellenpräsentation und -auswahl. Um bei hohen Datenmengen den Überblick nicht zu verlieren, ist eine gute Visualisierung notwendig. NMC stellt deshalb die Visualisierung von Messdaten, berechneten Daten und von Zusatzinformationen als Tabellen und Grafiken bereit. Die GIS Darstellung wird z.Z. noch über das zuvor vorgestellte GIS der Firma WiGeoGIS abgewickelt, soll aber in Zukunft von einem Java GIS übernommen und somit besser integriert werden. Die Diplomarbeit soll dies evaluieren. c) Monitoring: Überwachung und Beobachtung des laufenden Systems (Laufzeitstatus der Softwarebausteine) und der Datenquellen (Statusüberwachung der Messstellen). Seite 23 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten d) Reporting: Erstellung von verschiedenen Berichten. e) Auswertung mit DAISY: Hiermit werden die Messdaten nachbearbeitet. f) Alarmierung: Darstellung von Ausnahmesituationen bei Messwerten oder Systemzuständen. Alarmierungen als Nachrichten an Benutzer oder Nutzergruppen. Für diesen Zweck existiert ein eigenes Nachrichtenkonzept. 3.2.2.2 Data Access Layer Der Data Access Layer stellt die Zugriffsschnittstelle über sog. Storeklassen zur Datenbank bereit. Über diese Schnittstelle greifen alle Komponenten der Anwendungs- und Benutzerschicht auf die Datenbank zu. In der darunter liegenden relationalen SQL basierten Datenbank (z.B. Oracle) ist das NMC Datenmodel abgelegt. 3.2.2.3 Business Layer Die Anwendungsschicht stellt die Kernfunktionalität von NMC dar und besteht aus folgenden Softwaremodulen: a) Communication Controller: Das „Betriebssystem“ des NMC für verschiedenste Datenübernahme/Importvorgänge, Kommunikationsaktivitäten und Datenprotokolle mit unterschiedlichen Datengeräten. b) Flow Controller: Zeitlich-, ereignis- und ablaufgesteuerte Vorlänge werden über den Flow Controller gesteuert. Damit ist es möglich Aktivitätssequenzen durchzuführen, die in Skripten definiert sind. c) Data Controller: Dieses Modul realisiert die automatische Datenplausibilisierung, ein Instrument zur automatischen Bewertung von Rohdaten aus verschiedensten Datenquellen. Hier finden verschiedenste Prüfalgorithmen (z.B. Schwellwertprüfung, Regressionsprüfung (Sprunghöhenprüfung) oder Konstantwertprüfung) und evtl. verschiedene Korrekturfunktionen (z.B. Offset Additionen oder Faktormultiplikationen) ihre Anwendung. d) Calculation/Aggregation Controller (DAISY-Calc): DAISY-Calc führt Berechnungen und Aggregierungen von Datenreihen wie z.B. Mittelwertberechnungen durch. Üblicherweise wird DAISY-Calc durch den Flow Controller im Anschluss an die Plausibilisierung gestartet. Ändern sich die Basiswerte z.B. durch eine Aktualisierung, wird die Berechnung entsprechend neu aktiviert und durchgeführt. e) Message Controller: Die Message Controller Komponente ist für das zentrales Logging und die Protokollierung zuständig. Alle Aktionen, Reaktionen und Systemfehler sowie der Status des Systems können lückenlos nachvollzogen und überwacht werden. Durch einen Notifier ist es außerdem möglich, automatisch Nachrichten an Benutzer oder Nutzergruppen zu senden, wenn ein kritischer Systemstatus oder Schwellwertüberschreitungen auftreten. Seite 24 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten f) System Controller: Der System Controller ist Teil des Systemkerns und kümmert sich um die Aufrechterhaltung der zentralen Funktionsfähigkeit des Systems. Die Aufgaben des System Controllers sind: • • • Start u. Initialisierung der Kernkomponenten kontrollierter Shutdown Überwachung der Module bzw. der Modulaktivitäten Bei Fehlern kann er Module reinitialisieren oder redundante Systemmodule starten. Sollte NMC auf einer ausfallsicheren Rechnerkonstellation (z.B. auf einem Cluster) laufen, kümmert er sich auch um die applikationsseitige Umschaltung. 3.3 ENVINET DAISY12 von TechniData DAISY (=Datenauswerte- und Informationssystem) ist, wie der Name schon sagt, für die Messdatenauswertung bestimmt. Wie NMC ist auch DAISY modular aufgebaut, um ein Höchstmaß an Flexibilität zu ermöglichen. DAISY besteht aus verschiedenen Client- und Serverkomponenten, die nachfolgend kurz beschrieben werden. 3.3.1 DAISY Client Komponenten Es gibt keinen eigenständigen DAISY Client. Üblicherweise wird der DAISY Client in den NMC Navigator eingebettet. In der NMC Baumstruktur werden lediglich für DAISY Knoten und Kontexte definiert, die die DAISY-spezifischen Masken aufblenden lassen. Die Rechteund Userverwaltung wird auch über die NMC Oberfläche realisiert und sind kein Bestandteil von DAISY. DAISY besteht aus folgenden Clientkomponenten: DAISY -Def-Calc: Die Bedienungsoberfläche zur einfachen Parametrierung der Berechnungen und der Möglichkeit zur kartografisch basierten Stationsmessstellenauswahl. DAISY -Show: Auswertung der Berechnungsergebnisse als Grafik und Tabelle. DAISY -Def-Show: Konfigurationsoberfläche für die DAISY-Show Komponente. DAISY -Mon: Ein Statusmonitor zur Überwachung und Manipulation der Berechnungen. DAISY -Def-Rep: Konfigurationsoberfläche für die Generierung von Berichten. DAISY -Admin: Oberfläche für die erweitere Manipulation der Berechnungen. 12 [DAISY] Seite 25 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 3.3.2 DAISY Server Komponenten DAISY -Controller: Der Berechnungsmanager für die Verteilung von Berechnungsaufträgen an DAISY-Calc. DAISY -Calc-Server ist ein CORBA-Prozess, in dem eine bestimmte Anzahl von Berechnungsprozessen laufen können. DAISY -Calc: Das Rahmenprogramm, das für eine Vielzahl unterschiedlichster Berechnungsformeln konzipiert ist. Für die Berechnung der Werte können verschiedene Filter, wie z.B. ein Zeitfenster, angegeben werden. DAISY-Calc bietet unterschiedliche Berechnungsarten (Aggregierungen), wie z.B. Mittelwert, Standardabweichung oder Häufigkeitsverteilungen. Die sequenzielle Ausführung verschiedener Filter- und Berechnungsvorschriften erlaubt somit flexible und vielfältige Möglichkeiten. DAISY -Report dient zur Erzeugung von Berichten und Reports auf Basis von MS Excel. Seite 26 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 3.4 Grobevaluierung freier und kommerzieller Java GIS API‘s Mit der Grobevaluierung soll ein erster Überblick über die am Markt verfügbaren GIS Klassenbibliotheken gewonnen werden. Das Auswahlkriterium der Kandidaten war eine vollständige Java Implementierung der Klassenbibliothek. 3.4.1 Freie Java GIS 3.4.1.1 DEMViewer 13 mit VisAD 14 Bibliothek Der DEMViewer ist ein Anzeigeprogramm für dreidimensionale Höhenmodelle, die im ArcGrid 15 ASCII Exportformat vorliegen. Das Programm wurde am Institut für Geografie an der Universität von Jena entwickelt und ist vollständig in Java implementiert. Für die 3DVisualisierung werden Java3D sowie VisAD eingesetzt, eine freie Java Bibliothek für die Visualisierung und Analyse numerischer Daten. Der Viewer stellt eine Beispielimplementierung für den Funktionsumfang von VisAD und Java3D dar. Die anfängliche Idee, den DEMViewer durch eine Erweiterung an das gewünschte Leistungsspektrum anzupassen, musste schließlich wieder verworfen werden. Leider liegt der Zweck von DEMViewer auf der reinen Visualisierung von Karten ohne weitere Funktionalität für die Ausgestaltung einer Bedieneroberfläche. Hieraus ergibt sich die Notwendigkeit der selbstständigen Weiterentwicklung des Programms unter Verwendung von VisAD und Java3D. Dies ist im Rahmen einer Diplomarbeit jedoch zu aufwendig und eine weitere Betrachtung dieses Projektes wurde ausgesetzt. 3.4.1.2 GISToolkit 16 Das GISToolkit ist eine freie Java GIS API zur Entwicklung von GIS Applikationen, die unter der GNU Library General Public Licence verfügbar ist. Leider stellte sich beim Test der Beispielapplikationen heraus, dass diese auf ArcSDE 17 aufbauen. Leider stand dieses Softwarepaket nicht zur Verfügung. Eine Emailanfrage an den Entwickler, ob man GISToolkit auch mit Kartendateien nutzen könnte, wurde erst nach Abschluss meiner Produktanalysephase mit einem Verweis auf den Sourcecode kommentiert. GISToolkit hat es somit nicht geschafft in den Kreis der engeren Wahl zu kommen. 13 [http://www.geogr.uni-jena.de/~p6taug/demviewer/demv.html] [http://www.ssec.wisc.edu/~billh/visad.html] 15 ArcGrid ist ein Toolpaket für räumliche Datenanalyse 16 [http://gistoolkit.sourceforge.net] 17 Hierbei handelt es sich um eine Software zur Anbindung verschiedener Datenbanken an GIS Applikationen, dass von der Firma ESRI vertrieben wird. 14 Seite 27 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 3.4.1.3 JaGo Bei JaGo 18 (Java Framework for Geospatial Solutions) handelt es sich um eine Java API, die eine Entwicklung lokaler und verteilter GIS Applikationen unterstützt, deren Schnittstellen und Architekturen an den Vorgaben der OGC (OpenGIS Consortium) orientiert sind. JaGo ist freie Software, die unter der GNU Lesser General Public License steht und in Zusammenarbeit des Geografischen Institutes der Universität Bonn mit der Firma LatLon entwickelt wurde. Die Vorteile von JaGo liegen in der freien Verfügbarkeit der API, die keine weiteren Lizenzkosten verursacht, sowie in der flexiblen Schichtenstruktur, die eine Auftrennung in eine hochdistributive Applikation erlaubt. Leider verfügt das JaGo Framework nur über wenig Visualisierungselemente für die Implementierung eines GIS Clients. Trotz dieser Schwäche wurde JaGo in die Feinevaluierung übernommen, da das Produkt einen sehr zukunftsweisenden Eindruck macht. Es orientiert sich an zahlreichen offenen Standards und unterstützt beispielsweise als einzigstes Paket GML, einen XML Standard für geografische Daten. 3.4.2 Kommerzielle Java GIS 3.4.2.1 ActiveMaps Bei ActiveMaps 19 handelt es sich um eine Java Klassenbibliothek, die wahlweise für Appletoder Applikationsentwicklung verfügbar ist. Gegenstand der Betrachtung ist die Bibliothek für die Java Applikationsentwicklung. Die Bestellung und Auslieferung der Softwarepakets wird schnell und direkt per Email zugesichert. Nach kurzer Anfrage wird auch sofort eine Testversion zur Verfügung gestellt, die mit zahlreichen Beispielen offen legt, was die API zu leisten vermag. Diese Kriterien haben ActiveMaps in die Liste der Feinevaluierung verholfen, wo die einzelnen Funktionen genau geprüft werden. Das Produkt hat allerdings den Nachteil, dass es von der irischen Firma Compass Informatics vertrieben, aber nicht mehr weiterentwickelt wird. Der erste Eindruck hinsichtlich des Funktionsumfangs kann nur beschränkt überzeugen. Dies soll aber in der Feinevaluierung genauer betrachtet werden. 3.4.2.2 GISTerm20 Die Firma disy ist ein junges Unternehmen, das 1997 von Mitarbeitern des Forschungszentrums Informatik Karlsruhe gegründet wurde und zahlreiche Referenzen besitzt. Disy bietet mit GISTerm ein umfangreich ausgestattetes und modernes Klassenpaket für die Entwicklung eigener GIS Applikationen, das keine Wünsche offen lässt. Der Funktionsumfang ist reichhaltig und stellt selbst das nachfolgend beschriebene MapObjects von ESRI in den Schatten. GISTerm bietet neben den Standardfunktionen wie Layerhandling oder Kartennavigation auch Perlen wie z.B. die Verbindung von Karten mit Geschäftsgrafiken oder eine optionale 3D Kartenvisualisierung, die mit Java3D realisiert wird. 18 [http://katla.giub.uni-bonn.de/jago] [http://www.compass.ie/geoshop/categories/devtools-index.html] 20 [http://www.disy.net/de/Produkte/disy_GISterm/index.html] 19 Seite 28 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Die beiden Wermutstropfen sind die teuren Lizenzen zum Einen und zum Anderen, dass disy leider keine Testversion für die Implementierung des Prototypen zur Verfügung stellt. 3.4.2.3 Map Objects for Java21 Die Firma ESRI hat pünktlich zum Start meiner Evaluierungsphase Anfang April das Produkt MapObjects for Java auf den Markt gebracht. Es bietet wie das zuvor beschriebene GISTerm ähnlich umfangreiche Funktionen und Beans für die Gestaltung der Benutzeroberfläche. Einige Extras, wie z.B. das 3D Paket, fehlen jedoch. Der Funktionsumfang lehnt sich stark an MapObjects for Windows an, das bereits in UGI GISView von WIGeoGIS Anwendung findet, welches bislang noch mit NMC / DAISY ausgeliefert wird. Ein Testversion zur Entwicklung eines Prototypen wird nach Anfrage zur Verfügung gestellt. Der Nachteil ist ein unreifes Erscheinungsbild, das sich in einer schlechten Dokumentation darstellt und auf den jungen Produktstatus zurückzuführen ist. Das Testpaket soll mit einer Reihe von Softwarebeispielen ausgeliefert werden und ein Diskussionsforum bietet eine Plattform für Erfahrungsaustausch und gegenseitige Hilfe. Das Forum ist allerdings wenig besucht, da MapObjects Java noch nicht sehr verbreitet ist. 3.5 Feinevaluierung anhand einer Featureübersicht 3.5.1 Featuretabelle Die Feinevaluierung wird an vier Klassenbibliotheken durchgeführt, die hinsichtlich ihrer Leistungsfähigkeit am dichtesten an den Anforderungen TechniData’s liegen. Das sind: • • • • JaGo ActiveMaps GISTerm MapObjects for Java Diese Klassensammlungen werden hier in einem weiteren Schritt anhand einer Featuretabelle genau evaluiert und verglichen, um eine Wissensbasis für die Leistungsfähigkeit der einzelnen Pakete zu erhalten. Diese Basis wird in einer anschließenden Entscheidungsphase eine wesentlich Grundlage darstellen. In der Tabelle werden die allgemeinen Produktdaten sowie die technischen Möglichkeiten der Produkte bewertet. Unter Verwendung dieser zwei Hauptgesichtspunkte wird versucht, einen möglichst guten Überblick über die Produktqualität zu erlangen. Die allgemeinen Produktdaten werden in den vier Punkten: 1. Ersterscheinung 2. Produktstatus 3. Lizenzpreis und 21 [http://www.esri.com/software/mojava/index.html] Seite 29 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 4. Lieferzeit bewertet, wobei die ersten beiden Punkte einen Indikator für die Produktstabilität darstellen sollen. Die technischen Möglichkeiten werden in insgesamt 34 Punkten bewertet. Eine genaue Beschreibung der technischen Fachbegriffe erfolgt im nachfolgenden Abschnitt. Die technischen Punkte setzten sich zum Einen aus den Features bisherig verwendeter TechniData GIS Produkte und zum Anderen aus den Features der vier neuen Produkte zusammen. Alle Features, die die Leistungsfähigkeit der bisher verwendeten TechniData GIS Produkte übersteigen, sind Zusatzfeatures und blau in der Tabelle hervorgehoben. Die Bewertung der einzelnen Punkte erfolgt in drei Stufen: 1. Guter Wert oder Funktionalität ist vorhanden: zwei Punkte 2. Befriedigender Wert oder Funkionalität ist teilweise vorhanden: einen Punkt 3. Unbefriedigender Wert oder Funktionalität ist nicht vorhanden: null Punkte. Null Punkte wurden ebenfalls gegeben, wenn eine Bewertung aufgrund fehlender Informationen nicht möglich war. Seite 30 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Seite 31 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Tabelle 3-1: Featuretabelle Seite 32 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 3.5.2 Featurebeschreibung Diese Featurebeschreibung soll Klarheit in die teilweise sehr kurzgehaltene Beschreibung der einzelnen technischen Funktionalitäten der Tabelle bringen. 3.5.2.1 Navigation 1. Standard Kartennavigation: Einfache Standardfunktionalität um in der Kartenansicht zu navigieren. Das umfasst das Verschieben oder Bewegen der Karte, das Zoomen in der Karte und das Zentrieren einer Karte auf volle Größe. 2. Übersichtskarte: Hierbei handelt es sich um eine Miniaturkarte, die die gesamte Karte und den aktuellen sichtbaren Bildausschnitt darstellt. Sie dient als Navigationshilfe. 3.5.2.2 Visualisierung 3. Maptips: Wenn man mit der Maus ein Kartenobjekt berührt, erscheint begleitende Attributinformation zum Objekt. 4. Legenden beschreiben die einzelnen Layer einer Karte und deren Anordnung. Die Layer können dann nach Belieben ein- oder ausgeblendet werden. 5. Labels: Dieses Feature erlaubt die Beschriftung von Kartenobjekten mit Zusatzinformationen (Text). Dieser Text kann z.B. ein Attribut aus der ESRI Shapedatei sein. 6. 3D-Ansicht: Dreidimensionale Ansicht der Karte, evtl. mit entsprechend erweiterten Navigationsmöglichkeiten. 7. Kartogramme / Geschäftsgrafiken in Karten: Geschäftgrafiken (z.B. Torten- oder Balkendiagramme) als Bestandteile der Karte, die wahlweise ein- oder ausgeblendet werden können. 8. Benutzerdefinierte Symbole: Kleine Grafiken, die für bestimmte Objekte auf der Karte eingesetzt werden können um sie lesbarer zu machen. Seite 33 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 3.5.2.3 Selektion 9. Räumliche Selektionstools: Selektion mit Maus und verschiedenen grafischen Formen (Rechteck, Polygon, Kreis). Damit können z.B. alle Kartenobjekte im Umkreis einer bestimmten Position selektiert werden. 10. Pufferbildung um selektierte Objekte: Mit dieser Funktion kann um alle selektierten Objekte ein räumlicher Puffer gebildet werden, der die Umgebung der Objekte mit einbezieht (evtl. auch layerübergreifend). 11. Geocoding: Mit Geocoding ist es möglich über eine Adresse (zum Beispiel dem Straßennamen) zu einer zugehörigen Position in der Karte zu gelangen. Dafür ist natürlich ein Layer notwendig, der die entsprechenden Geodaten enthält. 12. Selektion invertieren: Eine Funktion, die es erlaubt, die komplementäre Menge zu den aktuell selektierten Kartenobjekten zu erhalten. 13. Selektion mit SQL Ausdruck: Selektion mittels eines SQL Ausdruckes, der z.B. auf ein ESRI Shapefile angewendet wird. 3.5.2.4 Attributdatenabfrage 14. Räumliche Identifikation von Objektdaten: Abfragen von Objektdaten aus der Karte heraus durch direktes Anwählen mit der Maus oder Tastatur. 15. Einfache Suche von Objektdaten: Eine Suchfunktion, die die Suche von Kartenobjekten ermöglicht. 16. Komplexe Suche mittels Query‘s: Eine Suchfunktion, die mittels eines Querybilders eine komplexere Suche mit logischen Verknüpfungen ermöglicht. In ActiveMaps existiert dafür z.B. schon eine Java Swing Komponente, die diesen Querybilder implementiert. 3.5.2.5 Layerfeatures 17. Layer aus Shapedateien: Die Fähigkeit Layer aus ESRI Shapedateien zu importieren und entsprechend verwalten und visualisieren zu können. 18. Layer aus Bilddateien: Die Möglichkeit, Bilddateien (Rasterdaten) als Layer zu importieren und entsprechend verwalten und visualisieren zu können. Seite 34 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 19. Skalierungsdifferenzierung: Abhängig vom aktuellen Maßstab werden Layer angezeigt oder ausgeblendet. In einer Erweiterung dieser Funktionalität ist es auch möglich, bestehende Layer maßstabsabhängig durch andere (z.B. durch detailreichere Layer) zu ersetzen. 20. Werteabhängige Gestaltung von Layern: Die Gestaltung einzelner Kartenteile kann in Abhängigkeit weiterer Werte gewählt werden. Z.B. werden die einzelnen Gebiete einer Landkarte entsprechend der Bevölkerungsanzahl heller oder dunkler eingefärbt. Den Farben werden dann Wertebereiche zugewiesen. 21. Variable Layertransparenz: Möglichkeit der Konfiguration, ob ein Layer teilweise durchsichtig ist oder nicht. Lediglich bei ActiveMaps konnte keine solche Möglichkeit entdeckt werden. 3.5.2.6 Datenformate / Schnittstellen 22. Export als Bild: Schreiben einer Karte als Bilddatei. 23. ArcSDE Layer: Möglichkeit der Einbindung von ArcSDE. 24. ESRI Shapefile Format: ESRI’s Standard Dateiformat für Vektordaten. 25. GML Unterstützung: Die Geography Markup Language (GML) ist ein XML Standard, der die Codierung geografischer Daten beschreibt. GML wird von dem OpenGIS Konsortium (OGC) entwickelt und von einer Reihe namhafter Firmen wie z.B. Oracle oder MapInfo unterstützt und gefördert. 26. Verteilte Kartenlokalität: Alle vier Produkte können mit verteilten Kartendaten umgehen. 27. Zugriff auf Mapserver möglich: Karten können auch von einem Kartenserver per HTTP geladen werden. 28. ArcIMS Unterstützung: ArcIMS ist ESRI’s Mapserver Lösung um Kartendaten über das Internet anzubieten. 29. Anbindung an externe Datenbank: Hier bietet JDBC die wohl flexibelste Lösung um eine Datenbank direkt anzubinden. Im Normalfall wird die GIS Lösung aber mit Daten über die NMC / DAISY Schnittstelle versorgt werden. Seite 35 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 30. Oracle Spatial: Ermöglicht den direkten Zugriff auf Oracle Spatial, einer Datenbankerweiterung, die Datentypen und Funktionen für Zugriff, Speicherung und Analyse räumlicher Daten bietet. 3.5.2.7 Sonstige Features 31. Projektmanagement stellt die Möglichkeit dar, Einstellungen oder Konfigurationen (z.B. die Aufbauorganisation einer Karte) in einem applikationsseitigen Format abzuspeichern und bei Bedarf wieder zu laden. 32. Druckfunktion: Die Möglichkeit Karten auf dem Drucker auszugeben. 33. Abstandsmessungen: Mit dieser Funktion werden Abstände und Entfernungen relativ zum verwendeten Maßstab gemessen. 34. Geometrische Operationen: Operation wie Verschneiden, Vereinigen oder die Bildung der Differenz zwischen Layern als Anwendung von Kartenalgebra, um z.B. neue Karten zu bilden oder Resultate zu extrahieren. 3.5.3 Fazit Bei den Featurepunkten ist ActiveMaps der eindeutige Verlierer mit nur 29 Punkten. Die API bietet nur elementare Basisfunktionalitäten. Des Weiteren ist es generell sehr fragwürdig, eine Klassenbibliothek zu adaptieren, die zum Stillstand gekommen ist. Ein Support von fachlicher Seite kann von Compass Informatics selbst nicht geboten werden und es wird auf eine schwach besuchte und scheinbar ausklingende Entwicklergemeinschaft verwiesen, die in einem Diskussionsforum agiert. Auf Grund dieser Eigenschaften kommt es deshalb zu einem Ausscheiden der ActiveMaps Lösung für die Prototypentwicklung. JaGo reiht sich mit 34 Featurepunkten aber mit sehr guten 7 Produktpunkten ins Mittelfeld ein. Die Produktpunkte können den geringen Funktionsumfang jedoch nicht ausgleichen. Eine Implementierung des Prototypen mit JaGo scheidet aus, da es nicht möglich ist, die fehlende Funktionalität in der beschränkten Zeit dieser Diplomarbeit aufzubauen. Die beiden Produkte GISTerm und MapObjects for Java belegen die Spitzenplätze mit 50 und 46 Punkten. Die Tabelle stellt GISTerm eindeutig als Sieger dar, die Entscheidung wird allerdings von einer Reihe weiterer Faktoren geprägt. ESRI ist ein erfahrener Marktführer im Bereich GIS. Des Weiteren können bei einer Wahl MapObjects die bereits für TechniData existierenden Lizenzen für MapObjects for Windows weiterverwendet werden. Ein drittes und sehr wichtiges Kriterium für die Entscheidung war, dass MapObjects eine Testversion für die Implementierung anbietet, disy jedoch nicht. Daraus ergibt sich schließlich eine Entscheidung für MapObjects for Java als Klassenbibliothek für die Entwicklung des GIS Prototypen. Seite 36 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 4 Spezifikation des Prototypen Die folgenden zwei Kapitel beschreiben den praktischen Teils der Diplomarbeit, in welcher der Prototyp entwickelt wird. Der Prototyp soll die Möglichkeiten eines Java GIS für den Einsatz im Umfeld der Umweltmessdatenvisualisierung darstellen. Für die Entwicklung wird die MapObjects Java API der Firma ESRI verwendet. Ein Prototyp ist immer ein begrenztes und nur in den Kernkonzepten ausgearbeitetes Programm, dass die wesentlichen Probleme löst und veranschaulicht. Prototypen bilden somit keine fertigen, endgültigen Lösungen, sondern vielmehr eine Vorstufe davon. Mit der Entwicklung von Prototypen werden Möglichkeiten demonstriert. Strukturen und Zusammenhänge werden offen gelegt. Erkenntnisse über Umfang und Komplexität werden gewonnen. Dies alles bildet eine wichtige Wissensgrundlage für eine spätere Produktneuentwicklung oder eine Weiterentwicklung des Prototypen zum Produkt. 4.1 Anforderungen und Rahmenbedingungen Dieses Unterkapitel legt die Anforderungen, Rahmenbedingungen und Kernkonzepte des Prototypen fest und bildet die Grundlage für die anschließende Designphase. Der Java GIS Prototyp soll sich funktional am GIS des INES RAD Systems (s. Kapitel 3.1.2) orientieren und dieses in einem weiteren Schritt um zusätzliche Features erweitern, die mit der MapObjects API und im Rahmen der zur Verfügung stehenden Entwicklungszeit von drei Monaten realisierbar sind. 4.1.1 Einordnung des Prototyps in NMC / DAISY Abbildung 4-1: Java GIS Prototyp in NMC / DAISY (Quelle: Eigene Darstellung in Anlehnung an [NMC]) Seite 37 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Der Java GIS Prototyp soll als eigene Komponente zu den bestehenden NMC Softwarebausteinen hinzufügt werden (s. Abbildung 4.1). Im Client Tier soll Java GIS durch Menüeinträge und grafische Dialoge repräsentiert werden, die es dem Benutzer ermöglichen, Kartenkonfiguration zu erzeugen und diese Konfigurationen dann zu laden und gegebenenfalls wieder zu löschen. Im Data Access Layer sollen dem Data Access Interface die notwendigen Storeklassen hinzugefügt werden, die die Kartenkonfigurationen persistent in eigenen Datenbanktabellen verwalten. Im Business Layer befindet sich die gesamte Logik des GIS, wo z.B. die Datenstrukturen verwaltet und die MapObjects Komponenten zu einer semantischen Einheit verknüpft werden. Somit vollzieht sich die Prototypentwicklung auf allen Ebenen des Drei-Schichten-Modells von NMC / DAISY. Abbildung 4-2: NMC Präsentation Layer Oberfläche Die Abbildung 4-2 zeigt die Oberfläche von NMC, in die der Prototyp eingebettet werden soll. Neben den üblichen GUI Elementen wie Menü und Statusleiste besteht NMC außerdem noch aus einem Explorer, der links oben zu sehen ist. Der Explorer ermöglicht eine Ansteuerung der verschiedenen Knoten , die in diesem Baum hierarchisch angeordnet sind und Programme oder Datenkomponenten (wie z.B. Messstationen) repräsentieren. Jeder Knoten hat eine Menge von Kontexten, mit der beispielsweise Programmfunktionen angesteuert werden können. Wenn man auf einen Knoten mit der rechten Maustaste klickt, erscheint ein Kontextmenü, dass knotenabhängige Optionen bietet. Links unten befindet sich die Hauptauswahl, wo Messstationen per Drag and Drop aufgenommen und nach Bedarf selektiert werden können. Hier ist es auch möglich Messstationsgruppen zu bilden oder einzelne Selektionen abzuspeichern. Seite 38 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 4.1.2 Anwendungsfallanalyse Abbildung 4-3: Anwendungsfalldiagramm Es gibt insgesamt vier Anwendungsfälle, mit denen der Prototyp von Außen angesteuert bzw. konfiguriert wird. Der Administrator legt die Layer direkt in der Datenbank an, d.h. er registriert die Vektor- oder Rasterdateien, die von der Software später als Layer zu einer Karte zusammengefügt werden. Der Benutzer kann daraufhin mit den vorhandenen Layern eine Kartenkonfiguration erzeugen. Weiterhin kann er eine bestehende Konfiguration visualisieren und sie gegebenenfalls auch wieder löschen. Diese Anwendungsfälle repräsentieren ein solides Grundgerüst für den Prototypen, das später um weitere Fälle ergänzt werden kann. Innerhalb dieser Anwendungsfälle befinden sich selbstverständlich noch weitere Kommunikationsschnittstellen zur Messnetzsoftware, auf die später eingegangen wird. Seite 39 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Die Anwendungsfälle im Detail: Anwendungsfall Nr. 1 Anwendungsfall: Layer anlegen Akteur: Administrator Beschreibung: Der Layer wird durch einen Eintrag in eine Java GIS Datenbanktabelle erfasst. Anwendungsfall Nr. 2 Anwendungsfall: Kartenkonfiguration anlegen Akteur: Benutzer Beschreibung: Die Kartenkonfiguration wird mittels eines Dialoges erfasst. Innterhalb der Kartenkonfiguration können alle Layer (Kartenschichten), die in der Datenbank erfasst sind, verwendet werden. Nach dem Speichern erscheint die Kartenkonfiguration im NMC Explorer als Knoten. Anwendungsfall Nr. 3 Anwendungsfall: Kartenkonfiguration visualisieren Akteur: Benutzer Beschreibung: Das Kontextmenü des Kartenkonfigurationsknotens wird geöffnet und der Kontext für die Visualisierung ausgewählt. Der Java GIS Prototyp wird mit der Kartenkonfiguration geladen und dargestellt. Anwendungsfall Nr. 4 Anwendungsfall: Kartenkonfiguration löschen Akteur: Benutzer Beschreibung: Das Kontextmenü des Kartenkonfigurationsknotens wird geöffnet und der Kontext zum Löschen ausgewählt. Die Kartenkonfiguration wird aus dem NMC Baum gelöscht. Die Layer bleiben jedoch erhalten, da diese ausschließlich vom Administrator verwaltet werden. Seite 40 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 4.1.3 Pflichtenheft Das Pflichtenheft enthält alle gewünschten Funktionalitäten, die seitens TechniData für eine Basisimplementierung des Prototypen notwendig sind und aus den zuvor entwickelten Anwendungsfällen resultieren. Die Funktionalitäten wurden mit den technischen Möglichkeiten der MapObjects API im Vorfeld grob abgestimmt und enthalten außerdem die Kernfunktionalität des INES RAD GIS Pakets. Das Pflichtenheft unterteilt sich in zwei Teilbereiche. Zum Einen in reine GIS Funktionalität und zum Anderen in die Integration, d.h. die Verbindung des Prototypen mit NMC / DAISY. Java GIS Funktionalität 1) Visualisierung von Layern und Karten 2) Visualisierung von Legenden 3) Standardnavigationselemente für Zoom und Verschieben der Karte 4) Grafische Repräsentation von Stationspunkten 5) Speicherung der Karte als Bilddatei 6) Kontextmenü für Stationspunkte 7) Wertabhängige Visualisierung von Stationspunkten 8) Visualisierung zeitlicher Abläufe Integration des GIS Prototypen in NMC / DAISY 9) Anpassung des Prototypen an das Model-View-Controller Pattern von NMC / DAISY 10) Datenmodel zur Abspeicherung der Kartenkonfiguration 11) Storeklassen zur Abspeicherung der Kartenkonfiguration 12) Dialog für die Kartenkonfiguration 13) Austausch von Messstationsdaten über die NMC Hauptselektion 14) Abfrage von Messwerten Tabelle 4-1: Pflichtenheft des Prototypen 4.1.4 Architekturanalyse Da die zu entwickelnde Software in die bereits bestehende Messnetzapplikation NMC / DAISY integriert wird, ist es wichtig deren Architektur frühzeitig einzubeziehen. Die Integration des GIS Prototypen in NMC erfordert die Implementierung des Projektes als MVC Pattern. Die Klassen werden unterteilt in Model- und Viewklassen. Der Controller selbst wird durch den bereits existierenden NMC Navigationsbaum bereitgestellt. Dieser Controller wird durch Datenbankeinträge konfiguriert und so mit den Model- und Viewklassen verbunden. Seite 41 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 4.1.5 Evaluierung verschiedener Kernkonzepte Da MapObjects nur mit einigen wenigen Beispielen und einer sehr rudimentären Dokumentation verfügbar ist, stellt es sich als sinnvoll heraus, wichtige Kernkonzepte anhand eines ersten explorativen Prototypen 22 herauszuarbeiten. Mit diesem initialen Prototypen sollen die ersten Erfahrungen mit der API gewonnen werden, die sich als sehr hilfreich für die weitere Konzeption herausstellten werden. Die folgenden zwei Kernkonzepte, die für das weitere Prototypdesign von entscheidender Wichtigkeit sind, sollen hier in ausführlicher Form beleuchtet werden. 4.1.5.1 Grafische Repräsentation von Stationspunkten Die grafische Darstellung von Stationspunkten stellt eine besondere Herausforderung dar, da hierfür kein statischer Layer verwendet werden kann. Der Layer hat dynamischen Charakter, da er ständiger Veränderung ausgesetzt ist. Das Verhältnis eines persistenten Standardlayers zu diesem Stationslayer ist vergleichbar mit dem Verhältnis einer statischen HTML Seite zu einer dynamischen. Es muss also ein Weg gefunden werden, diese Stationspunkte in einer effizienten Art und Weise auf einem Layer zu vereinen, der möglichst flexibel als solcher mit MapObjects behandelt werden kann. MapObjects bietet für den Aufbau von Karten durch Layer eine umfangreiche Interface- und Klassenhierarchie. Abbildung 4-4: Layer in MapObjects (Quelle: [MapO]) Für die Implementierung bieten sich die beiden Klassen BaseFeatureLayer und BaseGraphicsLayer an (s. Abb. 4-4). 22 [Oest98], S. 146 Seite 42 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Das erste Konzept: In einem ersten Versuch wird ein BaseGraphicsLayer als Zeichenlayer in den AcetateLayer von MapObjects eingebunden. Dieser AcetateLayer wird mit dem DrawLayer assoziiert. Der DrawLayer stellt eine eigene Klasse dar, die alle Stationspunkte kapselt und somit einen geordneten Zugriff auf deren Daten ermöglicht. Der AcetateLayer ist ein transparenter Layer, der immer verwendet werden muss, wenn eine eigene Grafik über die bestehenden Layer gelegt werden soll. Auf den BaseGraphicsLayer können dann alle Stationspunkte gesetzt werden. Der DrawLayer wird als Layer der Karte hinzugefügt und die Stationspunkte sind sichtbar. Nachteil dieses Vorgehensmodells: Durch selbstständiges Hinzufügen von Punkten, ohne die Nutzung des MapObjects Layer Beans, werden diese lediglich auf der Karte angezeigt. Die Punkte werden nicht im Table of Contents in Form einer Legende dargestellt. Die grafische Repräsentation muss in diesem Fall also vollständig eigenverantwortlich verwaltet werden. Das ist leider äußerst aufwendig. Dieser gravierende Nachteil ist der Antrieb zur Evaluierung eines zweiten Konzepts, das den Nachteil des ersten Ansatzes ausräumen sollte. Das zweite Konzept: Bei diesem Konzept baut der DrawLayer nicht wie zuvor den Layer visuell auf, sondern generiert lediglich die Datenstruktur dafür. Diese Datenstruktur wird dann als temporäre ESRI Shape Datei auf die Platte geschrieben. Die API bietet dafür eine Klasse zur Erzeugung von Shape Dateien. Mit dem MapObjects Layer Bean wird dieser temporäre Layer wieder eingelesen und mit der Hauptapplikation verbunden. Dabei unterscheidet sich der generierte Layer nur in dem Punkt, das er vom Programm erzeugt wird, wohingegen die anderen Layer extern vorhanden sein müssen. Um den Layer als Datei exportieren zu können, ist es notwendig, die BaseFeatureLayer Klasse als Datencontainer zu verwenden. Hier werden Punkte als Features eingesetzt. Jede Messstation ist solch ein Featurepunkt mit einer x und y Koordinate. Seite 43 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Abbildung 4-5: DrawLayer generiert temporäre Shape Datei Somit ist der DrawLayer von der direkten Visualisierung gelöst. Das Layer Bean sorgt automatisch dafür, dass der Layer mit all seinen Stationspunkten sowohl in der Kartenansicht, als auch im Table of Contents korrekt dargestellt wird. Diese Vorgehensweise arbeitet wesentlich näher am Programmiermodell der ESRI MapObjects API und sollte sich auch positiv auf zukünftige Weiterentwicklungen auswirken. 4.1.5.2 Erkennung eines Mausklicks auf einem Stationspunkt Die Einbindung der Stationspunkte in den BaseFeatureLayer und der Import in die Karte sorgen lediglich für eine korrekte Visualisierung. Ein Maussignal für das einzelne Feature wird jedoch grundsätzlich nicht bereitgestellt und ist selbst zu programmieren. Diese Möglichkeit sollte auf jeden Fall vorhanden sein um Funktionalität auf Messstationen legen zu können. Dafür muss also ein Mechanismus geschaffen werden, mit dem man die Features in der Karte erkennen kann, nachdem auf sie geklickt wurde. Jedes Feature wird durch ein Symbol auf der Karte visualisiert. Dieses Symbol repräsentiert den Koordinatenpunkt, der ohne dieses kaum zu erkennen wäre. Jedes Symbol hat eine bestimmte Symbolgröße, die in x und y Koordinaten angegeben ist. Der Benutzer möchte selbstverständlich das Feature ansteuern können, wenn er auf das Symbol klickt. Somit benötigt man einen Algorithmus, der es ermöglicht das Feature zu erkennen, wenn das Symbol an einer beliebigen Stelle angeklickt wird. Generell muss man zwischen zwei verschiedenen Koordinatenarten innerhalb der Karte unterscheiden: 1. Bildschirmkoordinaten: Das sind die Koordinaten der Karte relativ zum Bildschirm. Der Ursprung liegt in der linken oberen Ecke der Kartenansicht. Die x Koordinate bewegt sich zwischen dem linken Rand der Kartenansicht, dem Nullpunkt, und dem rechten Rand der Kartenansicht, wo der Maximalwert liegt. Die y Koordinate hat am oberen Rand ihren Seite 44 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Nullpunkt und am unteren ihr Maximum. Dieses Koordinatensystem findet sich übrigens überall, wo Bildschirmkoordinaten verarbeitet werden. 2. Weltkoordinaten: Hierbei handelt es sich um das Kartenkoordinatensystem. Im Falle eines Koordinatensystems mit Längen- und Breitengraden liegt der Nullpunkt an der Stelle, wo sich der Äquator und der Nullmeridian schneiden. Der Algorithmus berechnet einen unsichtbaren Rahmen um die Stelle, wo der Benutzer sein Maussignal ausgelöst hat. Alle Features die in diesem Rahmen liegen bilden die Ergebnismenge der gefundenen Stationspunkte. Mit den beiden genannten Koordinatensystemen muss gerechnet werden, da der Suchrahmen die gleichen Abmessungen im Weltkoordinatensystem haben muss, wie das Symbol im Bildschirmkoordinatensystem. Das muss immer gelten, egal welcher Kartenmaßstab vorliegt. Wie wird diese Bedingung hergestellt bzw. garantiert? Der unsichtbare Suchrahmen wird in folgenden Schritten aufgebaut (Pseudocode): S = Seitenlänge des Symbols in Bildschirmpixeln 1. Mausklick wird erfasst 2. Screen0 = Bildschirmkoordinate des Mausklicks 3. World0 = Weltkoordinate des Mausklicks (API Methode) 4. Screen1 = Punkt ( Screen0.X – S/2, Screen0.Y + S/2) 5. World1 = transformiere Screen1 in Weltkoordinaten (API Methode) 6. Screen2 = Punkt ( Screen1.X + S, Screen1.Y + S) 7. World2 = tranformiere Screen2 in Weltkoordinaten (API Methode) 8. DistanzX = Distanz der X Koordinaten von World1 und World2 9. DistanzY = Distanz der Y Koordinaten von World1 und World2 10. Rahmen = Rahmen zwischen Punkt (World1.X, World1.Y) und Punkt(World1.X + DistanzX, World1.Y + DistanzY) Seite 45 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Abbildung 4-6: Algorithmus zur Featureerkennung Innerhalb dieses Rahmens wird mittels einer Query, die von der MapObjects API bereitgestellt wird, räumlich nach Features gesucht. Da sich der Featurepunkt immer in der Mitte des Symbols befindet, kann mit dieser Methode das Feature immer erkannt werden, egal an welcher Stelle des Symbols der User klickt. Abbildung 4-7: Beispiele für Stationspunkterkennung Das Prinzip soll abschließend noch durch zwei Beispiele demonstriert werden. Im Beispiel 1 liegt das Feature außerhalb des Suchrahmens und wird somit nicht erkannt. Das ist auch beabsichtigt, da außerhalb des Symbols geklickt wurde. Im zweiten Beispiel jedoch wird innerhalb des Symbols geklickt, der Suchrahmen schneidet sich automatisch mit dem Feature und es wird erkannt. Das Gleiche funktioniert von jeder beliebigen Seite. Seite 46 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 4.2 Objektorientiertes Design Das objektorientierte Design schließt sich sinngemäß an die Phase der objektorientierten Analyse an. Hierzu ist allerdings anzumerken, dass dieser Übergang nicht scharf und absolut, sondern eher fließend zu sehen ist. Auch in dieser Diplomarbeit wurden bereits in der Analysephase entsprechende Design- und sogar Codeabschnitte erarbeitet, um mit den daraus gewonnen Erkenntnissen eine sinnvolle Analyse zu ermöglichen. Die Evaluierung anhand eines ersten Prototypen ist eine anerkannte Vorgehensweise, um die notwendigen Erkenntnisse zu sammeln. 4.2.1 UML Klassendiagramme Alle hier aufgeführten UML Klassendiagramme sind mit der Rational Rose Professional J Edition entstanden. Das Klassendiagramm wurde zu Gunsten der Übersicht auf mehrere Grafiken verteilt, die hier zwar getrennt beschrieben aber dennoch in einem gemeinsamen Kontext zu sehen sind. Um die Zusammenhänge besser erfassen zu können, wurde wichtige Klassen in mehreren Teilmodellen verwendet. Seite 47 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 4.2.1.1 Hauptapplikation Die Hauptapplikation besteht im Wesentlichen aus den beiden Klassen MapShowFrame und MapShowFrameUI. MapShowFrame muss von der NMC Klasse BasicInternalFrame die Methode setModel() erben, da nur so eine erfolgreiche Einbindung in das NMC Framework möglich ist. Das MapConfigurationModel wird dem MapShowFrame dann zugewiesen. Die MapShowFrameUI Klasse ist lediglich eine Auslagerung der UI-Elemente 23 dar, was ausschließlich der Übersicht dient. Hier werden alle grafischen Elemente in den Frame für die Visualisierung der Kartenkonfiguration 24 gesetzt. Der DrawLayer stellt in dieser GUI Klasse das Hauptelement dar und wird im Anschluss erläutert. Abbildung 4-8: UML Klassendiagramm der Hauptapplikation 23 24 User Interface Elemente Siehe Anwendungsfall Nr. 3 in Kapitel 4.1.2 Seite 48 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 4.2.1.2 DrawLayer Der DrawLayer ist wohl die wichtigste Komponente des Prototypen. Er verwaltet den dynamischen Layer durch Exportieren der entsprechenden ESRI Shape Datei und den anschließenden Rückimport in die Karte der Hauptapplikation. Er verwaltet die Kartenfeatures (Stationspunkte) in einem Vektor aus GISFeature Objekten 25. Abbildung 4-9: UML Klassendiagramm des DrawLayer Diese GISFeature Objekte repräsentieren intern die Messstationen und bestehen im Wesentlichen aus einer MeasureLocation (also der Position der Messstation) und einer ValueSeries (einer Messwertmenge). Somit kann für jeden Punkt eine genaue Koordinate und 25 Leider kann diese Beziehung von Rational Rose im Klassendiagramm nicht dargestellt werden. Der Grund dafür ist der statische Charakter des Klassendiagramms. Da die GISFeatures zur Laufzeit in den Vector eingefügt werden, besteht in der statischen Sichtweise des Klassendiagramms keine Beziehung zwischen dem Vector und des GISFeatures. Seite 49 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten eine Reihe von Messwerten gespeichert werden. Die Messwertreihe repräsentiert damit einen zeitlichen Abschnitt, in dem z.B. jeder Wert einer 10 Minuten Messung entspricht. Der DrawLayer implementiert einen Observer, da die Klasse bei jeder Änderung der Messstationen eine Erneuerung der temporären Shapedatei veranlassen muss um die Aktualität zu bewahren (s. Abb. 4-5). Der DrawLayer implementiert außerdem einen MouseListener, um beim Klick auf ein Feature im Layer reagieren zu können. Eine mögliche Variante auf ein solches Event zu reagieren ist ein sog. PopupMenü. Wenn der Benutzer mit der rechten Maustaste auf das Symbol einer Messstation klickt, erscheint ein Menü, mit der er die Station entfernen oder Stationsdaten abfragen kann. Dieses Menü soll als Beispiel umgesetzt werden (s. Klasse FeaturePopupMenu). Die zwei Toolbars der Applikation arbeiten ebenfalls eng mit dem DrawLayer zusammen. Mit der SelektionToolBar Klasse können die Stationspunkte grafisch ausgewählt werden, um beispielsweise in einem nächsten Schritt eine Gruppenoperation durchzuführen. Die TimeToolbar schließlich soll die Visualisierung der zeitlichen Abläufe ermöglichen und verfügt über einen Mechanismus, den angezeigten Messwert des GISFeatures zu variieren und den Refresh des DrawLayers auszulösen. Durch das Design dieser beiden Klassen ist diese Toolbar gut zu adaptieren. Seite 50 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 4.2.1.3 Kartenkonfigurations- und Modelklassen Die Kartenkonfiguration folgt den Model-View-Controller Pattern, welcher von der Messnetzzentrale NMC vorgeschrieben wird. Das MapConfiguationModel stellt das Modell dar, dass vom MapConfigurationFrame als View assoziiert wird. Diese View ist eine zusammengesetzte GUI, die aus drei weiteren Panels besteht (SubPanelName, SubPanelVersion und SupPanelLayerChoose). Diese Aufteilung wurde vorgenommen, um ein möglichst hohes Maß an Wiederverwendung innerhalb der GUI Entwicklung zu ermöglichen. Die ersten beiden Panels waren bereits vorhanden und bieten Standard GUI Komponenten zur Erfassung von Grunddaten. Die SubPanelLayerChooser Klasse soll ein grafisches Frontend für die Aufnahme der gewählten Layer bieten. Die MapShowFrame Klasse ist ebenfalls mit dem Modell assoziiert, da für die Visualisierung die Layerdaten ebenfalls benötigt werden. Abbildung 4-10: UML Klassendiagramm der Kartenkonfiguration mit Modellklassen Seite 51 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 4.2.1.4 Storeklassen Abbildung 4-11: UML Klassendiagramm der Storeklassen Die Storeklassen stellen die Persistenz der Kartenkonfiguration sicher und sorgen für den Datenaustausch zwischen den Modelklassen und den Datenbanktabellen, die nachfolgend beschrieben werden. Für jede Datenbanktabelle existiert genau eine Storeklasse. Des Weiteren existieren zwei Modellklassen, die wiederum einen festen Bezug zu den Storeklassen besitzen. Die nachfolgende Tabelle soll diese Zuordnungen deutlicher machen: Modellklasse LayerSource Storeklasse LayerSourceStoreJdbc LayerSourceCollectionStoreJdbc MapConfigurationModel Datenbanktabelle JGIS_LAYER JGIS_DIALOGMODEL _ASSO MapConfigurationModelStoreJdbc JGIS_DIALOGMODEL Tabelle 4-2: Zuordnung von Modellklassen, Storeklassen und DB-Tabellen Die beiden ersten Storeklassen bieten genau eine read, eine write und eine remove Methode. Die LayerSourceStoreJdbc benötigt lediglich eine read Methode, da die Layer applikationsseitig nicht gelöscht werden. 26 Die MapConfigurationModelStoreJdbc ist die einzige vom System angetriggerte Klasse, die nach dem Ausführen der eigenen Arbeit die anderen Storeklassen nutzt um die LayerSource Modelle zu laden. 26 Siehe Kapitel 4.1.2 Seite 52 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 4.2.2 Datenmodel der Kartenkonfiguration Das Datenmodell ermöglicht es, Kartenkonfigurationen in der Datenbank abzubilden, welche von den Storeklassen gelesen und geschrieben werden. Die Tabelle JGIS_LAYER wird ausschließlich vom Administrator benutzt um Karten zu registrieren und enthält den Vorrat an verfügbaren Karten, die der Benutzer für seine Kartenkonfiguration einsetzten kann. Jeder Layer verfügt über eine eindeutige Identifikation, einen Namen, eine Beschreibung und einen Pfadnamen, der auf die Layerdatei zeigen muss. Die Tabelle JGIS_DIALOGMODEL bildet das MapConfigurationModel ab und enthält alle Informationen für die Identifizierung des Models, wie z.B. die Bezeichung der Konfiguration und die ID des Erstellers. Die JGIS_DIALOGMODEL_ASSO Tabelle assziiert die beiden zuvor beschriebenen Tabellen durch jeweils einen Fremdschlüssel und ermöglicht somit, dass eine Kartenkonfiguration beliebig viele Layer der Layertabelle enthalten darf. Durch den kombinierten Primary Key aus den beiden Feldern DIALOGMODEL_ID und ORDER_ID ist es möglich, mehrmals den gleichen Layer zu zuordnen, wobei die ORDER_ID die Stelle beschreibt, in der der Layer in die Karte gelegt wird 27. Abbildung 4-12: Datenmodell zur Speicherung der Kartenkonfiguration 27 ORDER_ID = 5 bedeutet somit, dass der Layer an fünfter Stelle in der Karte erscheint und beispielsweise den Layer Nr. 4 grafisch überlagert. Seite 53 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 5 Implementierung Die Teilimplementierungen des explorativen Prototypen der Analysephase können zum Teil übernommen werden und bilden den ersten Kern der Applikation. Das sind vor allem die GUI Klassen zum struktuellen Aufbau der Visualisierungsoberfläche (MapShowFrame und MapShowFrameUI) und die evaluierten Mechanismen aus Kapitel 4.1.5 in der DrawLayer Klasse. Ausgehend von diesem Kern werden die Klassen sukzessive erweitert und um die Klassen der Designphase ergänzt. Die nachfolgenden Unterkapitel beschreiben den finalen Entwicklungsstand nach Codierungsende. 5.1 Implementierung der logischen Klassen 5.1.1 Modelklassen LayerSource und MapConfigurationModel Die beiden Klassen LayerSource und MapConfigurationModel stellen die Modellklassen für die Kartenkonfiguration dar. LayerSource ist ein reiner Datencontainer, der lediglich die Layerdaten, (wie z.B. Name und Pfad der Layerdatei) hält und mit Get und Set Methoden Zugriff darauf bietet. Im MapConfigurationModel wird ein LayerSource Vector gehalten. Mit der Methode getStoreName wird die Beziehung zur Storeklasse hergestellt, wie sie in Tabelle 4-2 veranschaulicht ist. 5.1.2 DrawLayer und GISFeature Die DrawLayer Klasse stellt die umfangreichste Klasse des Prototypen dar. In ihr sind die interessantesten Konzepte vereinigt. Die Mausklickerkennung auf den Stationspunkten wurde in Kapitel 4.1.5.2 ausführlich erklärt und konnte von dem ersten Prototypen übernommen werden. Dem ist nichts mehr hinzuzufügen. Der DrawLayer hat vier weitere Aufgaben, die nachfolgend beschrieben werden. 5.1.2.1 Synchronisation mit der Hauptselektion Der DrawLayer besitzt eine einzige Schnittstelle für den Datenaustausch von Messstationen und Messwerten. Das ist die Hauptselektion von NMC (siehe Kapitel 4.1.1). Die im DrawLayer enthaltenen Messstationen sollen stets synchron zu denen in der Hauptselektion vorhandenen Stationen sein. Aus diesem Grund ist der DrawLayer ein Observer der Hauptselektion und wird folglich angetriggert, wenn sich etwas in der Seite 54 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Hauptselektion ändert. Alle Messstationen, für die Messwerte existieren und in der Hauptselektion vorhanden sind, werden in den DrawLayer importiert und entsprechend den Einstellungen visualisiert. Alle Messstationen, für die Messwerte existieren und in der Hauptselektion markiert werden, sind auch im DrawLayer selektiert. Die Methode updateFromMainSelection, die entweder direkt aus der Applikation oder über die überschriebene update Methde des Observers aufgerufen wird, regelt diese Synchronisationsrichtung. Das gleiche gilt auch für die entgegengesetzte Richtung und wird von der Methode updateToMainSelection durchgeführt. Diese Methode wird jedoch ausschließlich von den Prototyp Klassen aufgerufen und ist kein Bestandteil der Observer Implementierung. 5.1.2.2 Grafische Repräsentation von Stationspunkten Die grafische Repräsentation der Messstationspunkte wird, wie bereits in Kapitel 4.1.5.1 beschrieben, vom Layer Bean übernommen. Die Methode refreshDrawLayer wird immer gerufen, wenn ein solcher Reimport gewünscht wird. Diese Methode entfernt den vorhandenen BaseFeatureLayer aus der Karte. Sie ruft die Methode exportFile, die die GISFeatures als neue temporäre ESRI Shape Dateien 28 exportiert und die vorherigen überschreibt. Die Shape Dateien auf der Festplatte stellen somit immer die aktuelle Konfiguration der Messstationen im GIS Prototypen dar. In der shp Datei werden die Stationspunkte abgelegt und in der dbf Datei die zugehörigen Messwerte. Die Export Methode legt den Wert ab, den die getValue Methode von GISFeature zurückgibt. GISFeature verwaltet intern einen Index, der zwischen den Feldgrenzen der Messwertreihe liegt. Somit wird immer die aktuelle Position gespeichert. Diese Vorgehensweise ist notwendig um unterschiedliche Messungen einer Messstation visualisieren zu können. Die Methode importFile fügt diese Datei sehr einfach wieder als neuen BaseFeatureLayer in die Karte ein und verknüpft sie mit den bereits bestehenden Einstellungen 29. Somit bleibt die Darstellung auch nach einer Aktualisierung erhalten und geht nicht verloren. Ein Stationspunkt wird am Anfang durch ein einfaches, farbiges Quadrat dargestellt, welches dann vom Benutzer in vielfältiger Art und Weise angepasst werden kann. Durch Einsatz des PropertyDialog Beans ist es möglich jeden Shape Layer, und somit auch den DrawLayer, in seinem Aussehen zu verändern. Symbole können in ihrer Größe, Farbe und Form verändert werden. Die Darstellung kann für jedes Feature gleich oder abhändig von ihrem Wert variieren. 28 Das sind drei Dateien, die den gleichen Namen tragen und sich nur in den Dateiextensionen unterscheiden. Die shp Datei enthält die geografischen Elemente, die shx Datei ist eine Indexdatei für die Verwaltung und die dbf Datei enthält Datensätze, mittels derer Daten zu den geografischen Elementen zugewiesen werden können. Durch den gleichen Namen vor der Dateiextension erkennt MapObjects die Zugehörigkeit. Siehe auch [http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf], Seite 2. 29 Einstellungen werden über sogenannten Renderer realisiert. Mit ihnen kann man die Darstellung von Features individuell anpassen. Renderereinstellungen beziehen sich z.B. auf Farbe, Form oder die Transparenz der Symbole. Mit einem Labelrenderer können die Beschriftungen der Messstationen konfiguriert werden. Seite 55 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Zum Abschluss erhält die Karte selbst noch einen Refresh, um sicher zu gehen, dass sie auch neu gezeichnet wird. 5.1.2.3 Verwaltung der Stationspunkte als GISFeature Objekte Alle Stationspunkte werden als GISFeature Objekte verwaltet, wobei der DrawLayer in dieser Beziehung als Containerklasse arbeitet und Methoden zum Hinzufügen, Prüfen und Löschen solcher Objekte bietet. Jedes dieser Objekte repräsentiert eine DrawLayer interne Messstation. Lediglich die Koordinaten, der Name und der aktuelle Messwert (Messwert auf den der GISFeature Index zeigt) werden für den Export des temporären Layers benötigt. Es wurde so festgelegt, da es möglich sein soll, neben dem reinen Punkt auch den Namen der Station und des Messwert visualisieren zu können. Bei der Visualisierung werden die Features durch den Import der temporären Daten automatisch gewonnen. Jeder Punkt ist also genau zweimal vorhanden. Einmal visuell im Layer Bean in der Karte und einmal als GISFeature Objekt im DrawLayer. Die angereicherte interne Repräsentation der Messstationen als GISFeatures ist für den Überblickscharakter der TimeToolBar notwenig. Für die Visualisierung ist der aktuell sichtbare Bereich allerdings ausreichend. Dies soll auch Resourcen schonen. Wenn bei jedem Refresh z.B. nicht ein Messwert pro Station, sondern 1000 reimportiert werden würden, würde das sicher zu einem Performanceproblem führen. 5.1.2.4 Laden einer ValueSeries aus der Datenbank Beim Aufbau eines GISFeature Objektes wird auch die ValueSeries 30 geladen. Dies geschieht in der loadValues Methode durch den Einsatz der NMC eigenen ClientConnector Klasse, die unter Nutzung der Storeklassen des NMC Datenmodells die ValueSeries extrahiert. Der ClientConnector arbeitet mit einem MeasureLocation Objekt, einem MeasuringSelector Objekt und zwei Zeitstempeln, die den Beginn und das Ende der Messreihe definieren. Für den Prototypen wird die Parametrierung des MeasuringSelection Objekts fest mit einer Konfigurationsdatei definiert. Die Konfigurationsdatei enthält die Einstellungen für die Messung von Gamma Strahlung als 10 Minuten Mittelwerte. Als Zeitstempel werden ebenfalls zwei feste Daten eingesetzt. Als Resultat liefert er nach mehreren Schritten ein Wertearray, dass die Messwerte der Station bei dieser Parametrierung enthält. Dabei handelt es sich um ein eine Zahlenreihe. Diese Zahlenreihe wird zusammen mit dem MeasureLocation Objekt und einem Index dazu genutzt, das GISFeature Objekt aufzubauen und im DrawLayer Container abzulegen. Der Index legt fest, welcher Wert momentan visualisiert wird und wird später noch eingehender im Zusammenhang mit der TimeToolBar erläutert. Existieren keine Werte für eine Station, weil z.B. für die Zeitperiode keine Messungen vorliegen, wird die Messstation auch nicht in den DrawLayer übernommen. 30 Siehe auch Kapitel 4.2.1.2 unten Seite 56 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 5.1.3 Storeklassen Die drei Storeklassen MapConfigurationModelStoreJdbc, LayerSourceCollectionStoreJdbc und LayerSourceStoreJdbc sichern die Persistenz des Konfigurationsdialogs. In den Storeklasse wird die bisher abstrakte Handhabung der Datenbank konkretisiert. Die Datenbanktabellen und Felder sind hier als Zeichenketten hinterlegt und werden entsprechend für den Zugriff genutzt. Die Storeklassen bauen die einzelnen SQL Anweisungen zum Schreiben, Lesen und Entfernen von Konfigurationen auf. Beim Zugriff auf die Daten werden an den notwenigen Stellen Transaktionsbereiche mit Hilfe von Java Try-Catch Blöcken eingerichtet. Dies wird z.B. beim Ausführen einer SQL Anweisung nötig. Sollte die Anweisung scheitern, wird eine SQLException ausgelöst, welche daraufhin zum letzten konsistenten Datenbankstatus zurückkehrt 31. 5.2 Implementierung der grafischen Klassen 5.2.1 MapConfigurationFrame und SubPanelLayerChooser Das MapConfigurationFrame bildet die grafische Schnittstelle des zweiten Anwendungsfalles, mittels dessen der User in der Lage ist Kartenkonfigurationen anzulegen. Abbildung 5-1: MapConfigurationFrame mit SubPanelLayerChooser Die Umsetzung des MapConfigurationFrames erfolgt durch das Zusammensetzen dreier Panels, die in der Grafik jeweils mit einem schwarzen Rand umrissen sind. Die zwei oberen Panels (SubPanelName und SubPanelVersion) sind bereits fester Bestandteil von NMC. Der untere Panel (SubPanelLayerChoose) ist eine Eigenentwicklung nach dem Vorbild der beiden 31 Das ist ein sogenannter Rollback. Seite 57 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten anderen. Mittels des „Add layer...“ Buttons können neue Layer zur Kartenkonfiguration hinzugefügt werden. Bestehende Layer können außerdem markiert und durch Drücken des „Remove layer ...“ Buttons entfernt werden. Im Prototyp wird nach dem Betätigen des „Add“ Buttons immer ein fester Satz Layer aus der Datenbank hinzugefügt. Diese fest codierte Verhaltensweise kann später durch einen weiteren Dialog ausgebaut werden. Dieser Dialog könnte es ermöglichen, bestehende Layer der Datenbank darzustellen. Der User könnte dann aus dem Portfolio an verfügbaren Layern frei auswählen und sich so seine Konfiguration zusammenstellen. 5.2.2 FeaturePopupMenu und PropertyDialog Diese beiden grafischen Komponenten veranschaulichen den Gebrauch der Stationspunkterkennung im DrawLayer. Das FeaturePopupMenu wird aufgerufen, wenn ein Stationspunkt im DrawLayer erfolgreich erkannt wird und dabei die rechte Maustaste gedrückt wurde. Abbildung 5-2: FeaturePopupMenu Dieses Menü bietet lediglich zwei Optionen, die einen demonstrativen Charakter haben. Der Punkt kann aus dem DrawLayer entfernt werden (Option Delete). Des Weiteren können Informationen über die Station dargestellt werden (Option Properties), wofür der PropertyDialog eingesetzt wird. Seite 58 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Abbildung 5-3: PropertyDialog Dieser Dialog stellt die wichtigsten Daten dar, die im zugehörigen GISFeature Objekt abgelegt sind. Dies sind u.a. der Name der Station und die Liste der ausgelesenen Messwerte. 5.2.3 SelektionToolBar Die SelectionToolBar ist eine GUI Komponente, die die drei wichtigsten grafischen Selektionstools der MapObjects API enthält und im Prototyp fest mit dem DrawLayer verknüpft ist. Somit können die Stationspunkte elegant selektiert werden. Abbildung 5-4: SelectionToolBar Bei der Auswahl einer der drei möglichen Buttons wird eine LayerSelect Instanz erzeugt. Dieses Objekt setzt nach Abschluss der Operation die Selektionsmenge im DrawLayer neu und triggert dessen Abgleich mit der Hauptselektion an. Dies bedeutet, dass alle im DrawLayer selektierte Messstationen auch in der Hauptselektion markiert werden. 5.2.4 TimeToolBar Die TimeToolBar Klasse führt eine neue Dimension in die bisher statische Struktur des GIS Prototypen ein und erweitert die Visualisierung um ein neues Element – die Zeit. Seite 59 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Abbildung 5-5: TimeToolBar Da eine Messstation bei der Integration im DrawLayer intern durch ein GISFeature Objekt dargestellt wird und, unter anderem, die vollständige Messwertreihe enthält, kann mit dieser Toolbar darin navigiert werden. Da ein Messwert automatisch einer bestimmten Zeit 32 zugeordnet ist, entspricht diese Navigationsmöglichkeit somit einer Zeitachse, in der man sich bewegen kann. Die Symbole auf der Toolbar lassen schon intuitiv darauf schließen, was sie zu leisten vermag. Die Bedeutungen von links nach rechts sind: 1. Schneller Rücklauf (Button 1) 2. Eine Messung zurück (Button 2) 3. Anzeige der aktuellen Position (hier bei der Initialisierung noch leer) (Textfeld) 4. Eine Messung weiter (Button 3) 5. Schneller Vorlauf (Button 4) 6. Stop (anwendbar bei 1 und 5) (Button 5) Beim Klick auf Button 2 bzw. Button 3 wird das usedValue Attribut sämtlicher GISFeature Objekte um eins vermindert bzw. erhöht und ein DrawLayer Refresh ausgelöst. Auf diese Art kann dann manuell durch den ganze Messreihe geblättert werden. Beim Klick auf Button 1 bzw. Button 4 wird ein Thread gestartet, der dies automatisch in einem vordefiniertem Zeitabstand durchführt und somit eine Art Diashow initiiert. Im Halbsekundentakt wird dann der Messwert gegen den vorherigen bzw. nächsten (falls vorhanden) ausgetauscht und ein DrawLayer Refresh ausgelöst. Diese Thread läuft kann mit Button 5 unterbrochen werden. Das Textfeld zeigt die aktuelle Position in der Messreihe an. 5.2.5 MapShowFrame und MapShowFrameUI Die beiden Klassen MapShowFrame und MapShowFrameUI enthalten fast alle Komponenten und stellen die GUI Visualisierung des 3. Anwendungsfalles dar 33. Hier werden die implementierten und die MapObjects Komponenten in einer gemeinsamen grafischen Oberfläche verknüpft. 32 33 Im Prototyp durch die feste Parametrierung von 10 Minuten Mittelwerten sind es somit 10 Minuten. Siehe Kapitel 4.1.2 Seite 60 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 5.3 Datenbankeinträge zur Visualisierung im NMC Explorer Um die Applikationsschnittstellen im NMC Explorer sichtbar zu machen, ist es notwendig, die Model und View Klassen mit den entsprechenden Datenbankeinträgen zu registrieren. Tabellenname REF_CLASSES Funktion Hier wird eine eindeutige Klassenidentifikation mit dem Klassenpfad verknüpft. Es wird weiterhin festgelegt, ob es sich bei der Klasse um ein Modell oder ein Frame (View) handelt. NMC nutzt diese Tabelle um für die automatische Objekterzeugung die richtige Klasse aufzufinden. REF_OBJECTS Hiermit werden Kontexte im Explorer gruppiert. REF_CONTEXT Hier wird der Knoten im Baum angelegt. Ein Knoten entspricht einem Kontext. Dieser Kontext wird mit einer eindeutigen ID angelegt und mit einer Klasse verbunden. Damit „kennt“ das System die aufzurufende Klasse, wenn ein bestimmter Kontext im Baum gewählt wird, und kann sie über REF_CLASSES finden. REF_CONTEXTITEMS Mittels dieser Tabelle werden die hierarchischen Beziehungen innerhalb der Kontexte definiert und aufgebaut. Es gibt Vater und Kindkontexte. Hier wird z.B. der Kartenkonfigurationskontext mit dem DAISY Kontext verbunden. Das Resultat ist dann, dass beim Aufruf des Kontextmenüs am Explorerknoten DAISY der Kontext erscheint, mittels dessen man den Dialog zur Kartenkonfiguration aktivieren kann. Tabelle 5-1: NMC Datenbankeinträge Nachdem alles richtig eingetragen ist, sind, nach einem Neustart der NMC Applikation, alle applikationsseitigen Anwendungsfälle (Anwendungsfall 2-4) über den NMC Explorer ansteuerbar. Seite 61 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 5.4 Review des Pflichtenheftes Ein Blick in das Pflichtenheft verrät, dass alle gewünschten Anforderungen an den Prototypen erfolgreich umgesetzt werden konnten. Java GIS Funktionalität 1) Visualisierung von Layern und Karten 2) Visualisierung von Legenden 3) Standardnavigationselemente für Zoom und Verschieben der Karte 4) Grafische Repräsentation von Stationspunkten 5) Speicherung der Karte als Bilddatei 6) Kontextmenü für Stationspunkte 7) Wertabhängige Visualisierung von Stationspunkten 8) Visualisierung zeitlicher Abläufe Integration des GIS Prototypen in NMC / DAISY 9) Anpassung des Prototypen an das ModelView-Controller Pattern von NMC / DAISY 10) Datenmodel zur Abspeicherung der Kartenkonfiguration 11) Storeklassen zur Abspeicherung der Kartenkonfiguration 12) Dialog für die Kartenkonfiguration 13) Austausch von Messstationsdaten über die NMC Hauptselektion 14) Abfrage von Messwerten Status Umgesetzt im ersten Prototypen und übernommen in die MapShowFrameUI Klasse. Umgesetzt im ersten Prototypen und übernommen in die MapShowFrameUI Klasse. Umgesetzt durch Verwendung vorhandener MapObjects Beans in der MapShowFrameUI Klasse. Umgesetzt in der DrawLayer Klasse. Umgesetzt im der Klasse MapShowFrameUI. Die aktuell dargestellte Karte kann als Jpeg Grafik abgelegt werden. Umgesetzt mit der Klasse FeaturePopupMenu. Umgesetzt mit der GISFeature Klasse als Datenstruktur und dem LayerPropertyBean der MapObjects API. Umgesetzt mit der TimeToolBar. Umgesetzt in Design und Implementierung. Umgesetzt mit drei Datenbanktabellen. Umgesetzt mit den drei Storeklassen: MapConfigurationModelStoreJdbc, LayerSourceCollectionStoreJdbc und LayerSourceStoreJdbc. Umgesetzt mit der Klasse MapConfigurationFrame. Umgesetzt mit den Methoden updateFromMainSelection und updateToMainSelection in der DrawLayer Klasse. Umgesetzt mit der loadValues Methode in der DrawLayer Klasse. Tabelle 5-2: Review des Pflichtenheftes Ein Screenshot des Java GIS Prototypen ist auf der nächsten Seite dargestellt. Seite 62 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Abbildung 5-6: Java GIS Prototyp Screenshot Seite 63 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 6 Zusammenfassung und Ausblick Die Diplomarbeit hat gezeigt, welche Möglichkeiten Java basierte geografische Informationssysteme bieten. Nach einem einführenden Kapitel in die allgemeine Thematik der GIS wurde eine umfangreiche Produktanalyse durchgeführt, die den Markt der verfügbaren Java GIS Klassensammlungen für die Applikationsentwicklung beleuchtete. Mittels einer Grobanalyse wurde die Menge potentieller Softwarelösungen auf vier Produkte eingeengt. Die Feinanalyse bestand aus einem umfangreichen Test, der sowohl die Produktqualitäten, als auch die funktionale Leistungsfähigkeit abprüfte. Die Basis für diese Featureliste wurde durch die vorherige Evaluierung bestehender Messnetz GIS Lösungen gebildet. Unterstützt von dem Ergebnis der Feinanalyse konnte das Produkt gewählt werden, das die Anforderungen für die anschließende Prototypentwicklung erfüllen sollte – MapObjects für Java. Im vierten Kapitel wurden die Rahmenbedingungen für den Prototypen mittels objektorientierter Analyse und Design gelegt. Ein explorativer Prototyp war notwendig um eine ausreichende Wissensgrundlage für ein gutes Design aufzubauen. Die Erkenntnisse daraus waren sehr hilfreich für den weiteren Verlauf der Planungsphase und konnten mit Teilen in die spätere Implementierung übernommen werden. Der junge Produktstatus forderte oft zeitaufwendige Detailrecherchen über interne Funktionszusammenhänge. Das Pflichtenheft konnte vollständig umgesetzt werden und der Java GIS Prototyp wurde neben sein Grundfunktionalität auch vollständig in die bestehende Messnetzzentrale NMC / DAISY eingebunden. Der Prototyp veranschaulicht verschiedene Visualisierungsmöglichkeiten für Umweltmessdaten. Neben der Standarddarstellung von Messstationen beherrscht er eine werteabhängige Messwertdarstellung, die zudem noch über einer Zeitperiode manuell oder automatisch iteriert werden kann. Eine gewinnbringende Integration, was ursprüngliche Motivation für den Prototypen war, wurde auf diese Weise gezeigt. Die Erkenntnisse über die MapObjects Klassensammlung sollen nachfolgend in einem extra Abschnitt zusammengefasst werden. 6.1 Bewertung der MapObjects Java API Nach einer Prototypdesign und -implementierungszeit von etwa 3 Monaten konnten mit der MapObjects Java API einige Erfahrungen gesammelt werden. Diese Erfahrungen werden an dieser Stelle für eine Bewertung der API herangezogen. 6.1.1 Pro 1. Reichhaltiger Funktionsumfang: Die Klassensammlung bietet reichhaltige Möglichkeiten für die Implementierung vielfältiger GIS Funktionen. Ein umfangreiches Portfolio an grafischen und funktionalen Komponenten steht ebenso zu Verfügung wie zahlreiche durchdachte Datenstrukturen für viele Aufgaben, die bei der Entwicklung einer GIS Applikation auftreten. Seite 64 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 2. Zukunft: Eine Weiterentwicklung 34 der API wird nach offiziellen Angaben durchgeführt. 3. Einige Beispiele: Einige gut gemachte kleine Beispiele halfen über die ersten Hürden der Applikationsentwicklung hinweg und konnten einige Zusammenhänge klar machen. 6.1.2 Contra 1. Schlechte Produktdokumentation: Bei Analyse, Design und Implementierung traten oft Probleme auf, die auf Grund der schlechten Dokumentation nur unter großem Zeitaufwand gelöst werden konnten. Die JavaDoc Klassenbeschreibung enthält meist nur rudimentäre Einträge und hinterlässt ein herbes Gefühl von Unreife. 2. Keine Alternativdokumentation: Es gibt weder Bücher von ESRI noch von anderen Autoren. Es konnten weiterhin auch keine externen Dokumentationsquellen gefunden werden. 3. Bug im LayerPropertyBean: Das LayerProperty Bean liefert bei der Auswahl von Icons als Symbolvisualisierung immer eine 0 als Symbolgröße, ganz gleich, was man gewählt hat. Hier handelt es sich um einen Bug der sich folglich auch im GIS Prototyp wiederfindet. 4. Keine Koordinatentransformationen: Die Klassensammlung bietet zum aktuellen Zeitpunkt noch keinerlei Funktionalität um eine Koordinatentransformation durchzuführen. Es können also nur Layer verwendet werden, die bereits im korrekten Koordinatensystem vorliegen. Messstationspunkte müssten in das jeweilige Koordinatensystem durch eigene Algorithmen umgerechnet werden, was einen erheblichen Aufwand darstellt. Abbildung 6-1: Fehlende Unterstützung von Koordinatentransformationen (Quelle: http://forums.esri.com/Thread.asp?c=9&f=1193&t=69344&mc=10) 34 Siehe Abbildung 6-1, wo von einer Betaversion der Version 2.0 gesprochen wird. Seite 65 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 6.1.3 Fazit: Pro MapObjects Java Trotz der leicht überwiegenden Contra Punkte, halte ich die MapObjects Java API für die richtige Wahl zur Erstellung von Java basierten GIS Applikationen zur Visualisierung von Umweltmessdaten. Viele Probleme bei der Arbeit mit der MapObjects Java API wurden im Rahmen dieser Diplomarbeit gelöst. Der Sourcecode des Prototypen 35 und die hier vorliegende Dokumentation bilden ein solides Fundament für weitere Projekte und mildern den unvollendeten Dokumentationsstand der API. Der Arbeitsaufwand für zukünftige Projekte wird sich deshalb stark vermindern und es ermöglichen Applikationen schneller zu entwickeln. 6.2 Ausblick Dieser Abschnitt umfasst alle Ideen, die innerhalb der Diplomarbeit leider nicht realisierbar waren, aber dennoch genannt werden sollten. Die Gedanken könnten für zukünftige Weiterentwicklungen des Prototypen im Bereich der Visualisierung von Umweltmessdaten eingesetzt werden. 6.2.1 Schnittstellenerweiterungen Der GIS Prototyp besitzt momentan lediglich die Schnittstelle zur Hauptselektion über die er Stationsdaten erhält und mittels derer Messwerte extrahiert. Für die bessere Zusammenarbeit mit anderen NMC Komponenten wäre es hilfreich weitere Schnittstellen einzurichten um eine GIS Darstellung auch aus einer anderen NMC Komponente antriggern zu können. Eine Schnittstelle könnte sogar soweit flexibilisiert werden, dass eine vollständige Automation der GIS Einheit mögliche wäre. Realisieren könnte man dies durch eine Wrapperklasse, die eine Konfiguration von Außen (Eingabe) entgegennimmt. Die Klasse könnte mittels einer Schnittstelle Methoden zur externen Ansteuerung verschiedener Funktonen anbieten und die internen Komponenten entsprechend steuern (Verarbeitung). Das Resultat könnte als Bild oder ESRI Shape Datei zurückgegeben werden (Ausgabe). 6.2.2 Verbesserung der Konfigurierbarkeit Es wäre wünschenswert, die Konfigurationsmöglichkeiten einer Karte stark zu erweitern. So könnte man z.B. Messstationen vordefiniert in einer Konfiguration ablegen, was das manuelle Hinzufügen zur Hauptselektion ersparen würde. Sinnvoll wäre auch Kartenvisualisierungsoptionen (z.B. Symboleigenschaften) in einer Konfiguration zu speichern, um nicht nach jedem Laden der Karte alles neu setzen zu müssen. 35 mit seinen etwa 3300 Zeilen dokumentiertem Quellcode Seite 66 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten 6.2.3 Automatische Generierung von Bildern Die TimeToolBar könnte mit der Methode zur Bildgenerierung gekoppelt werden. Die so erzeugten Momentaufzeichnungen könnten auf vielfältige Art und Weise weiterverarbeitet werden. Die Bilder könnten zur Generierung von Reports genutzt werden. Mit dem Einsatz von XML wären hinsichtlich Flexibilität keine Grenzen gesetzt. Somit könnten z.B. für verschiedene Kunden angepasste HTML Webseiten generiert werden. Es wäre möglich, Reports per Email zu verschicken oder die Darstellung NMC intern, z.B. bei einer Alarmmeldung, als geeignete Visualisierung zu verwenden. 6.2.4 Automatische Generierung einer Animation Sobald eine Bilderreihe für einen bestimmten Zeitraum verfügbar ist, wäre es auch denkbar, mittels eines entsprechenden Tools eine GIF89 Animation 36 zu erzeugen, um sie z.B. auf einer Webseite darzustellen. 36 Anschauliche Beispiele darüber finden sich auf [http://www.geogr.unijena.de/~p6taug/demviewer/demv.html] Seite 67 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Literaturverzeichnis [DAISY] TechniData DAISY Produktbeschreibung [MapO] MapObjects Java Hilfe [NMC] TechniData ENVINET-NMC Produktbeschreibung [Frit94] Fritsch, Dieter: Raumbezogene Informationssysteme und digitale Geländemodelle, C.H. Beck, 1994 [Goep87] Göpfert, Wolfgang: Raumbezogene Informationssysteme, Karlsruhe 1987 [Oest98] Oestereich, Bernd: Objektorientierte Softwareentwicklung. Analyse und Design mit der Unified Modeling Language, 4. Auflage, Oldenbourg, München u.a. 1998 [Saur97] Saurer, Helmut; Behr, Franz-Josef: Geografische Informationssysteme. Eine Einführung, Darmstadt 1997 [Wilk86] Wilkinson, G.G. et. al: Review of Integrated Geo-Information Systems Techniques. A Study on Integrated Geo-Information Systems (Final Report on ESA Contract No. 6084/84/D/JS/SC), 1986 Seite 68 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Internetquellen Compass Informatics, http://www.compass.ie/geoshop/categories/devtools-index.html, 10.05.2002 DEMViewer, http://www.geogr.uni-jena.de/~p6taug/demviewer/demv.html, 03.05.2002 disy – Produkte – disy GISTerm, http://www.disy.net/de/Produkte/disy_GISterm/index.html, 10.05.2002 ESRI Shapefile Technical Description, http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf, 25.08.2002 GIS in Internet und Intranet – Technologie, Einsatzmöglichkeiten und Perspektiven, http://gio.uni-muenster.de/beitraege/ausg97_2/stahl/stahl.htm, 17.06.2002 GISToolkit, http://gistoolkit.sourceforge.net, 03.05.2002 JaGo, http://katla.giub.uni-bonn.de/jago, 10.05.2002 MapObjects Java Standard Edition, http://www.esri.com/software/mojava/index.html, 10.05.2002 TechniData AG, http://www.technidata.de, 21.08.2002 THREADS - ESRI Discussion Forums, http://forums.esri.com/Thread.asp?c=9&f=1193&t=69344&mc=10, 27.08.2002 VisAD Home Page, http://www.ssec.wisc.edu/~billh/visad.html, 03.05.2002 What is GIS?, http://www.gis.com/whatisgis/index.html, 05.04.2002 WIGeoGIS, http://www.wigeogis.com, 21.08.2002 Seite 69 von 70 Diplomarbeit: Geografische Informationssysteme zur Visualisierung von Umweltmessdaten Eidesstattliche Erklärung Ich erkläre hiermit an Eides Statt, dass ich die vorliegende Diplomarbeit selbstständig und ohne unzulässige fremde Hilfe angefertigt habe. Die verwendeten Quellen und Hilfsmittel sind vollständig zitiert. Furtwangen, den 28.08.2002 ________________________ Ralf Bierig Ralf Bierig Hoher Baum 3 D-74747 Ravenstein Seite 70 von 70
