aufbau eines geoportals als komponentenbasiertes ... · implementierte system beschrieben und alle...

RHEINISCHE FRIEDRICH-WILHELMS-UNIVERSITÄT BONN INSTITUT FÜR INFORMATIK III Prof. Dr. Armin B. Cremers

Aufbau eines Geoportals als komponentenbasiertes Informationssystem für ein Projekt der

Entwicklungsforschung (GLOWA Volta)

Diplomarbeit

Joscha Laubach [email protected]

26. Juni 2008

Inhaltsverzeichnis

3

Inhaltsverzeichnis 1 Einleitung ............................................................................................................................... 5

1.1 Motivation ....................................................................................................................... 5

1.2 Ziele der Arbeit................................................................................................................ 6 1.2.1 Architektur............................................................................................................... 6 1.2.2 Exploration, Navigation und Analyse ..................................................................... 7 1.2.3 Kommunikation und Austausch .............................................................................. 7

1.3 Gliederung ....................................................................................................................... 8

2 Grundlagen und Anforderungsanalyse ............................................................................... 9

2.1 Problembeschreibung ...................................................................................................... 9 2.1.1 Architektur............................................................................................................... 9 2.1.2 Exploration, Navigation und Analyse ..................................................................... 9 2.1.3 Kommunikation und Austausch ............................................................................ 10

2.2 Verwendete Standards und Begriffe.............................................................................. 11

2.3 Verwendete Programme ................................................................................................ 13

2.4 Alternative Geoportalansätze ........................................................................................ 15 2.4.1 Geoportaltypen ...................................................................................................... 15 2.4.2 Bewertungskriterien............................................................................................... 16 2.4.3 Bewertung der Kriterien ........................................................................................ 19 2.4.4 Beispiele existierender Geoportale........................................................................ 20

3 Entwicklung des Geoportals ............................................................................................... 31

3.1 Herangehensweise ......................................................................................................... 31

3.2 Architektur des Geoportals............................................................................................ 32 3.2.1 Ursprünglicher Zustand ......................................................................................... 32 3.2.2 Schwächen der ursprünglichen Architektur .......................................................... 33 3.2.3 Anforderungen....................................................................................................... 33 3.2.4 Neue komponentenbasierte Architektur ................................................................ 34

3.3 Praktische Umsetzung des Entwurfs ............................................................................. 37 3.3.1 Sicherheit ............................................................................................................... 38 3.3.2 Portalsoftware und Datamanager........................................................................... 40 3.3.3 Verwaltung der Metadaten .................................................................................... 45 3.3.4 Suchfunktionen...................................................................................................... 54 3.3.5 Visualisierung........................................................................................................ 60 3.3.6 Analyse .................................................................................................................. 77 3.3.7 Exportfunktionen................................................................................................... 78 3.3.8 Integration der ESRI Geodatenbanken.................................................................. 82 3.3.9 Benutzerkommunikation ....................................................................................... 84

3.4 Zusammenfassung ......................................................................................................... 88

Inhaltsverzeichnis

4

4 Zusammenfassung und Ausblick........................................................................................92

4.1 Erzielte Ergebnisse......................................................................................................... 92

4.2 Bewertung der Ergebnisse ............................................................................................. 93 4.2.1 Architektur ............................................................................................................. 93 4.2.2 Exploration, Navigation und Analyse.................................................................... 96 4.2.3 Kommunikation und Austausch............................................................................. 99

4.3 Ausblick ....................................................................................................................... 102

5 Literatur..............................................................................................................................108

6 Anhänge ..............................................................................................................................114 6.1 Verwendete Software im Geoportal............................................................................. 114

6.2 Programmaufbau des Geoportals ................................................................................. 114

6.3 Aufbau aller verwendeter Datenbanken....................................................................... 117

6.4 Vollständiges Datenbankschema des Portals............................................................... 118

6.5 Änderungen an der Mapbender-Datenbank ................................................................. 121

6.6 Änderungen am Quellcode von Mapbender ................................................................ 123

6.7 Vollständiges Schema der Metadatenbank .................................................................. 124

6.8 Beispiel einer XML-Datei für Metadaten .................................................................... 128

6.9 Schema für die Metadaten in XML.............................................................................. 128

6.10 URLs im Geoportal und ihre Bedeutung ..................................................................... 133

6.11 Umfrage unter Mitarbeitern des ZEF zum Geoportal.................................................. 134

6.12 Workflows.................................................................................................................... 141

7 Danksagungen ....................................................................................................................143

8 Eidesstattliche Erklärung..................................................................................................145

1.1 Motivation

5

1 Einleitung

1.1 Motivation Die Verwaltung von georeferenzierten Daten (Geodaten, [Wiki07b]) ist ein wichtiges Thema. In Projekten mit geografischem Bezug werden bestehende Geodaten verwendet und neue erzeugt. Diese Daten sind wertvoll, denn sie bilden die Grundlage für weitere wissenschaftliche Arbeit. Mehrere Personen und Institutionen haben ein Interesse an diesen Daten, um sie für eigene wissenschaftliche Arbeiten weiter zu verwenden. Die Daten liegen jedoch stark zerstreut bei den zuständigen Mitarbeitern vor.

Die schiere Menge und die zerstreute Speicherung der Daten machen das Auffinden bestimmter, benötigter Daten in der Gesamtheit aller Daten aber sehr schwierig, wenn diese nicht in einer strukturierten Art und Weise abgelegt sind.

Eine mögliche Lösung dieser Probleme stellt die Entwicklung von Geoportalen dar. Unter einem Geoportal versteht man stark vereinfacht einen Vermittler zwischen den Geodaten oder -diensten und dem Benutzer [SADM04]. Das Portal dient hauptsächlich dem geordneten Auffinden von Geodaten, die zuvor dem Portal bekannt gemacht wurden. Diese Daten werden dann auf geeignete Art und Weise im Browser angezeigt. Für den Benutzer ist es nicht wichtig, wo sich die eigentlichen Geodaten befinden, darum kümmert sich das Geoportal. Eine ausführlichere Definition des Begriffs Geoportal findet man in [Schu03] und in Kapitel 2.2.

Ein Geoportal bietet einen einfachen Zugriff auf Daten über das Internet unter Verwendung von Standard-Webbrowsern. Es handelt sich hierbei also um ein sogenanntes Web-GIS [Schm01, UnSc05, Mao05]. Ein Web-GIS ist ein im Funktionsumfang stark reduziertes Geoinformationssystem (GIS), welches aber einen Zugriff über das Internet bietet. Dafür wird es in der Regel um Funktionen wie das Bearbeiten der Geodaten beschnitten, die über das Internet nicht Jedermann zugänglich seien sollen [Schm01].

Beispiele für bereits bestehende Geoportale sind das Sedag Web-GIS der Universität Bonn [Seda07] und der Hamburger MetaDatenKatalog (HMDK, [Hmdk07]). In Kapitel 2.4 werden weitere Geoportale vorgestellt und bewertet. Einen Vergleich verschiedener Geoportale findet man zudem unter [Cros05].

Für das GLOWA Volta Projekt [Glow07] wurden vom Zentrum für Entwicklungsforschung (ZEF, [Zef08]) und anderen wissenschaftlichen Einrichtungen georeferenzierte und auch viele nicht georeferenzierte Daten gesammelt, die sich mit dem Umgang von Wasserressourcen im Volta-Becken in Ghana und Burkina Faso befassen. Diese Daten werden von den Mitarbeitern und Studenten des ZEF und anderen Einrichtungen erstellt und liegen derzeit sehr unsortiert auf verschiedenen Medien an verschiedenen Orten vor. In diesem Zustand ist es sehr schwer, die benötigten Daten zu finden, und es ist nicht möglich, effizient darauf zuzugreifen. Das veranschaulicht das folgende Beispiel aus der Praxis des GLOWA Volta Projekts.

Die Kommunikation mit interessierten Personen wird mit Hilfe von E-Mails abgewickelt. Auf diesem Weg braucht man oft mehrere E-Mail-Runden, um an die richtigen Daten zu kommen. Ein typisches Szenario sieht so aus: Bislang müssen die Interessenten eine E-Mail mit einer Anfrage nach bestimmten Daten an einen zuständigen Mitarbeiter einer der Institute schicken. Die Angaben in einer solchen E-Mail sind oft unvollständig, so dass der Mitarbeiter in einer

1 Einleitung

6

weiteren E-Mail weitere Angaben erfragen muss. Nun kann er manuell in dem lokalen Datenbestand nachsehen, ob die gewünschten Daten verfügbar sind. Ist dies der Fall, kann er sie in einer E-Mail zurückschicken. Wenn nicht, dann muss der Interessent die Daten nach einiger Zeit erneut anfragen. Bei besonders großen Datenmengen muss eventuell eine CD-ROM verschickt werden, was bei externen Interessenten mit Aufwand, Kosten und weiterer Wartezeit verbunden ist.

Alternativ können die Mitarbeiter die verfügbaren und aufbereiteten Daten auch auf einen zentralen Datenserver am ZEF hochladen. Alle Benutzer mit Zugriff auf diesen Server können sich die Daten dann von dort herunterladen. Damit der Benutzer die Daten überhaupt findet, liegen zumindest einige der Daten in einer festgelegten Verzeichnisstruktur vor. Dieser Ansatz ist natürlich sehr unflexibel und ebenfalls nicht sehr benutzerfreundlich.

Durch die Entwicklung eines Geoportals ist es möglich, diese Umwege deutlich zu verkürzen und somit an Effizienz zu gewinnen. Ein Geoportal kann den Benutzern alle verfügbaren Daten über das Internet zur Verfügung stellen und die oben genannten, für beide Seiten unvorteilhaften, Kommunikationsszenarien vermeiden [Teeg01a].

Kommerziell zu erwerbende Geoportal-Software kann derzeit nicht alle an sie gestellten Anforderungen erfüllen. So ist man beim Funktionsumfang und bei Erweiterungsmöglichkeiten vom Hersteller abhängig. Anpassungen an eigene Bedürfnisse sind nicht möglich oder teuer. Die Flexibilität der Einsatzmöglichkeiten ist also eingeschränkt. Außerdem fallen für die Nutzung der Software hohe Lizenzgebühren an. Eine eigene Entwicklung kann diese Probleme umgehen.

1.2 Ziele der Arbeit Ziel dieser Arbeit ist die Entwicklung eines Geoportals für das GLOWA Volta Projekt, das an die Bedürfnisse des Projekts angepasst ist. Das Geoportal soll den Wissenschaftlern im Projekt das Auffinden der Projektdaten erleichtern. Außerdem soll man darüber Projektergebnisse der Öffentlichkeit zugänglich machen können. Zusammenfassend sollte es die folgenden Funktionen erfüllen, die im Anschluss genauer dargestellt werden.

• Komponentenbasierte Architektur, die die Verwendung eigener und externer Programme und Erweiterungseigenschaften ermöglicht; Sicherheit der Daten in Bezug auf externe Angriffe und Zugriffsrechte; geringe Lizenzkosten;

• Exploration, Navigation und grundlegende Onlineanalyse der Geodaten, um gewünschte Informationen leicht zu finden und erfassen zu können;

• Distribution und Austausch der Daten; Kommunikation der Projektpartner und Planung von Projektereignissen; Umgang mit unzuverlässigen und langsamen Internetanbindungen.

1.2.1 Architektur Kommerzielle Geoportal-Software kann keine flexible, komponentenbasierte Architektur bieten, in der man selbst entwickelte und externe Software integrieren könnte. Ein offener, komponentenbasierter Ansatz kann zudem Erweiterbarkeit bieten, wo hingegen man bei monolithischer Software von den Entwicklern des Herstellers abhängig wäre.

Alle Bestandteile der für das GLOWA Volta Projekt entwickelten Architektur sollen zusammen Funktionen zur Datenhaltung, zum Datentransfer, zur Datenaufbereitung, zur Visualisierung von Geodaten und die Portalsteuerung ermöglichen. Bei den Anwendern kann aufgrund gewünschter

1.2 Ziele der Arbeit

7

Interoperabilität für den Zugriff auf die Daten nur ein Standard-Webbrowser vorausgesetzt werden [Teeg01b].

Da die Geodaten sehr wertvoll sein können, ist gerade wegen der zentralen Verfügbarkeit über das Internet besonders auf Sicherheitsaspekte [Bsi07] zu achten, die Entscheidungen über die zu verwendende Architektur stark beeinflussen können. Die Daten sollen möglichst gut vor externen Angriffen geschützt werden. Zudem muss es möglich sein, Zugriffsrechte auf die Daten zu setzen.

Fertige kommerzielle Software mit Geoportal-Funktionen ist außerdem nur durch den Kauf teurer Lizenzen zu haben [Asam03]. Wenn man den Kauf einer fertigen Lösung oder eine Sonderentwicklung durch eine spezialisierte Firma aber meidet, muss man mit Einschränkungen der Funktionalität und mit mangelnder Integration von Software rechnen. Das entwickelte Geoportal soll dennoch ohne teure Lizenzkosten auskommen.

1.2.2 Exploration, Navigation und Analyse Ein Geoportal soll es dem Benutzer ermöglichen, selbständig nach den von ihm benötigten Daten zu suchen, ohne dass er jemanden kontaktieren muss. Man soll Anfragen nach Daten selbst stellen können und selbst merken, ob in der Anfrage noch Informationen fehlen. Die Benutzerschnittstelle des Portals steht über das Internet zur Verfügung und kann die benötigten Auswahl- und Suchfunktionen anbieten, die zum Auffinden eines gewünschten Datensatzes benötigt werden. Hier soll das Auffinden der Daten durch thematische Listen und über Attribute möglich sein.

Außerdem soll man den ausgewählten Datensatz direkt online betrachten können [Teeg01b], um festzustellen, ob er den gewünschten Ansprüchen genügt. Visuelle räumliche Anfragen sollen direkt in den Karten möglich sein, um die gewünschten Informationen auch gleich visuell erfassen zu können.

Um ohne weitere Software bereits mit den Daten arbeiten zu können, kann eine Portal-Oberfläche auch grundlegende Analysefunktionen [AnAn01] für die Daten bieten. Eine vollständige Integration geeigneter Funktionen in die Portalarchitektur wird von verwendbarer Software noch nicht fertig angeboten, sondern muss speziell entwickelt werden.

1.2.3 Kommunikation und Austausch Die Internetanbindungen im Zielgebiet des Projekts in Afrika können langsam und unzuverlässig sein. Der Kommunikationsaufwand mit dem Portal soll also möglichst gering sein, so dass nur eine geringe Netzwerklast beim Zugriff auf die Daten entsteht. Das Portal soll zudem auch mit instabilen Verbindungen umgehen können.

Ein Projekt kann weltweit auf verschiedene Institutionen und Länder verteilt sein, trotzdem ist eine Kommunikation zwischen den Beteiligten notwendig. Ein Geoportal kann deshalb dazu genutzt werden, die Koordination und Planung von Projektereignissen (z.B. Termine) von gleich gesinnten und an unterschiedlichen Orten arbeitenden Projektteilnehmern zu ermöglichen.

Nicht nur Erfahrungen, sondern auch Daten müssen in einem Projekt ausgetauscht werden. Der Benutzer möchte die Daten auf seinem Rechner weiterverarbeiten, da sie die Grundlage für seine (wissenschaftliche) Arbeit sind. Das Portal bietet dafür nicht genügend Funktionalität, so dass der Einsatz von lokal installieren Programmen notwendig wird. In wissenschaftlichen Projekten können die Daten zudem die Arbeit nach außen hin repräsentieren und sollen deshalb allgemein

1 Einleitung

8

zugänglich gemacht werden. Hierfür soll das Portal die Koordination der Distribution der Daten übernehmen. Eine Downloadfunktion wird jedoch in bestehenden Geoportalen oft gar nicht (z.B. [Gbun08]) oder nur mit wenigen ausgewählten Daten (z.B. [Ghes07]) angeboten und ist stark von der verwendeten Architektur abhängig. Diese Funktion soll im GLOWA Volta Geoportal jedoch integriert sein.

1.3 Gliederung Im ersten Kapitel „Einleitung“ wurde das Thema der Diplomarbeit motiviert und die Ziele wurden beschrieben. Im folgenden zweiten Kapitel „Grundlagen und Anforderungsanalyse“ werden die Probleme genauer betrachtet, die bei der Entwicklung eines Geoportals auftreten können und die für dieses konkrete Projekt relevant sind. Außerdem werden verwendete Standards, Begriffe und Programme kurz erläutert. Im Anschluss werden bereits bestehende Geoportale vorgestellt und anhand von ebenfalls vorgestellten Kriterien bewertet. Im dritten Kapitel „Entwicklung des Geoportals“ werden die endgültige Architektur des Geoportals und das implementierte System beschrieben und alle wichtigen Schritte und Gründe zur Entstehung erläutert. Dieses Kapitel stellt den Hauptteil dieser Diplomarbeit dar. Im letzten Kapitel „Zusammenfassung und Ausblick“ werden die wichtigsten Punkte der Diplomarbeit noch einmal zusammengefasst und die erzielten Ergebnisse dargelegt und bewertet. Außerdem werden mögliche zukünftige Erweiterungen und Entwicklungen des Geoportals vorgeschlagen. Es folgen noch die Literaturliste und die Anhänge.

2.1 Problembeschreibung

9

2 Grundlagen und Anforderungsanalyse

2.1 Problembeschreibung

2.1.1 Architektur Man kann Software mit Geoportal-Funktionen fertig kaufen oder eine Firma mit der Entwicklung beauftragen, was aber in den meisten Fällen teuer und unflexibel ist. Es gibt aber viele verschiedene kostenlose Programme, die jeweils eine bestimmte Aufgabe eines Geoportals erfüllen. Solche externen Programme werden hier Fremdprogramme genannt und sind in der Regel Open Source Software. Die Fremdprogramme werden durch selbst entwickelte Komponenten ergänzt beziehungsweise von diesen als Bestandteile verwendet. In diesem Projekt wird also eine komponentenbasierte Architektur zum Aufbau eines Geoportals verwendet, die folgende Funktionen bietet: Datenhaltung, Datentransfer, Datenaufbereitung, Visualisierung, Sicherheit und Steuerung. Gerade die Fremdprogramme wurden aber oft nicht dafür entwickelt, um problemlos zusammen zu arbeiten. Um ein nahtloses Geoportal zu erreichen, ist dies aber notwendig. In unserer Architektur ergeben sich deshalb verschiedene Probleme, weil die Fremdprogramme oft keine standardisierten Schnittstellen für den Datenaustausch oder die Steuerung anbieten und sie schlecht dokumentiert sind.

Die Daten sind oft teuer und wertvoll, so dass ihre Sicherheit gewährleistet werden muss, wenn das Portal von den Datenproduzenten akzeptiert werden soll. In Bezug auf die Sicherheit gibt es zwei verschiedene Aspekte. Zunächst sollen einige Daten nur einem eingeschränkten Kreis von Personen zugänglich gemacht werden, also muss man den Zugriff auf die Daten beschränken können, wie beispielsweise in [Mitt04] dargelegt. Für eine Zugriffbeschränkung der Daten ist eine Benutzerverwaltung notwendig, um bestimmte Benutzer oder Benutzergruppen eindeutig identifizieren zu können. Nur dann kann man den Zugriff auf eine Person/Gruppe beschränken. Der andere Aspekt ist die Absicherung der Daten gegen Angriffe von außen. Jedes Geoportal ist auch ein Webserver, der somit aus dem Internet kompromittiert werden kann [Wiki07c] und dessen Daten dabei entwendet werden können. Um solche Angriffe zu erschweren, soll in diesem Projekt ein separater Datenserver eingesetzt werden, der nicht direkt aus dem Internet zu erreichen ist. Dessen Daten muss man aber ebenfalls zugreifen können, um sie dem Benutzer zugänglich zu machen. Die räumliche Trennung zwischen dem Speicherort der Daten und dem Ort der Nutzung (Webserver) muss überwunden werden.

2.1.2 Exploration, Navigation und Analyse Um die bereitgestellten Geodaten zu finden, benötigt man Such- und Auswahlmöglichkeiten für diese Daten. Es ist bei großen Datenmengen offensichtlich nicht zumutbar, alle Daten manuell, sequenziell durchzusehen, um den benötigten Datensatz zu finden. Besser ist es, wenn man die Daten nach thematisch sortierten Listen auswählen kann oder eine Suche nach Stichwörtern ermöglicht, um bestimmte Daten anhand beschreibender Informationen zu finden. Alle diese Möglichkeiten können in die Portaloberfläche integriert werden und stehen dort dem Benutzer zur Verfügung.

Ein Ansatz ist die Verwendung von Metadatenbanken [Puch01], die beschreibende Informationen über die an beliebiger Stelle abgelegten Daten enthalten. Im Gegensatz zu


10

spezialisierten Geodatenbanken müssen das nicht nur Geodaten sein, sondern man kann beliebige Daten verwenden. Zwar ist man mit der Verwendung einer Metadatenbank flexibel in Bezug auf den Speicherort der Daten, allerdings muss man auf ihre Konsistenz in Bezug auf die eigentlichen Daten achten. Man benötigt außerdem ein separates Verwaltungswerkzeug für die Datenbank. Eine Suche innerhalb der eigentlichen Daten ist zudem nicht möglich, da nur die Metadatenbank durchsucht wird.

Neben den genannten Möglichkeiten einen bestimmten Datensatz zu finden, kann man sich auch die Georeferenzierung [Wiki07a] der Daten zu Nutze machen und Informationen visuell innerhalb der Daten in einem bestimmten Gebiet erfassen, wenn man die geeignete Karte bereits gefunden hat.

Die Geodaten sollen direkt im Browser betrachtet werden können. Hieraus ergeben sich verschiedene Probleme. So können die Daten in verschiedenen Dateiformaten vorliegen, die von keinem Browser direkt interpretiert werden können. Die Visualisierung soll bei einem Geoportal aber funktionieren, also muss eine Aufbereitung der Daten erfolgen, um sie internetkompatibel zu machen [Teeg01a]. Die aufbereiteten Daten werden über eine Schnittstelle an die Benutzeroberfläche weitergereicht [Teeg01b], die verschiedene Funktionen zum Betrachten der gewünschten Karte zur Verfügung stellt. Bei der Schnittstelle ist ein allgemein akzeptierter Standard wünschenswert, um eine gute Interoperabilität auch mit externen Programmen zu erreichen. In [WSS00] wird beispielsweise eine Lösung vorgestellt, die nicht verbreitet und somit nicht mit anderen Programmen kompatibel ist. Dies gilt auch für die proprietären Schnittstellen kommerzieller Hersteller [Teeg01b]. Für die Visualisierung könnte beispielsweise sogar die Anzeige von 3D-Daten notwendig sein [BBB+99], dies ist im GLOWA Volta Projekt derzeit jedoch nicht von Bedeutung.

Zusätzlich zur reinen Visualisierung können auch grundlegende Funktionen zur Analyse sinnvoll sein, die dem Benutzer direkt online zur Verfügung stehen und bereits eine Auswertung der gefundenen Daten ermöglichen. Denkbar sind hier verschiedene Funktionen, wie zum Beispiel das Hervorheben von Objekten mit bestimmten Eigenschaften oder die Anzeige weiterer Informationen zu einem Objekt in der Karte. Für das Hervorheben von Objekten gibt es einen Standard (SLD, [Ogc07b]), der aber oft nur experimentell oder gar nicht implementiert ist.

2.1.3 Kommunikation und Austausch Da noch nicht überall Breitbandanbindungen an das Internet üblich sind, sind auch die Datenmengen zu berücksichtigen, die übertragen werden. Bei der Visualisierung werden die Daten vorher bereits verlustbehaftet reduziert [Teeg01a], eine weitere Reduktion wäre nicht sinnvoll. Denkbar wäre allerdings die in [STCK02] vorgestellte Möglichkeit, die Daten zunächst nur grob darzustellen und dann durch das Nachladen von Daten weiter zu verfeinern, was allerdings umfangreiche Änderungen an bestehenden Fremdprogrammen nach sich ziehen würde. Beim Download soll der Benutzer mit den vollständigen Daten weiterarbeiten können, so dass man hier keine verlustbehaftete Reduktion vornehmen kann. Trotzdem gibt es auch hier Ansätze nur Verringerung der Datenmenge. So kann man die Daten verlustfrei komprimieren oder man kann nicht benötigte Teile der Daten weglassen und so eine Reduktion der Datenmenge erreichen. Hier ist man aber auf Mithilfe des Benutzers angewiesen, da nur dieser die benötigten Teile festlegen kann.

Bei einem wissenschaftlichen Projekt müssen immer wieder Ereignisse geplant bzw. koordiniert werden. So müssen sich beispielsweise alle zuständigen Mitarbeiter auf eine gemeinsame Zeit für

2.2 Verwendete Standards und Begriffe

11

ein Treffen einigen oder ähnliches. In der Regel ist hier der Austausch vieler E-Mails durch alle Mitarbeiter notwendig. Ein Geoportal kann Funktionen anbieten, um solche Probleme einfacher zu lösen.

Die Daten stellen Ergebnisse eines Projekts dar, die auch nach außen hin kommuniziert werden sollen. Außerdem sind die Mitarbeiter eines Projekts oft weltweit verteilt und wollen trotzdem auf die Daten anderer Mitarbeiter zugreifen können. Lokal installierte GIS-Programme bieten weitergehende Funktionen zur Verarbeitung und Analyse der Geodaten als ein Geoportal, so dass man es dem Benutzer ermöglichen sollte, die Daten auf den lokalen Rechner herunter zu laden.

Ein Geoportal muss den Austausch der Daten durch Bereitstellen fertiger Daten durch den Datenproduzenten und eine Downloadmöglichkeit der Daten durch den Nachfragenden ermöglichen. Eine weitere Möglichkeit ist die Unterstützung gezielter Anfragen eines Nachfragenden nach bestimmten Daten, die dann von den Verantwortlichen nach entsprechender Aufbereitung zur Verfügung gestellt werden können.

2.2 Verwendete Standards und Begriffe

Geoportal Es gibt verschiedene Definitionen für den Begriff Geoportal, die sich je nach gewünschtem Schwerpunkt unterscheiden. Gemein haben alle diese Definitionen, dass es sich bei einem Geoportal um eine Internet-Webseite handelt, die dem Benutzer Zugriff auf georeferenzierte Daten (Geodaten, siehe Abschnitt „Geodaten und Karten“) bietet.

Für diese Diplomarbeit ist ein Geoportal als Webseite definiert, die dem Benutzer georeferenzierte und nicht georeferenzierte Daten zugänglich macht. Ein Geoportal bietet Suchmöglichkeiten für diese Daten und kann die Daten selbst anzeigen, zum Download anbieten oder eine Verknüpfung mit einem externen Angebot liefern. Außerdem sind Funktionen zum Austausch von Daten und Informationen zwischen den Benutzern denkbar. Dem Benutzer können zudem Informationen zu geeigneten Themengebieten zugänglich gemacht werden.

Eine Geodateninfrastruktur (GDI, [Gisw08, Food05]) bezeichnet eine Einrichtung zur Speicherung, Bereitstellung und zum Austausch verschiedener Geodaten. Die Daten können in spezialisierten Datenbanken oder standardisierten Dateiformaten gespeichert werden. Ebenfalls zu einer GDI gehören Metadaten, die die Geodaten beschreiben. Benutzer können über Schnittstellen auf die GDI zugreifen; eine solche Schnittstelle kann beispielsweise ein Geoportal sein, welches den Zugang zu einer GDI ermöglicht [GLCZ08].

Geodaten und Karten Geodaten sind digital vorliegende Daten über Räume und deren Nutzung, die georeferenziert wurden. Die Daten wurden also einem bestimmten Ort auf der Erde zugeordnet, was unter der Verwendung von Koordinaten eines oder verschiedener Koordinatensysteme geschieht. Weiterführende Informationen zu Geodaten und Koordinatensystemen findet man unter [Gisw06] und [Gisw07].

Neben der gegebenen Definition gibt es auch Quellen, die auch analoge Daten als Geodaten bezeichnen. Da solche Daten aber für diese Diplomarbeit keine Rolle spielen, ist hier die gegebene Definition ausreichend.


12

Der Begriff Karte wird in dieser Diplomarbeit vereinfachend für zweidimensional grafisch darstellbare Geodaten verwendet. Eine Karte kann aus verschiedenen, übereinander liegenden Ebenen, den sogenannten Layern, bestehen. Ein Beispiel für Geodaten, die keine Karten sind, kann man beispielsweise (georeferenzierte) Textdokumente nennen, die das Geoportal ebenfalls verwalten kann. Karten können im Internet nicht nur in Form von statischen Grafiken angezeigt werden, sondern auch als sogenannter Geodienst, der eine interaktive Nutzung ermöglicht.

Komponente Eine Komponente ist ein Bestandteil eines Programms. Das Hauptprogramm kann durch eine oder mehrere Komponenten erweitert werden. Da Komponenten durch einheitliche Schnittstellen mit dem Programm kommunizieren, lassen sie sich beliebig gegen kompatible andere Komponenten austauschen. Es kann jedoch verschiedene Schnittstellen für unterschiedliche Typen von Komponenten geben. Weitere Informationen zu Komponenten finden sich unter [Wiki08a].

Dublin Core Dublin Core [Dcmi08] ist ein Metadatenschema zur Beschreibung der Geodaten. Es ist sehr allgemein gehalten und bietet nur wenige vorgegebene Felder (Elemente), sondern stattdessen eine flexible Nutzung. Diese Einfachheit und Flexibilität war der Grund dafür, dass Dublin Core am ZEF den alten Standard FGDC [Fgdc07] abgelöst hat. FGDC war sehr umfangreich und enthielt sehr viele Pflichtfelder. Das Ausfüllen all dieser Felder hätte zu einem sehr großen Arbeitsaufwand für die Wissenschaftler geführt.

Dublin Core bietet 15 Kernelemente, die jedoch den Bedürfnissen der jeweiligen Anwendung angepasst werden können. Hierbei ist es möglich, einzelne Elemente zu präzisieren („refinements“) oder neue Elemente hinzuzufügen. Da alle Elemente optional sind, kann man nicht benötigte Kernelemente auch weg lassen.

Für das Geoportal wurden alle 15 Kernelemente verwendet, einige davon wurden jedoch präzisiert und es wurden neue Elemente hinzugefügt. Nähere Informationen hierzu findet man in Kapitel 3.3.3 und in der Schemabeschreibung in Anhang 6.7.

WMS Web Map Service (WMS, [Ogc07a]) ist ein Standard des Open Geospatial Consortiums (OGC) zum Abfragen von Karten über das Internet. Benötigte Informationen über die gewünschte Karte werden als standardisierte XML-Dateien übertragen, die Karten selbst in einem allgemein gebräuchlichen, nicht georeferenzierten Grafikformat wie beispielsweise JPEG, GIF oder PNG.

Bei jeder Änderung an der angezeigten Karte, zum Beispiel einer Veränderung des angezeigten Ausschnitts, wird von der Serverseite (Mapserver) eine komplett neue Grafikdatei erzeugt und übertragen. Diese ersetzt die angezeigte Grafik vollständig. Mit WMS kann man Karten als Geodienst verfügbar machen (vgl. Abschnitt „Geodaten und Karten“).

SLD Ein Styled Layer Descriptor (SLD, [Ogc07b]) ist ebenfalls ein XML-basierter Standard des OGC. Wie der Name bereits nahe legt, enthält ein SLD-Dokument alle Angaben, um das Aussehen eines bestimmten Layers verändern, ohne dass man die zugrunde liegenden Daten des Layers ändern müsste. Hierfür spezifiziert SLD Filter, die gewünschte Objekte eines Layers unter

2.3 Verwendete Programme

13

angegebenen Bedingungen verändern können. So kann man beispielsweise alle Länder ab einer bestimmten Einwohnerzahl anders einfärben als die restlichen.

SSH/SCP Secure Shell (SSH, [Wiki08f]) ist ein Protokoll, mit dem über das Netzwerk eine verschlüsselte und authentifizierte Verbindung zu einem entfernten Rechner aufgebaut werden kann, um diesen so zu nutzen. Das Secure Copy Protokoll (SCP) verwendet SSH, um einen Dateitransfer zwischen den beteiligten Rechnern zu ermöglichen.

2.3 Verwendete Programme

Java/JSP und Tomcat Das Geoportal und die selbst programmierten Komponenten wurden in Java und JavaServer Pages (JSP, [Sun08]) programmiert. JSP ist eine Erweiterung der Programmiersprache Java um Funktionen zum dynamischen Erzeugen von Webseiten. Außerdem kann auf den vollen Umfang von Java zurückgegriffen werden.

Damit ein Server JSP-Seiten anzeigen kann, benötigt er einen Webserver oder eine Webserver-Erweiterung („Plug-in“), die JSP kompilieren, ausführen und dann auch anzeigen kann. Das Open Source Programm Tomcat von Apache kann genau dies leisten [Apac07]. Es kann sowohl als eigenständiger Webserver, als auch als Plug-in für einen bestehenden Webserver, fungieren und wandelt JSP-Seiten in sogenannte Servlets um. Diese können dann – ebenfalls von Tomcat – ausgeführt und als Webseiten angezeigt werden. Auch verknüpfte Javaklassen können über Tomcat ausgeführt werden.

Die Grundfunktionalität von Java/JSP wurde für das Geoportal durch einige Bibliotheken erweitert, um zusätzliche Funktionen zu ermöglichen. Der Zugriff auf Datenbanken erfolgt über die Java Database Connectivity Schnittstelle (JDBC). Hierüber kann – bei verfügbarem Treiber für die vorhandene Datenbank – auf einem einheitlichen Weg aus Java, und somit auch aus JSP heraus, auf Datenbanken zugegriffen werden. Mit der Bibliothek JavaMail können aus Java heraus E-Mails versendet und empfangen werden. Mit Apache Commons FileUpload wird JSP in die Lage versetzt, über eine Webseite hochgeladene Dateien zu verarbeiten. Apache Commons Lang bietet Methoden an, um kritische Zeichen in Ausgaben auf JSP-Seiten durch Escape-Zeichen zu ersetzen. Hiermit kann verhindert werden, dass vom Benutzer versehentlich oder absichtlich HTML- oder Javascriptcode in die Ausgabe geschmuggelt werden kann, der dann vom Browser des Anwenders fälschlicherweise interpretiert wird (HTML/Script Injection).

Samba/SMB Server Message Block (SMB) ist ein Protokoll von Microsoft Windows für unter anderem den Dateizugriff über ein Netzwerk. Die Open Source Software Samba ermöglicht die Nutzung dieses Protokolls auch unter GNU/Linux [Samb08]. Somit können Windows-Clients auch auf das Dateisystem eines Linuxservers zugreifen, ohne Samba wäre der Zugriff nur auf einen Windows-Server möglich.

UMN MapServer Die Geodaten des Portals sollen dem Benutzer in einem Standard-Webbrowser angezeigt werden können, damit das Portal genutzt werden kann, ohne zusätzliche Software installieren zu müssen.


14

Ein Webbrowser unterstützt jedoch die Austauschformate für Geodaten nicht, die dem Portal zur Verfügung stehen. Um diese dennoch anzeigen zu können, wird ein sogenannter Mapserver verwendet, der die Daten in ein internetkompatibles Format umwandelt. Hier kommt das Open Source Programm UMN MapServer zum Einsatz [Umn07], das nicht nur kostenlos zur Verfügung steht, sondern auch dafür bekannt ist, schnell und stabil zu arbeiten. UMN MapServer unterstützt WMS (siehe Kapitel 2.2).

Mapbender Die vom Mapserver aufbereiteten Geodaten kann man zwar direkt im Webbrowser anzeigen, jedoch ist dann keinerlei benutzbare Interaktivität möglich. Um dem Benutzer eine ansprechende Bedienschnittstelle zu bieten, die beispielsweise Funktionen wie Zoomen, Panning oder Querying für die Karten zur Verfügung stellt, wird das Open Source Programm Mapbender verwendet [Mapb08]. Mapbender ist ebenfalls kostenlos verfügbar und bietet über die Schnittstelle WMS (siehe Kapitel 2.2) Zugriff auf die vom UMN MapServer bereitgestellten Daten.

ArcGIS mit AmeiN! Am ZEF wird zur Erstellung von Karten das Geoinformationsprogramm ArcGIS der Firma ESRI eingesetzt [Esri07a]. Auf dieses Programm kann nicht verzichtet werden, so dass für das Geoportal Anpassungen hieran notwendig sind.

Neben der Erstellung von Karten bietet das Programm auch Funktionen zur Verwaltung und Verifikation von Geodaten an. Zum Abspeichern dienen in der Regel verschiedene Arten von Geodatenbanken, die in die Oberfläche von ArcGIS integriert sind.

Um die gewünschten Geodaten zum Download anbieten zu können und mit MapServer/Mapbender anzeigen zu können, ist ein Export aus ArcGIS und dessen Geodatenbank notwendig. Die benötigten Daten müssen in ein dateibasiertes Austauschformat überführt werden, um vom UMN MapServer verarbeitet werden zu können. Außerdem werden einige Zusatzinformationen über den Kartenaufbau und die Lage der Dateien benötigt, die in sogenannten Mapfiles und weiteren Konfigurationsdateien abgelegt werden. Diese können mit der ArcGIS-Erweiterung AmeiN! halbautomatisch erzeugt werden [Terr08]. Dies ist auch notwendig, wenn die Daten bereits in einem kompatiblen Austauschformat vorliegen.

ESRI Geodatabases Die in ESRI ArcGIS verwalteten Daten können in verschiedenen Datenbanktypen abgespeichert werden [Esri07b]. In diesem Projekt soll als zentrale Datenbank für ArcGIS die, von ESRI für die Zukunft favorisierte, File Geodatabase eingesetzt werden. Diese speichert ihre Daten nicht relational oder als Access-Datenbank, sondern dateibasiert in einem Verzeichnis eines verfügbaren Dateisystems. Neben den File Geodatabases bietet ESRI noch die Personal Geodatabases, die ihre Informationen in Access-Datenbanken abspeichern. Diese werden im Projekt bereits eingesetzt.

Beide Datenbanktypen haben gemein, dass der Zugriff ausschließlich über ArcGIS Produkte möglich ist, da nur diese mit den proprietären Datenbankformaten umgehen können. Mit Hilfe von ArcGIS Engine Runtime 9.2 und der Programmierschnittstelle ArcObjects, kann man auch aus Java-Programmen heraus auf die Datenbanken zugreifen.

2.4 Alternative Geoportalansätze

15

2.4 Alternative Geoportalansätze Wie bereits in Kapitel 1.1 erwähnt, gibt es bereits viele Geoportale mit unterschiedlichem Funktionsumfang. In diesem Kapitel werden Geoportale in verschiedene Typen unterteilt. Die Unterscheidung wird aufgrund des Anwendungszwecks und des daraus resultierenden Funktionsumfangs vorgenommen. Eine solche Unterteilung ist sinnvoll, um verschiedene Geoportale grob gegeneinander abzugrenzen.

Neben einer Einteilung von Geoportalen in verschiedene Kategorien werden noch allgemeine Kriterien zur Bewertung von Geoportalen benötigt. Nur so ist ein Vergleich verschiedener Geoportale möglich. Diese Kriterien werden ebenfalls in diesem Kapitel aufgestellt. Je nach Anwendungszweck des Geoportals sind jedoch nicht alle Kriterien wichtig. Nun können ausgewählte verschiedene Geoportale anhand von wissenschaftlicher Literatur und eigener Erfahrung verglichen und bewertet werden.

2.4.1 Geoportaltypen Den meisten Geoportalen ist gemein, dass sie die Suche nach Geodaten ermöglichen und dass sie beschreibende Metadaten über ihr Angebot zugänglich machen [NKNM05]. Jedoch ist es möglich, verschiedene Typen von Geoportalen zu definieren. Dies wurde in [TaSe05] und [FTS05] bereits gemacht, deren Definitionen auch hier verwendet werden sollen. Es wird unterschieden nach Katalogportalen, Anwendungsportalen und Enterpriseportalen. Im Folgenden werden diese drei Typen genauer beschrieben.

Katalogportale Ein Katalogportal (catalog portal) ist ein Geoportal, welches hauptsächlich den Zugriff auf einen sogenannten Metadatenkatalog bietet. Ein solcher Metadatenkatalog kann vom Benutzer des Portals durchsucht werden, um gewünschte Geodaten oder andere Geodienste aufzufinden. Gesucht werden kann normalerweise nur in den Metadaten, die zu den eigentlichen Geodaten gehören, oder in Teilen davon. Der Katalog enthält dann Verweise auf die eigentlichen Daten. Diese Daten können sowohl vom Portal selbst angeboten werden als auch von anderen Anbietern im Internet [Esri03b].

Wenn das Portal nicht nur eigene Daten anbietet, dann muss es externen Anbietern die Möglichkeit geben, eigene Metadaten bekannt zu machen („Registrierung“). Diese Informationen stehen den Benutzern des Katalogportals danach zur Verfügung. Sie verweisen jedoch in der Regel auf das unabhängige, externe Angebot des Anbieters. Dies hat den Vorteil, dass verteilte Angebote den Benutzern über eine zentrale Webseite zugänglich gemacht werden können („one-stop“), ohne auch die Datenhaltung zentralisieren zu müssen.

Wenn sich der Katalog aus verschiedenen Angeboten zusammensetzt, dann muss darauf geachtet werden, dass der Benutzer darauf trotzdem auf eine einheitliche Art und Weise zugreifen kann und dass die Informationen darin möglichst aktuell sind.

Wie in [FTS05] erwähnt, werden Katalogportale immer häufiger auch mit Funktionen zur Visualisierung und Verarbeitung von Geodaten ausgestattet. Dies ist normalerweise eine Eigenschaft von Anwendungsportalen, die nun im Folgenden beschrieben werden. Auch Katalogportale bieten jedoch oft Visualisierungsmöglichkeiten an.


16

Anwendungsportale Ein Anwendungsportal (application portal) ist im Gegensatz zu einem Katalogportal ein spezialisiertes Geoportal. Aus dem Namen ist bereits ersichtlich, dass es dem Benutzer eine bestimmte Anwendung zur Verfügung stellt, die auf Geodaten basiert.

Diese Anwendung kann dem Benutzer spezialisierte Zugriffsmöglichkeiten auf die Geodaten ermöglichen. Außerdem können umfangreichere Möglichkeiten angeboten werden, um die Geodaten zu betrachten oder zu verarbeiten [TaSe05]. Ein Anwendungsportal dient also nicht nur dem reinen Auffinden von Daten, der Benutzer kann so einen zusätzlichen Nutzen aus den Daten ziehen. Ein klassisches Beispiel für ein Anwendungsportal ist ein Routenplaner, bei dem der Benutzer eine spezialisierte Suche nach Adressen zur Verfügung stehen hat. Die Geodaten dienen hierbei der Visualisierung der berechneten Route für den Benutzer.

Aufgrund der Spezialisierung auf eine bestimmte Anwendung bieten diese Portale die benötigten Geodaten (und Dienste) in der Regel selbst an, ohne auf externe Anbieter zurück zu greifen. Jedoch können Anwendungsportale auch allgemeine Suchfunktionen für ihre Daten anbieten, wie sie in Katalogportalen üblich sind.

Enterpriseportale Enterpriseportale (enterprise portals) sind spezialisierte Portale von Firmen. Sie stellen Mitarbeitern benötigte Informationen meistens über das Intranet der Firma zur Verfügung [Wiki07e]. Ein Zugriff über das Internet kann jedoch ebenfalls möglich sein.

Diese Portale können durch Geodaten und –dienste erweitert werden, die den Benutzern dann ebenso zur Ansicht und Verarbeitung zur Verfügung stehen, wie andere Informationen aus dem Portal. Es steht so ein zentraler Anlaufpunkt zur Informationsbeschaffung zur Verfügung, der von den Firmen auch zur Kommunikation der Mitarbeiter untereinander genutzt werden kann.

In [Esri06a] werden exemplarisch BHP Billiton und Shell Oil als Firmen genannt, die solche Portale betreiben.

2.4.2 Bewertungskriterien Um Geoportale untereinander vergleichen zu können, sind feste Kriterien wünschenswert, anhand derer man die Portale bewerten kann. Diese Kriterien können sich auf den Funktionsumfang eines Portals beziehen oder auf die Qualität der angebotenen Funktionen. Allerdings ist zu beachten, dass Geoportale auch absichtlich einen geringen Funktionsumfang aufweisen können, weil sie an die Bedürfnisse der Benutzer angepasst wurden. Im Folgenden werden verschiedene Kriterien vorgestellt, die zum Vergleichen und Bewerten von Geoportalen geeignet sind. Außerdem bieten sie einen Überblick über den möglichen Funktionsumfang bereits existierender Geoportale.

Einfache Gliederung und Themeneinordnung Um möglichst vielen Personen den Zugang zu einem Geoportal zu ermöglichen, ist es wichtig, eine einfache Benutzbarkeit anzubieten [TaSe05]. Der Metadatenkatalog ist der zentrale Bestandteil eines Geoportals, der Zugriff sollte auch für unerfahrene Benutzer einfach und schnell zu finden sein [LSS+06]. Grundsätzlich gilt, dass die Informationen, die das Portal anbietet, vom Benutzer leicht gefunden und genutzt werden können sollen.


17

Es kann sinnvoll sein, wichtige Daten und Informationen in Themenlisten einzusortieren. Diese Listen werden Kanäle („channels“) genannt und helfen dem Benutzer, schnell einen Einstieg in ein bereits vorbereitetes Thema zu finden [TaSe05].

Mehrsprachigkeit Bei internationaler Nutzung eines Geoportals oder bei Portalen für mehrsprachige Länder kann die Benutzerschnittstelle mehrsprachig ausgelegt werden [Esri06a, Food05]. Alternativ ist eine weit verbreitete Sprache – wie beispielsweise Englisch – zu wählen. So schließt man keine Benutzer aufgrund der Sprachbarriere aus. Wenn mehrere Sprachen genutzt werden, dann ist es nicht selbstverständlich, dass auch Metadaten und die Suchfunktionen übersetzt vorliegen [LSS+06].

Suchfunktionen Damit der Benutzer aus dem Angebot des Geoportals das für sich passende finden kann, sind geeignete Suchfunktionen notwendig. Durchsucht werden in der Regel die Metadaten des Portals. Die Suche kann entweder auf den Daten durchgeführt werden, die das Portal selbst anbietet, oder auf verteilt vorliegenden Daten externer Anbieter [Food05].

Es sind umfangreiche Möglichkeiten denkbar, durch die der Benutzer gewünschte Suchanfragen absetzen kann. Man kann zwischen drei verschiedenen Sucharten unterscheiden. Zunächst gibt es die häufig angebotene Standardsuche, bei der Stichwörter in ein einzelnes Suchfeld eingegeben werden. Diese Suche ist einfach gehalten und verwirrt den Benutzer nicht mit zu vielen Eingabemöglichkeiten. Wenn komplexere Suchanfragen gestellt werden müssen, kann eine erweiterte Suche angeboten werden. Sie bietet mehrere Felder und Menüs zur Eingabe an. So kann nach beliebigen Stichwörtern genau so gesucht werden, wie in einzelnen Elementen des Metadatenkatalogs. Die Suche nach Zeiträumen kann in einem Geoportal ebenfalls sinnvoll sein und gehört zur erweiterten Suche. Da ein Geoportal georeferenzierte Daten verwaltet, ist auch eine Suche nach einem bestimmten Bereich auf der Erde („extent“) üblich. Man kann eine solche Suche als räumliche Suche oder Koordinatensuche bezeichnen. Auch die bereits eingeführten Kanäle stellen eine Suchfunktion dar, die ein Geoportal anbieten kann. [AdKr06, LSS+06, TaSe05, AdKr05]

Bei Anwendungsportalen kann eine Suche sinnvoll sein, die an die jeweilige Anwendung optimal angepasst ist [TaSe05]. Sie ist für den Benutzer besonders einfach zu bedienen, da sie einen direkten Bezug zur Anwendung hat und keine überflüssigen Funktionen enthält.

Qualität und Geschwindigkeit Die Akzeptanz eines Geoportals steht und fällt mit den angebotenen Daten. Deshalb sollten die Metadaten, in denen der Benutzer sucht, stets aktuell sein. Beispielsweise sind Verweise in Metadaten auf nicht mehr existierende Geodaten, die trotzdem als Suchergebnis präsentiert werden, für den Benutzer ärgerlich.

Wenn das Geoportal seine Suche auf verschiedene Anbieter verteilen muss, die das eigentliche Angebot bereithalten, kann es noch zu anderen Problemen kommen. Wenn jeder Anbieter bei jeder einzelnen Suchanfrage separat abgefragt wird, dauert die Suche sehr lange. Wie in [TaSe05] erläutert, sollte eine Suche jedoch nach maximal 2-5 Sekunden ein Ergebnis liefern. Als Abhilfe kann ein Geoportal einen Index zwischenspeichern und nur in diesem wird gesucht. Dann ist aber auf die Aktualität dieses Indexes zu achten. [LSS+06, TaSe05]


18

Metadaten sind häufig unvollständig, weil die zuständigen Personen die umfangreichen Elemente nicht alle ausfüllen. Wenn nun die Suche in allen Elementen möglich ist, kann dies dazu führen, dass existierende Daten nicht gefunden werden, obwohl sie verfügbar sind, wenn der Benutzer die Vollständigkeit der Metadaten voraussetzt. Hier kann eine reduzierte Elementsuche Abhilfe schaffen [TaSe05]. Aber nicht nur die Metadaten in einem Geoportal sind wichtig, schließlich suchen die Benutzer diese eigentlich nicht. So können Art und Umfang der angebotenen Geodaten für den Vergleich verschiedener Geoportal wichtig sein [Cros05].

Präsentation der Suchergebnisse Die Suchergebnisse sollten dem Benutzer übersichtlich präsentiert werden. In der Regel werden einige ausgewählte Metadatenelemente angezeigt, sowie Links zu den vollständigen Metadaten und anderen Betrachtungs- (z.B. Kartenvisualisierung) oder Downloadmöglichkeiten. Auch Vorschaubilder sind denkbar. Die Auswahl der gezeigten Metadatenelemente ist wichtig, weil sie dem Benutzer als Entscheidungsgrundlange dienen kann, ob die Suche erfolgreich war. [AdKr06, LSS+06]

Als veraltet gilt eine Anzeige von Ergebnissen, die nach den Anbietern der jeweiligen Daten sortiert ist. Dies bedeutet zusätzlichen Aufwand für den Benutzer bei der Auswertung der Ergebnisse. [AdKr06]

Stabilität und Erreichbarkeit Geoportale können von den Benutzern nur akzeptiert werden, wenn sie zuverlässig erreichbar sind, falls der Benutzer sie benötigt. Ein instabiles und nur gelegentlich erreichbares System ist ungeeignet [TaSe05].

Interoperabilität und Integration Ein Geoportal kann ein in sich geschlossenes System sein oder es kann unterschiedliche Systeme unter einer gemeinsamen Oberfläche vereinen. Hier ist nicht nur eine gemeinsame Suche möglich, sondern auch das Betrachten von Karten verschiedener Anbieter aus dem Portal heraus. Auch andere Dienste, die auf Geodaten basieren, können in einem Portal zusammengeführt werden. Um dies zu erreichen ist die Verwendung einheitlicher Standards notwenig. Die Art und Anzahl dieser Standards gibt die Möglichkeiten eines Geoportals an, verschiedene Systeme oder Dateiformate zu integrieren. [BeSm04, TaSe05, Esri03a, Teeg01a]

Downloadmöglichkeiten Wenn der Benutzer die gesuchten Geodaten gefunden hat, dann möchte er diese eventuell zur weiteren Verarbeitung auf seinen lokalen Computer herunterladen. Diese Funktion bieten jedoch bei weitem nicht alle Portale an. Wenn ein Portal nur auf externe Angebote verweist, dann hängt es von diesen ab, ob die Daten für den Download verfügbar sind.

Oft ist gar keine Downloadfunktion vorgesehen oder es werden nur wenige ergänzende Informationsdokumente oder Basisdaten zum Download angeboten. Wenn einige Daten herunterladbar sind, dann muss dies noch lange nicht für alle verfügbaren Daten gelten. Alternativ kann man jedoch die Urheber der Daten kontaktieren und auf diesem Weg an die Daten gelangen. Oder die Daten können ausschließlich online betrachtet werden.

Wenn ein Download angeboten wird, können verschiedene Dateiformate zur Verfügung stehen. In [Cros05] werden beispielsweise Geoportale unter anderem anhand der für den Download


19

verfügbaren Formate verglichen. Bei kostenpflichtigen Daten kann ein Geoportal zwischen Käufern und Verkäufern vermitteln oder selbst Daten zum Kauf anbieten [TaSe05].

Benutzer-Benutzer-Kommunikation Ein Geoportal kann den Zugriff auf Funktionen zur Kommunikation der Benutzer untereinander vermitteln oder selbst anbieten. So können die Benutzer Informationen oder sogar Daten austauschen [Food05, Teeg01a].

Visuelle Darstellung und Analyse Viele Geoportale bieten die Möglichkeit, die bereitgestellten Karten für den Benutzer zu visualisieren (Mapviewer). Um nicht nur eine statische Karte betrachten zu müssen, können verschiedene Funktionen für die visualisierte Karte angeboten werden. Die gebräuchlichsten sind sicherlich das Verschieben des aktuellen Kartenausschnitts („panning“), das Zoomen in die bzw. aus der Karte und das Abfragen von Informationen zu Objekten in der Karte („querying“). [AdKr06] Auch andere Funktionen, wie eine Übersicht über die Ebenen der Karte, das Ein- und Ausblenden von Ebenen, eine Übersichtskarte oder eine Legende sind denkbar.

Ein Portal kann zudem nicht nur eine Karte anzeigen, sondern gleich mehrere Karten gleichzeitig, die räumlich korrekt zueinander liegen („overlay“, [Food05]). Diese und andere einfache Analysefunktionen können angeboten werden.

Sicherheit und Benutzerverwaltung Wenn ein Geoportal oder Teilfunktionen eines Geoportals nicht allen Benutzern zugänglich seien sollen, dann muss eine Benutzerverwaltung entsprechende Beschränkungen anbieten können. Hier müssen bestimmte Regeln („policies“) festgelegt werden, deren Durchsetzung das Geoportal übernehmen muss. [BKAS04, Mitt04, Teeg01a] Solche Beschränkungen können auch dazu dienen, erfahrenen Benutzern mehr Funktionen anzubieten als unerfahrenen [ACI+97].

Entwicklungskosten Neben dem Funktionsumfang und der Qualität der Funktionen sind ebenfalls die Kosten wichtig, die aufgebracht werden müssen, um das Geoportal zu entwickeln und zu unterhalten. Gerade wenn nur wenige Mittel zur Verfügung stehen, sind die Kosten ein wichtiger Punkt. Kommerzielle Systeme zum Aufbau von Geoportalen (z.B. ESRI ArcIMS) sind mit hohen Lizenzkosten verbunden. Diese Kosten können beispielsweise durch die Verwendung von Open Source Software vermieden werden.

2.4.3 Bewertung der Kriterien Die im vorangegangenen Kapitel vorgestellten Kriterien werden im Folgenden bewertet. Dies geschieht im Bezug auf das Geoportal für das GLOWA Volta Projekt und dessen Anforderungen. So sind einige der Kriterien hierbei weniger wichtig als andere.

Wichtig ist sicherlich bei jedem Geoportal die einfache Gliederung und Themeneinordnung der angebotenen Informationen, also wie gut auch unerfahrene Benutzer sich auf den Seiten des Portals zurechtfinden und benötigte Informationen auffinden können. Hierzu tragen auch Art und Umfang der Suchfunktionen bei, mit dem der Benutzer gewünschte Daten finden kann. Eine übersichtliche Präsentation der Ergebnisse einer Suche ist ebenfalls wichtig für ihre Auswertung durch den Benutzer.


20

Nachdem Geodaten gefunden wurden, ist eine visuelle Darstellung für den Benutzer wichtig, die auch einer ersten einfachen Analyse dienen kann. So kann man direkt sehen, ob man die richtigen Informationen gefunden hat und kann diese auch bereits betrachten und auswerten. Auch der Vergleich verschiedener Informationen ist so möglich. Wenn diese Funktionen nicht ausreichen oder die Daten anderweitig weiterverarbeitet werden sollen, ist eine Downloadfunktion für möglichst viele Daten erforderlich. Hier ist im GLOWA Volta Geoportal eine Benutzeridentifikation notwendig, weil nicht jeder Benutzer alle Daten herunterladen können soll. Da das GLOWA Volta Geoportal viele Daten möglichst gut zugänglich machen soll, ist die Interoperabilität ebenfalls ein wichtiges Kriterium.

Für ein Projekt der Entwicklungsforschung mit begrenzten finanziellen Mitteln sind die Entwicklungskosten eines Geoportals entscheidend, zumal das Portal später auch im Projektgebiet in Afrika zum Einsatz kommen soll. Hohe Lizenzgebühren für Software oder teure Entwicklungskosten durch kommerzielle Firmen können nicht aufgebracht werden.

Die weiteren genannten Kriterien, wie die Mehrsprachigkeit, Geschwindigkeit, Qualität und Erreichbarkeit sind im GLOWA Volta Projekt weniger wichtig. Die meisten dieser Faktoren hängen von der späteren Administration des Servers und Pflege des Datenbestandes ab. Dies gilt auch für viele Sicherheitsanforderungen (z.B. an einer sicheren Konfiguration des Servers). Sie sollten jedoch nicht vernachlässigt werden.

2.4.4 Beispiele existierender Geoportale In diesem Kapitel werden verschiedene, bereits existierende Geoportale vorgestellt. Sie werden anhand der vorgestellten Kriterien bewertet, falls die entsprechenden Informationen aus Literaturquellen oder dem Angebot des jeweiligen Geoportals im Internet bekannt sind.

Geospatial One Stop Das Geospatial One Stop (GOS, [Gos08]) ist ein bekanntes Katalogportal, welches von der US-amerikanischen Regierung initiiert wurde. Es ermöglichst das Auffinden von Geodaten, -diensten und -anbietern in den USA über eine einheitliche Oberfläche. Die Daten werden von verschiedenen staatlichen Behörden angeboten und sollen Regierungsstellen und der Öffentlichkeit zur Verfügung stehen [Cros05]. Neben Karten und Dokumenten kann man beispielsweise auch externe Anwendungen mit Geodatenbezug finden.

Das Geoportal wurde auf eine einfache Benutzbarkeit hin ausgelegt. Es bietet eine einfache Standardsuche, die jedoch durch eine umfangreiche erweiterte Suche ergänzt wird. So ist die Suche nach Stichworten möglich, die man auf Kategorien, bestimmte Datentypen, Anbieter und Zeiten einschränken kann. Dazu wird eine räumliche Suche angeboten. Man kann allerdings nicht in einzelnen Metadatenelementen suchen. Kanäle und umfangreiche Informationsseiten vereinfachen den Einstieg und die Nutzung [TaSe05]. Der große Funktionsumfang des Portals erschwert die Einarbeitung jedoch im Vergleich zu einem weniger umfangreichen Portal.

Der Studie [LSS+06] zufolge liefert GOS die Suchergebnisse in einer guten Zeit aus. Die Ergebnisse werden in einer Liste mit einer kurzen Zusammenfassung angezeigt, von wo man einem Link zu den vollständigen Metadaten folgen kann. Dort ist dann der Aufruf einer externen Webseite oder eines integrierten Mapviewers möglich. Dieser bietet alle wichtigen Funktionen und ermöglicht sogar die gemeinsame Anzeige mehrerer Karten. Nur ein Teil der Daten lässt sich herunterladen, wenn dies vom jeweiligen Anbieter unterstützt wird. Karten lassen sich jedoch immer als einfache Bilddateien abspeichern. Eine Stichprobe im April 2008 hat ergeben, dass


21

nicht alle Karten und Verweise auf externe Angebote noch verfügbar sind. Der Mapviewer benötigt lange zum Aufbau der Karte und reagiert träge auf Eingaben.

Abbildung 2.1 Startseite des Geospatial One Stop Portals

GOS verwendet den in den USA sehr verbreiteten Metadatenstandard FGDC [Fgdc07], der von einem gleichnamigen Gremium der amerikanischen Regierung entwickelt wurde. Außerdem werden mehrere OGC-Standards unterstützt. Zukünftig soll GOS die Möglichkeit bieten, in fremde Webangebote eingebettet zu werden. All dies ermöglicht eine gute Interoperabilität. [TaSe05, FOJ04, Cros05]

GOS vermittelt den Zugriff auf sogenannte Communities, in denen sich gleich gesinnte Benutzer untereinander austauschen können. Außerdem wird ein virtueller Marktplatz zum Austausch von Daten angeboten. Die gesamte Funktionalität von GOS ist jedermann frei zugänglich.

Die Verwendung kommerzieller Software und die Entwicklung durch einen kommerziellen Anbieter (ESRI) lassen auf hohe Kosten schließen, die sich ein kleineres Projekt nicht leisten könnte [FOJ04].

INSPIRE Das Katalogportal Infrastructure for Spatial Information in Europe (INSPIRE, [Insp08]) ist das europäische Äquivalent zu Geospatial One Stop. Es wurde von der Europäischen Union (EU) beschlossen und dient dazu, Geodaten und -dienste der Behörden aller Länder der EU allgemein zugänglich zu machen. Das Portal verwaltet ausschließlich Metadaten und bietet selbst keine Geodaten an. [FOJ04, Gdi07]

Wie in der Studie [LSS+06] beschrieben, bietet INSPIRE eine gut strukturierte Benutzerschnittstelle und umfangreiche Suchfunktionen mit einer Standardsuche und einer erweiterten Suche nach verschiedenen Metadatenelementen, Orten und Zeiträumen an. Auch die Antwortzeiten auf Suchanfragen sind gut. Obwohl es sich um eine europäische Webseite handelt, ist die Oberfläche nur auf Englisch verfügbar.


22

Abbildung 2.2 Erweiterte Suche des INSPIRE Geoportals

Die Suchergebnisse werden als Liste aus Datentyp und Titel angezeigt. Von hier aus lassen sich zu jedem Eintrag detailliertere Metadateninformationen einblenden. Zudem lassen sich – falls erforderlich – externe Anwendungen für den entsprechenden Eintrag starten oder man kann Karten zum integrierten Mapviewer hinzufügen. Der Mapviewer kann als WMS verfügbare Karten mit der üblichen Funktionalität anzeigen, so ist beispielsweise das Verschieben des Kartenausschnitts oder Zoomen möglich. Auch die gemeinsame Anzeige mehrerer Karten wird unterstützt. [BKAS04, Rie05]

INSPIRE verwendet den Metadatenstandard ISO 19115. Außerdem bietet das Geoportal Interoperabilität durch viele weitere Standards des OGC. Alle verwendeten Standards werden von der INSPIRE-Initiative der EU vorgeschrieben. [BKAS04, BeSm04, Cros05, Rie05] Das Herunterladen von Daten wurde bei INSPIRE als Fähigkeit mit eingeplant [Rie05], jedoch war dies bei einer Stichprobe im April 2008 offenbar noch nicht möglich.


23

Das Portal bietet keinerlei Funktionen an, damit Benutzer untereinander kommunizieren können. Die angebotene Funktionalität steht jedoch ohne Einschränkungen jedem Benutzer zur Verfügung. Bei durchgeführten Stichproben im April 2008 waren das INSPIRE Geoportal oder Teilfunktionen davon teilweise nicht zu erreichen.

Die umfangreiche, mehrjährige Planung durch die EU und der große Funktionsumfang lassen auf hohe Kosten für INSPIRE schließen, die ein kleines Projekt nicht aufbringen könnte.

GeoPortal.Bund GeoPortal.Bund [Gbun08] ist das zentrale Katalogportal der Bundesrepublik Deutschland [GLCZ08]. Hierüber sollen alle Bürger sämtliche verfügbaren Geodaten (Basis- und Fachdaten) der Behörden des Bundes finden können [FOJ04].

Der Funktionsumfang des Portals ist nicht sehr umfangreich, so dass die Bedienung und der Einstieg einfach sind. Hilfetexte, wie ein Glossar, und ein Assistent für die Suche erleichtern zudem den Einstieg. Die einfache Suche nach Stichwörtern wird auch hier durch eine erweiterte Suche ergänzt, die nach Themen sucht und auf bestimmte Kategorien, Zeiträume und Orte eingeschränkt werden kann. Eine Suche in einzelnen Metadatenelementen ist auch hier nicht möglich.

Abbildung 2.3 Mapviewer des GeoPortal.Bund

Die Suchergebnisse werden nach Anbietern sortiert aufgelistet, was für den Benutzer eine umständliche Auswertung bedeutet [GLCZ08]. Die Ergebnisliste zu den jeweiligen Anbietern besteht aus Titeln und kurzen Zusammenfassungen. Von hier kann man die ausführlichen Metadaten aufrufen und direkt über einen Mailto-Link das eigene E-Mail-Programm mit vorausgefüllten Angaben zu dem jeweiligen Datensatz öffnen, um die Daten bei dem Verantwortlichen zu bestellen. Diese Funktion war jedoch bei der Stichprobe im April 2008 bei einigen Datensätzen fehlerhaft. Die Ausdehnung einiger Karten kann man sich auf einer


24

Übersichtskarte anzeigen lassen oder die Karte mit dem in das Portal integrierten Mapviewer betrachten. Bei einer Stichprobe stand diese Funktionalität jedoch nur für einige Metadatensätze zur Verfügung, gerade das Betrachten einer Karte mit dem Viewer wird nur selten angeboten.

Der Kartenviewer bietet die vollständige übliche Funktionalität (siehe Kapitel 2.4.2). Dieser sogenannte Basicviewer wird noch durch einen Expertenviewer ergänzt, der auf Java basiert. Eine Downloadfunktion ist geplant, jedoch noch nicht verfügbar. Sämtliche Funktionen des Portals stehen allen Benutzern kostenlos zur freien Verfügung. [GLCZ08]

GeoPortal.rlp Zusätzlich zum GeoPortal.Bund gibt es auch entsprechende Geoportale der Bundesländer. Ein Beispiel hierfür ist das GeoPortal.rlp [Grlp08] des Landes Rheinland-Pfalz. Genau wie das Geoportal.Bund ist es ein Katalogportal, welches dem Benutzer Geodaten und -dienste verschiedener Anbieter zugänglich macht [StBa05]. Diese Anbieter sind hauptsächlich behördliche und kommunale Institutionen.

Abbildung 2.4 Startseite des GeoPortal.rlp

Der Funktionsumfang ist wie beim Geoportal.Bund stark eingeschränkt, was die Bedienung und den Einstieg erleichtert. Umfangreiche Informationstexte und ein Glossar erleichtern neuen Benutzern ebenfalls den Einstieg in das Thema.

Eine Suche ist ausschließlich nach Stichwörtern möglich. Eine erweiterte Suche, wie sie bei anderen Geoportalen üblich ist, existiert hier nicht. So ist es nicht möglich, in einzelnen Metadatenelementen zu suchen oder zeitliche und räumliche Anfragen zu stellen. Es kann aber nach Adressen und Wohnorten gesucht werden [Kurp07].


25

Die Suchergebnisse sind übersichtlich in Kategorien, wie Adresse, Dienste, Info und Metadaten eingeteilt [Kurp07]. Es wird allerdings nur der Titel des jeweiligen Treffers angezeigt, was eine Auswertung der Ergebnisse durch den Benutzer erschwert. Die vollständigen Informationen, beispielsweise über die Metadaten, erhält man erst, wenn man einen Treffer anklickt. Die Kartendienste lassen sich zu dem in das Portal integrierten Mapviewer hinzufügen, so dass hier mehrere Karten gemeinsam dargestellt werden können [Kurp07].

Als Benutzeroberfläche zur Anzeige von Karten wird das Open Source Programm Mapbender verwendet, das die übliche Funktionalität zum Betrachten von Karten anbietet. Hier sind beispielsweise das Verschieben, Zoomen oder das Abfragen von Attributen zu nennen. Außerdem kann man Layer an- und abwählen und eine Legende einblenden. Beim Geoportal.rlp kann man, abgesehen von einigen vorbereiteten Textdokumenten, keine Daten herunterladen.

Das Geoportal verwendet Standards der ISO (International Organization for Standardization) und des OGC, um eine Interoperabilität mit externen Anbietern zu erreichen [Kurp07]. Dies ermöglicht zudem die Verwendung von Open Source Software für die Kartendarstellung, wenn diese die entsprechenden Standards unterstützt. Neben dem bereits erwähnten Mapbender nennt die Seite auch weitere verwendete Open Source Programme, sogar das Portal selbst steht unter einer Open Source Lizenz zur Verfügung. Die Nutzung von Open Source spart dem Projekt Entwicklungsaufwand und somit Kosten.

Die gesamte Funktionalität steht allen Benutzern offen. Es gibt allerdings eine Benutzeranmeldung, die es ermöglicht, Suchanfragen und zusammengestellte Karten abzuspeichern. Außerdem erhält man so Schreibzugriff auf eine Besonderheit dieses Geoportals, das integrierte Wiki, das sich jedoch hauptsächlich an Entwickler und Diensteanbieter richtet und keine Kommunikation für reguläre Benutzer bietet.

Gigateway In England gibt es ebenfalls ein Katalogportal der Regierung, das Gigateway [Giga08] heißt. Sein Funktionsumfang beschränkt sich auf die Suche in Metadaten, eigene Geodaten werden nicht angeboten.

Neben seiner umfangreichen Suche in Metadaten aller eingebundenen Anbieter, die eine Stichwortsuche und Suchmöglichkeiten nach Kategorien und räumlichen und zeitlichen Angaben ermöglicht, gibt es noch eine Anbietersuche und eine Suche nach lokalen Informationen anhand von Postleitzahlen. [GLCZ08]

Die Suchergebnisse der Metadatensuche werden nach Anbietern sortiert aufgelistet. Das hat die bereits erwähnten Nachteile für die Auswertbarkeit der Ergebnisse durch den Benutzer. Außerdem werden von den Ergebnissen jeweils nur die Titel angezeigt, was eine Auswertung zusätzlich erschwert. [AdKr06] Auf Wunsch kann man sich zu jedem Eintrag die vollständigen Metadaten anzeigen lassen.

Weitere Funktionalität bietet Gigateway nicht, der Funktionsumfang ist also sehr stark begrenzt und beschränkt sich ausschließlich auf die beschriebenen Suchfunktionen. Zu den wenigen Informationen auf der Webseite gehört ein Newsletter.


26

Abbildung 2.5 Die Suchergebnisse von Gigateway werden nach Anbietern aufgelistet

Le Géoportail Le Géoportail [Geop08a] ist das zentrale Geoportal der französischen Regierung. Es ist ebenfalls ein Katalogportal mit einem integrierten Mapviewer [GLCZ08]. Seine Oberfläche ist übersichtlich gestaltet.

Die Suchfunktionen sind umfangreich und bieten neben einer einfachen Suche nach Stichwörtern auch erweiterte Suchanfragen nach ausgewählten Metadatenelementen sowie räumliche und zeitliche Anfragen. Jedoch lassen sich nicht alle Metadatenelemente explizit durchsuchen.

Die Suchergebnisse zeigen neben dem Titel auch eine Zusammenfassung an. Von hier kann man zudem direkt die vollständigen Metadaten anschauen, bei einigen Daten kann man auch den integrierten Mapviewer oder die zugehörige Webseite aufrufen. Einige Daten lassen sich auch direkt aus dem Portal heraus herunterladen [GLCZ08]. In [GLCZ08] ist zudem angegeben, dass ein Kauf nicht freier Geodaten über das Portal möglich ist.

MAPSTER MAPSTER ist ein Beispiel für ein Anwendungsportal. Es stand bei einer Stichprobe im April 2008 zeitweise nicht im Internet zur Verfügung. MAPSTER wurde vom kanadischen Fischereiministerium geschaffen und ist darauf spezialisiert, Informationen über Fischerei sowie Lebensräume in Meeren und Flüssen zu liefern. Wie in Anwendungsportalen üblich, stellt es die meisten Daten selbst zur Verfügung und greift nicht auf externe Anbieter zurück. [TaSe05]

Es gibt eine einfache Suchfunktion nach Stichwörtern, hauptsächlich werden dem Benutzer jedoch alle Daten als Karte visualisiert. Eine Suche in einem Metadatenkatalog steht nicht zur Verfügung [TaSe05]. In dem Mapviewer lassen sich die üblichen Funktionen, wie Verschieben oder Zoomen verwenden, außerdem lassen sich einzelne Ebenen an- oder abschalten.


27

Abbildung 2.6 Das Anwendungsportal MAPSTER

Transport Direct Transport Direct [Tran08] ist ein weiteres Beispiel für ein Anwendungsportal. Es bietet eine stark spezialisierte Anwendung zur Reiseplanung in Großbritannien. Die zur Verfügung stehenden Suchfunktionen sind sehr vielfältig, was dazu führt, dass das Portal sehr unübersichtlich wirkt. Die Oberfläche steht in Englisch und Walisisch zur Verfügung.

Wie in [TaSe05] dargelegt, war es unmöglich, die Vielzahl von Funktionen, die zu einer Reiseplanung notwendig sind, in einer Suche zu vereinen. So werden verschiedene Suchen für unterschiedliche Zwecke angeboten, die auf verschiedene Informationsquellen zurückgreifen. So kann man beispielsweise Reiserouten oder Reiseinformationen zu Zügen und Flugzeugen suchen lassen. Alle Suchen sind auf ihren jeweiligen Zweck spezialisiert, eine allgemeine Suche in allen Metadaten wird nicht angeboten.

Der integrierte Mapviewer kann dazu verwendet werden, Orte wie zum Beispiel Haltestellen auf einer Karte anzuzeigen. Zwar werden übliche Funktionen, wie das Verschieben des Kartenausschnitts oder das Zoomen angeboten, diese lassen sich jedoch nur umständlich bedienen.

Besucherinformationssystem Nationalpark Berchtesgaden Das Besucherinformationssystem für den Nationalpark Berchtesgaden [Bnb08] ist ein weiteres Beispiel für ein Anwendungsportal. Es wurde im Rahmen einer Diplomarbeit entwickelt und soll Besucher des Nationalparks informieren können [UnSc05]. Die Daten werden alle vom Portal selbst bereitgestellt. Da der Funktionsumfang aufgrund der starken Spezialisierung sehr gering ist, ist die Oberfläche sehr übersichtlich.


28

Die Suchfunktion des Portals beschränkt sich darauf, aus einem Auswahlmenü Orte oder Touren auszuwählen, die dann auf der Karte dargestellt werden. Hier ist wieder der hohe Grad der Spezialisierung zu erkennen. Der Mapviewer bietet grundlegende Funktionalität (Verschieben, Zoomen, Layer an/aus) sowie Abfragen zu Objekten auf der Karte. Der geringe Funktionsumfang und die Verwendung von Open Source Software (UMN MapServer) führten zu niedrigen Kosten für die Entwicklung des Angebots [UnSc05].

Conservation GeoPortal Das Conservation GeoPortal [Cons08] ist ein Katalogportal, welches von verschiedenen Umweltschutzorganisationen und anderen Partnern gemeinsam entworfen wurde und betrieben wird. Das Portal hat seinen eigenen Metadatenkatalog, die eigentlichen Daten stammen jedoch von den teilnehmenden Organisationen [Natu06].

Die Suche bietet eine Standardsuche nach Stichwörtern und eine erweiterte Suche für komplexere Suchanfragen nach Orten, Kategorien, Datentypen und Zeiten. Eine Suche in einzelnen Metadatenelementen ist nicht möglich. Für einen einfachen Einstieg gibt es Kanäle zu unterschiedlichen Themen.

Als Suchergebnisse werden ausgewählte Metadatenelemente angezeigt. Auf Wunsch kann man eine detailliertere oder vollständige Sicht der Metadaten aufrufen. Einige Daten können von hieraus auch mit dem integrierten Mapviewer betrachtet werden. Hierbei kann man auch mehrere Karten kombinieren [Natu06]. Eine Auswahl von Metadaten ist mit vorbereiteten Daten verknüpft, die sich herunterladen lassen. Der Mapviewer bietet einen großen Funktionsumfang (Verschieben, Zoomen, Abfragen, Hinzufügen von Karten, Legende, Layer an/aus). Er lädt jedoch lange und reagiert träge auf Eingaben. Eine Benutzeridentifikation wird verwendet, um Suchanfragen und Karteneinstellungen zu speichern und um dem Katalog eigene Metadaten hinzufügen zu können.

Das Geoportal verwendet den kommerziellen ESRI ArcIMS Server und wird von vielen Organisationen gefördert [Esri06b], was auf hohe Kosten schließen lässt, die nur ein Projekt mit entsprechenden Mitteln aufbringen kann.

GEO Portal Das GEO Portal [Geop08b] ist ein gemeinsames Projekt der European Space Agency (ESA) und der Food and Agriculture Organization der Vereinten Nationen (FAO), welches zum Auffinden von Karten, Informationen und Dienstanbietern dienen soll. [Esa07] Die übersichtliche Oberfläche dieses Katalogportals steht auf Englisch und Chinesisch zur Verfügung.

Aufgrund eines animierten Globus auf der Startseite des Portals reagiert dieses nur sehr träge auf Eingaben, wenn man diese von der Hauptseite aus tätigt. Allerdings bietet der Globus einen benutzerfreundlichen Einstieg in das Portal. Dies gilt auch für die Kanäle zu verschiedenen Themen, die ebenfalls angeboten werden.

Das Portal bietet eine Standardsuche nach Stichwörtern genau so an wie eine erweiterte Suche, die zusätzlich nach Regionen, Koordinaten, Kategorien und Datentypen suchen kann. Eine Suche anhand bestimmter Metadatenelemente ist nicht möglich. Die Suche findet in den verteilten Katalogen verschiedener externer Anbieter statt [Esa07]. Die Suchergebnisse sind anhand des Datentyps (z.B. Informationen, Anbieter, Daten) unterteilt. Nach einer Auswahl wird die eigentliche Ergebnisliste angezeigt, die aus Titeln und kurzen Texten besteht. Detailliertere


29

Metainformationen lassen sich nicht abrufen. Bei Karten wird direkt der integrierte Mapviewer gestartet, der die übliche Funktionalität anbietet (Verschieben, Zoomen, Abfragen von Informationen zu Kartenobjekten, Layer an/aus). Zusätzlich ist es möglich, mehrere Karten oder Ebenen zu kombinieren. Bei einer Stichprobe im April 2008 funktionierte der Mapviewer jedoch nicht, ausgewählte Karten wurden nicht angezeigt, weil benötigte XML-Dateien offenbar fehlten. GEO Portal steht allen Benutzern ohne Einschränkungen zur Verfügung [Esa07]. Eine Benutzeridentifikation wird ebenso wenig angeboten wie ein Download von Daten.

Abbildung 2.7 Die Startseite des GEO Portals wird von einem animierten Globus dominiert

IDEC Geoportal Das IDEC Geoportal [Idec08] ist ein Katalogportal der katalanischen Regierung [Guim04]. Oberfläche und Metadaten sind auf Englisch, Spanisch und Katalanisch verfügbar. Bei einer Stichprobe im April 2008 war das IDEC Geoportal teilweise nicht zu erreichen.

IDEC verwendet den Metadatenstandard ISO 19115 und OGC-Standards, wie beispielsweise WMS [Guim04], was die Integration externer Dienste ermöglicht. Das Portal bietet vorgefertigte Karten aus verschiedenen Quellen an, außerdem ist es in der Lage, externe Daten, beispielsweise als WMS-Dienst, einzubinden [Guim04]. Hierfür verwendet es jedoch unterschiedliche Mapviewer, die beide über die übliche Funktionalität verfügen. Dem Viewer für Dienste kann man mehrere Karten hinzufügen, der Viewer für Karten enthält bereits Daten, die sich in Form von Ebenen auswählen lassen. Zusätzlich bietet er eine Suche nach Adressen und Einrichtungen


30

an. Es ist nicht sinnvoll, zwei verschiedene Programme für dieselbe Funktionalität zu verwenden, da dies die Einarbeitung und Bedienung für den Benutzer erschwert.

Der Metadatenkatalog lässt sich getrennt nach Daten und Diensten durchsuchen. Man kann anhand von Stichwörtern, Themen, Organisationen und Datentypen und nach Koordinaten suchen. Eine Trennung in eine einfache Standardsuche und eine erweiterte Suche, wie es bei anderen Katalogportalen üblich ist, findet nicht statt. Die Suchergebnisse zeigen eine Liste von Titeln sowie ein weiteres Metadatenelement an. Auf Wunsch können eine Übersicht oder die vollständigen Metadaten des jeweiligen Eintrags angezeigt werden. Bei manchen Ergebnissen kann einer der Mapviewer gestartet werden.

Wie in [Guim04] erwähnt, sollen Daten nicht nur beschrieben und gefunden, sondern in ausgewählten Fällen auch heruntergeladen werden können. Das Portal selbst bietet eine solche Funktion jedoch nicht an, so dass dies nur über einen Link auf einen externen Anbieter möglich seien kann, der diese Funktion anbietet. Ein ins Portal integrierter Marktplatz benötigt eine Benutzeridentifikation, alle anderen Funktionen stehen allen Benutzern frei zur Verfügung.

PortalU PortalU [Port08] ist ein deutsches Katalogportal der Umweltverwaltungen von Bund und Ländern. Es soll verschiedene Informationen zum Thema Umwelt auf einer Webseite zugänglich machen. Die Oberfläche des Portals steht auf Deutsch und Englisch zur Verfügung.

PortalU kann verschiedene Metadatenkataloge und andere Informationsquellen durchsuchen. Außerdem bietet PortalU mehrere eigene Metadatenkataloge zu verschiedenen Themen an. Durch eine mit Plug-ins erweiterbare Architektur können diese Fähigkeiten später noch ergänzt werden. Kompatibilität und Erweiterbarkeit wurden bei der Entwicklung von PortalU besonders berücksichtigt. In [KVKL07] und [VKK06] findet man weitere Informationen hierzu.

Die integrierte Suche ist sehr umfangreich. Neben einer einfachen Suche nach Stichwörtern gibt es eine erweiterte Suche, die zusätzliche Suchoptionen (Raum, Zeit, Themen) unterstützt. Außerdem gibt es spezialisierte Suchen, beispielsweise für Messwerte. Die Suchergebnisse bestehen aus Titel, einer Zusammenfassung, dem Anbieter und einer Quelle. Sie verweisen direkt auf externe Webangebote. Separat wird auf Treffer in externen Suchkatalogen hingewiesen, die man jedoch zunächst aufrufen muss, um die Ergebnisse anzuschauen. Es findet keine Integration in die eigene Trefferliste statt. PortalU bietet außerdem einen eigenen Mapviewer an, dieser ist jedoch nicht mit der Suchfunktion verknüpft, wie es bei anderen Katalogportalen in der Regel der Fall ist.

Der integrierte Mapviewer basiert auf dem Open Source Programm Mapbender und bietet die übliche Funktionalität. Ein vorbereiteter Satz Karten lässt sich in Form von Ebenen aktivieren oder deaktivieren. Es gibt zudem die Möglichkeit, weitere WMS-Dienste einzubinden, die man entweder aus einer vorbereiteten Liste auswählen oder per URL aufrufen kann. Alle Funktionen des Portals stehen allen Benutzern offen. Über eine Benutzeridentifikation können Benutzer die Startseite und die Suche personalisieren.

3.1 Herangehensweise

31

3 Entwicklung des Geoportals

3.1 Herangehensweise Vor der eigentlichen Programmierarbeit für das Geoportal des GLOWA Volta Projekts (GVP) stand zunächst einmal eine grobe Anforderungsanalyse. Als Erstes musste der bisherige Zustand der Geodatenverwaltung im GVP sowie die gewünschten Anforderungen der Projektmitarbeiter an die Datenverwaltung und das Portal festgestellt werden. Es musste außerdem berücksichtigt werden, dass das Geoportal nach Abschluss des Projekts in Afrika zum Einsatz kommen soll. Nicht alle Anforderungen waren bereits zu Beginn bekannt, so dass die Geoportal-Architektur im Laufe der Zeit mehrfach überarbeitet werden musste.

Bereits von Anfang an gab es die Anforderung der Datensicherheit und den Wunsch nach der Möglichkeit, Karten im Webbrowser anzeigen zu können. Daraus wurden sehr früh die Verwendung eines separaten Datenservers und die Verwendung eines Mapservers zur internet-kompatiblen Aufbereitung der Geodaten abgeleitet. Als erstes musste also entschieden werden, welcher Mapserver zum Einsatz kommen soll. Aus der Notwenigkeit eines Mapservers leitet sich auch automatisch die Notwendigkeit einer Benutzeroberfläche für die Anzeige der vom Mapserver aufbereiteten Daten ab. Auch hier musste zwischen verschiedenen Lösungen ausgewählt werden. Die Oberfläche sollte viele Funktionen zum interaktiven Umgang mit der Karte bieten und zudem einfache Analysefunktionen zur Verfügung stellen.

Da ein Mapserver nur die Daten anzeigen kann, die ihm zur Verfügung stehen, und die Daten auf einem separaten Server abgelegt werden sollten, musste eine Transferlösung entworfen werden. Die Daten mussten vom Datenserver auf den Webserver übertragen werden. Hier wurde das Konzept des Datamanagers als Geoportalbestandteil entworfen, der zunächst aus zwei Teilen bestehen sollte. Eine Komponente auf dem Webserver sollte die Daten anfordern, die dann von der Komponente auf dem Datenserver geliefert werden sollten. Dazwischen hätte ein eigenes Protokoll auf RMI-Basis die Daten übertragen sollen. Dieser Ansatz wurde zugunsten eines deutlich einfacheren Verfahrens mit bereits vorhandenen Protokollen (SMB, JDBC) und nur eines Datamanagers (auf dem Webserver) wieder verworfen.

Ebenfalls sehr früh in der Planungsphase war die Anforderung nach einer möglichst geringen erforderlichen Bandbreite gegeben, da das Geoportal von Afrika aus genutzt werden soll, wo Breitbandanbindungen an das Internet selten sind. Nach einer Umfrage eines ZEF-Mitarbeiters vor Ort entschärfte sich das Problem etwas, weil sehr viele Befragte Breitbandanbindungen zur Verfügung stehen hatten. Um jedoch möglichst wenige Personen von der Benutzung des Geoportals auszuschließen, ist die benötigte Bandbreite trotzdem zu berücksichtigen.

Da bei der Metadatenverwaltung zunächst die vorhandene Lösung am ZEF (M³Cat, [Inte07]) übernommen werden sollte, mussten hier Möglichkeiten gefunden werden, wie man aus dem Geoportal auf deren Datenbestand zugreifen konnte, um eine Suche oder anderweitigen Zugriff auf die Daten zu ermöglichen. Später wurde diese Lösung durch eine eigene ersetzt, so dass hierfür verschiedene andere Überlegungen getroffen werden mussten, die in dem entsprechenden Kapitel erläutert werden.


32

3.2 Architektur des Geoportals

3.2.1 Ursprünglicher Zustand

Webserver

ESRI ArcGIS Client

Meta-DB(M³Cat)manuell

per SSH

lokal

speichert

Intranet

NFS

Internet

BrowserBrowser

:80

RAIDmanuellper SSH

SSH ClientSSH Client

:22

Abbildung 3.1 Ursprünglicher Zustand der Verwaltung von Geodaten im Projekt

Bislang haben die Wissenschaftler des GLOWA Volta Projektes ihre gesammelten oder erstellten Geodaten nicht auf einem zentralen Server gespeichert. Stattdessen wurden die Daten entweder lokal auf dem eigenen Arbeitsrechner oder auf einem externen Medium abgelegt. In beiden Fällen standen sie anderen Personen nur sehr eingeschränkt zur Verfügung, da ein Zugriff nur durch Kontaktieren der entsprechenden Person möglich war. Und dies wiederum war nur möglich, wenn bekannt war, ob jemand die Daten besitzt und wenn ja wer.

Am ZEF hatte man jedoch bereits begonnen, einige Daten auf einem Server abzulegen. Der Zugriff auf diesen Server war jedoch nur durch SSH möglich und die Daten waren nur über das Dateisystem sortiert, was die Suchmöglichkeiten stark einschränkte.

Um einen Überblick über die vorhandenen Daten zu schaffen, wurden einige Daten bereits mit Metadaten beschrieben. Um die Metadaten zu verwalten, kam die Verwaltungssoftware M³Cat zum Einsatz, die im Intranet auf einem Arbeitsrechner installiert war. Um die wichtigsten Informationen hieraus als Tabelle im Internet zu publizieren, mussten sie halbautomatisiert aus der Datenbank von M³Cat exportiert werden und manuell als HTML-Tabelle auf den Webserver übertragen werden. Da dieser Vorgang sehr aufwändig war, wurde er nur selten durchgeführt, so dass die Tabelle im Internet immer nur veraltete Informationen enthielt.

Hinzu kommt, dass in M³Cat ein sehr komplexer Metadatenstandard (FGDB) verwendet wurde, bei dem sehr viele Felder ausgefüllt werden mussten, obwohl nur wenige davon benötigt wurden. So wurde die Metadatenbank nur unzureichend gepflegt.


33

3.2.2 Schwächen der ursprünglichen Architektur Die bisherige Architektur bot nur eingeschränkte Möglichkeiten, um Daten zentral zu speichern und zu verwalten. Zwar wurden Metadaten eingesetzt, um den Zugriff auf die Daten zu erleichtern, der verwendete Standard war jedoch zu komplex und die Metadaten wurden selten ausgefüllt. Außerdem waren sie nicht mit den eigentlichen Daten verknüpft. Es war so nicht möglich, bestimmte Datensätze zu finden. Dass die Daten stark verstreut an unterschiedlichen Orten und auf unterschiedlichen Medien vorlagen, erschwerte die Suche noch zusätzlich. Da die Metadaten im Internet unvollständig und veraltet waren, konnten Personen, die nicht am ZEF arbeiteten, ihre Suche somit nicht auf diese Daten stützen. Fehlende Visualisierungsmöglichkeiten verhinderten es, dass überprüft werden konnte, ob man die richtigen Daten gefunden hatte. Außerdem musste man die Daten zunächst umständlich bei den verantwortlichen Personen anfordern, um mit ihnen arbeiten, sie analysieren oder sie auch nur betrachten zu können. Da der Anfragende hierbei die Suche nicht selbst durchführte und auch keinen Überblick über die verteilt vorliegenden Daten hatte, gestaltete sich eine eindeutige Suchanfrage bei den verantwortlichen Personen als schwierig. Die Möglichkeit, die Daten zu den gefundenen Metadaten direkt über das Internet herunter zu laden, gab es nicht. Das Bereitstellen eigener Daten und Metadatenbeschreibungen waren ebenso beschränkt. Alle diese Punkte trugen dazu bei, dass das alte System nur sehr umständlich zu bedienen war und praktisch nicht genutzt wurde. Daten wurden nur über persönlichen Kontakt oder gar nicht verbreitet. Dieser persönliche Kontakt der Benutzer untereinander wurde von dem alten System in keiner Weise über das Internet ermöglicht oder erleichtert. Es gab keinen zentralen Anlaufpunkt, um zusätzliche Informationen zu den Daten oder den betroffenen Themengebiete zu erhalten.

3.2.3 Anforderungen Aus den Schwächen der ursprünglichen Architektur und aus zusätzlichen Vorgaben, die von Mitarbeitern des Projekts gemacht wurden, ergeben sich die Anforderungen für die Architektur des GLOWA Volta Geoportals. Sie werden im Folgenden getrennt nach funktionalen und nichtfunktionalen Anforderungen aufgelistet.

• Funktionale Anforderungen: • Verwaltung der Metadaten, die beschreibende Informationen zu den Ressourcen enthalten, • Suchfunktionen für die Metadaten, • Kartendarstellung von Geodaten, • Grundlegende Onlineanalyse für visualisierte Geodaten, • Import und Export von Daten und Metadaten, • Optionaler Lesezugriff auf ESRI File und Personal Geodatabases, • Informations- und Kommunikationsmöglichkeiten für die Benutzer.

• Nichtfunktionale Anforderungen: • Erweiterbarkeit, um an spätere Anforderungen anpassbar zu sein, • Geringe Kosten durch Open Source, • Ausfallsichere und fehlersichere Speicherung von Geodaten, • Datensicherheit vor Diebstahl und Missbrauch, • Zugriffsbeschränkungen auf Metadatenverwaltung und Exportfunktionen, • Einfache Benutzbarkeit.


34

3.2.4 Neue komponentenbasierte Architektur Die genannten Anforderungen führten zur Entwicklung einer eigenen Architektur, die die Schwächen der ursprünglichen Architektur vermeidet. Diese Architektur wurde auch als lauffähiges System implementiert, das in Kapitel 3.3 näher beschrieben wird. In diesem Kapitel werden jedoch zunächst theoretische Aspekte der Architektur näher erläutert.

Das Geoportal besteht aus einem Hauptprogramm, das Funktionen zur Verwaltung der Metadaten und Suchfunktionen auf den selbigen bietet. Es verwaltet zudem den Zugriff auf alle Daten und bietet administrative Funktionen an. Da diese Funktionalitäten jedoch nicht ausreichen, kann das Hauptprogramm noch durch zusätzliche Programmteile erweitert werden.

Komponentenbasierter Ansatz und allgemeiner Programmaufbau Das GLOWA Volta Geoportal wird in Deutschland anhand der Anforderungen der hiesigen Wissenschaftler des ZEF entwickelt. Später soll es jedoch in Afrika zum Einsatz kommen. Die dortigen Anforderungen sind allerdings noch nicht oder zumindest noch nicht vollständig bekannt. So müssen beispielsweise in Zukunft möglicherweise andere oder zusätzliche Daten visualisiert werden, als heute. Die Architektur des Geoportals muss also erweiterbar sein und an neue Bedingungen angepasst werden können. Es wurde also bei der Entwicklung des Geoportals ein komponentenbasierter Ansatz gewählt. Das Hauptprogramm kann an verschiedenen Stellen durch Komponenten erweitert werden, die man austauschen oder durch neue ergänzen kann.

Das Geoportal und seine Komponenten bestehen jeweils aus mehreren Javaklassen und JSP-Dateien. Im Hauptverzeichnis befinden sich alle JSP-Dateien der Portalsoftware, die zugehörigen Javaklassen liegen im Java-Package datamanager. Einige JSP-Dateien sind, der Übersichtlichkeit wegen, noch in Unterverzeichnisse ausgelagert. Die JSP-Dateien aller Komponenten liegen in Unterverzeichnissen, die den Namen der Komponente tragen. Den gleichen Namen haben die Packages der zugehörigen Javaklassen. So kann man leicht alle Dateien entsprechen zuordnen. Eine Übersicht über alle Dateien mit einer kurzen Beschreibung und ihre Einordnung ins Model-View-Controller-Modell findet man in der Tabelle im Anhang 6.2. Alle verwendeten Komponenten sind unabhängig voneinander. Mit dem Portal sind sie nur über den Datamanager und benötigte aufrufende Links verbunden. Diese Autonomie ermöglicht ihre Austauschbarkeit.

Model-View-Controller Eine Möglichkeit, um Programmcode austauschbar und erweiterbar zu halten, ist der sogenannte Model-View-Controller-Ansatz (MVC, [Wiki08b]). Sowohl das Hauptprogramm des Portals als auch sämtliche Komponenten sind nach diesem Prinzip aufgebaut, um neben dem Komponentenansatz noch eine weitere Möglichkeit zum vereinfachten Austausch von Programmcode zu bieten. Man unterteilt den Code in Datenmodelle, Präsentationen und Steuerungen. Somit wird dem Programm eine logische Struktur vorgegeben, die auch die Wartbarkeit und Fehlersuche im Code vereinfacht.

Das Datenmodell („model“) repräsentiert und enthält die eigentlichen Daten mit denen gearbeitet werden soll. Im GLOWA Volta Geoportal enthalten sie in der Regel nur sehr wenig oder gar keine Anwendungslogik. Das Modell besteht hier aus den Datenbanken, Geodaten und speziellen Javaobjekten, die immer einen bestimmten Satz an Daten repräsentieren. Auch einige Konfigurationsdateien, die zu den Geodaten gehören, können dem Datenmodell zugeordnet werden. Die Präsentationen („view“) dienen immer der Benutzerinteraktion, sie zeigen dem Benutzer also die Daten oder Eingabeelemente an. Sie verarbeiten die Daten niemals selbst,


35

sondern zeigen nur vorbereitete Daten an oder geben Benutzereingaben an die Steuerungen weiter. Im GLOWA Volta Geoportal sind die meisten JSP-Seiten Präsentationen, was auch sinnvoll ist, da nur diese über das Internet mit dem Benutzer interagieren können. Abschließend gibt es noch die Steuerungen („controller“), die Eingaben des Benutzers von den Präsentationen entgegennehmen und entsprechend geeignete Funktionen ausführen. Die Steuerungen verwalten zudem die Modelle. Neben dem Datenmodell können alternativ auch die Steuerungen die Anwendungslogik enthalten, was beim GLOWA Volta Geoportal auch so gemacht wurde. Die Steuerungen inklusive der Anwendungslogik sind Javaklassen, die jeweils für eine bestimmte Funktionalität zuständig sind. Hinzu kommen noch einige wenige JSP-Seiten, um die Benutzereingaben von anderen JSP-Seiten entgegen zu nehmen.

verwaltetliefert Daten

Benutzer

zeigt an gibt ein

View (Präsentation):Verzeichnis

•JSP-Seite: index.jsp

•Weitere JSP-Seiten

Controller (Steuerung):

Java-Package•Javaklasse(n)

Datamanager•Javaklasse(n)

(Verwendet eigene Klassen und Funktionen des Datamanagers)

DBJava-objekte

Model (Datenmodell)

JSP-Seite

Beispielkomponente

Abbildung 3.2 Model-View-Controller-Ansatz anhand einer Beispielkomponente

Komponenten im GLOWA Volta Geoportal Im Geoportal gibt es mehrere Möglichkeiten, um Teile auszutauschen oder zu erweitern. Man kann einige Javaklassen gegen gleichnamige austauschen, wenn man das Interface beibehält. Jede Javaklasse enthält in der Regel eine bestimmte Funktionalität, die man so austauschen kann. Dies funktioniert jedoch mit jedem Javaprogramm, welches objektorientiert programmiert ist. Der MVC-Ansatz erleichtert den Austausch bestimmter Programmteile, weil er eine Trennung anhand der Funktionalität vorgibt. Diese Teile können dann separat ausgetauscht werden.

Die Hauptmöglichkeit zum Austauschen oder Erweitern von Funktionalität besteht jedoch in den unterschiedlichen Anzeigekomponenten (Viewer) und den von dort aufgerufenen Downloadkomponenten (Downloader). Alle Metadateneinträge enthalten ein Typelement, in dem festgelegt wird, welcher Typ von Metadaten beschrieben wird. In der Konfigurationsdatei viewertypes.properties des Geoportals kann man festlegen, welche Anzeigekomponente bei welchem Typ verwendet werden soll. Einer der Viewer kann beispielsweise Karten anzeigen und


36

bietet zudem einfache Analysemöglichkeiten für die Karten. Außerdem kann man eine Defaultkomponente für alle anderen Typen festlegen.

Eine Anzeigekomponente besteht mindestens aus einer JSP-Datei, der beim Aufruf immer der Identifikator des gewünschten Metadateneintrages als Parameter übergeben wird, damit der Komponente bekannt gemacht wird, welchen Eintrag sie darstellen soll. Es können, falls erforderlich, zusätzliche JSP-Seiten hinzukommen, die der Übersichtlichkeit halber im gleichen Unterverzeichnis abgelegt werden. Der eigentliche Programmcode wird in Javaklassen eines gleichnamigen Packages ausgelagert. Dies hat den Vorteil, dass so die Programmlogik der Anzeigekomponente unabhängig von der Benutzerschnittstelle (JSP) ausgetauscht werden kann. Es können zudem externe Programme verwendet werden, um deren Funktionen im Geoportal nutzen zu können. Manche Anzeigekomponenten können die Möglichkeit bieten, eine passende Downloadkomponente zu starten, damit der Benutzer die, zu dem Eintrag gehörenden, Daten herunterladen kann. Diese liegen ebenfalls als JSP-Dateien in einem gemeinsamen Unterverzeichnis und nutzen Javaklassen eines gleichnamigen Packages. Die im Geoportal vorhandenen Anzeigekomponenten werden in Kapitel 3.3.5 näher beschrieben, die Downloadkomponenten in Kapitel 3.3.7.

Datamanager(Metadatenverwaltung, Metadatenimport, Suchfunktionen,

Datenverarbeitung, Benutzerverwaltung, ESRI GDB-Zugriff …)

Visu

alis

ieru

ng(K

arte

n, M

etad

aten

, …)

Dow

nloa

d (E

xpor

t)

Portalsoftw

are

Term

inpl

aner

Info

rmat

ions

view

er

…

Abbildung 3.3 Datamanager und verschiedene Arten von Komponenten

Um Projektereignisse zu verwalten, bringt das Geoportal einen eigenen Terminplaner mit, der die Möglichkeiten für eine Kommunikation mit dem Benutzer aufzeigen soll. Er ist ebenfalls als Komponente realisiert und kann leicht durch eine andere Komponente mit erweiterter Funktionalität ersetzt werden, wenn dies erforderlich werden sollte.

Das Geoportal bietet außerdem eine Möglichkeit an, einfache Informationsseiten zu verwalten und dem Benutzer anzuzeigen. Es können so neben den Metadaten noch zusätzliche Informationen bereitgestellt werden. Dieses Angebot ist relativ unabhängig vom restlichen Portal und nur über wenige Links mit diesem verknüpft. In der Hauptkonfigurationsdatei des Portals kann man einen Link auf ein externes Informationsangebot angeben, welches den integrierten

3.3 Praktische Umsetzung des Entwurfs

37

Informationsbetrachter ersetzen kann. Nähere Informationen hierzu findet man in Kapitel 3.3.9. Auf diese Weise kann man das Geoportal einfach erweitern beziehungsweise die mitgelieferte Funktionalität ersetzen.

Da es sich beim Geoportal um ein Webangebot handelt, kann man dem Benutzer über Links beliebige externe oder eigene Webangebote zugänglich machen und den Funktionsumfang des Geoportals so erweitern. Es wird die Möglichkeit geboten, Links auf solche Angebote in der Geoportaldatenbank zu verwalten und in der Menüleiste oder auf der Hauptseite einzublenden. Dies wird im Geoportal als statische Links bezeichnet (Kapitel 3.3.2).

Zum Abschluss soll an dieser Stelle noch die Konfigurierbarkeit der Metadatenbank erwähnt werden, in der man verschiedene Arten von Metadatenelementen hinzufügen oder entfernen kann, ohne dass im Geoportal der Quellcode geändert werden muss. Es handelt sich hierbei zwar nicht um eine Komponente, aber es ist ebenfalls eine Möglichkeit, das Geoportal an spätere Bedürfnisse anzupassen. Mehr hierzu findet man in Kapitel 3.3.3.


Verwendung von Open Source Im späteren Einsatzgebiet in Afrika und im ZEF stehen für die Realisierung des GLOWA Volta Geoportals nur eingeschränkte Mittel zur Verfügung. Hohe Lizenzkosten sollten hier beispielsweise vermieden werden. Es können nur bereits existierende Lizenzen genutzt werden, wie sie für einige Produkte von ESRI zur Verfügung stehen, die vor Ort bereits eingesetzt werden. Die niedrigen Kosten gehörten von Anfang an zu den Anforderungen, die bei der Entwicklung des Geoportals unbedingt beachtet werden mussten.

Unter Open Source Software versteht man zunächst einfach nur solche Software, deren Quellcode offen einsehbar vorliegt. Diese Definition ist jedoch unvollständig, weil wichtige Fragen offen bleiben. Beispielsweise werden keine Angaben über die Lizenzierung oder die Einsatzmöglichkeiten der Software getroffen. Deshalb soll hier die Open Source Definition (OSD) der Open Source Initiative verwendet werden. Den vollständigen Text findet man unter [Osd06]. Neben dem freien Zugang zum Quellcode der Software schreibt die OSD zusätzlich vor, dass die Softwarelizenz dem Benutzer nicht die kostenlose Weitergabe des Quellcodes oder dessen Änderung verbietet. Außerdem darf sie die Anwendungsmöglichkeiten der Software nicht einschränken. Solche Software wird auch als freie Software bezeichnet [Wiki08c]. Das Gegenteil zur Freien/Open Source Software ist proprietäre Software, die unter einer Lizenz steht, die eine Weitergabe oder Veränderung der Software untersagt. Bei kommerzieller Software ist zudem eine Gewinnabsicht des Herstellers gegeben. [UnSc05] In der Regel ist der Quellcode bei proprietärer Software nicht frei zugänglich [Wiki08d].

Der Hauptvorteil von Open Source Software sind die fehlenden Kosten. So kann man die Funktionalität der Software oder auch Bibliotheken verwenden, ohne dass Lizenzgebühren anfallen. Natürlich spart man im Vergleich zu einer selbst programmierten Lösung Entwicklungsaufwand, so dass man bei gleichem Aufwand eine höhere Funktionalität anbieten kann. Ein weiterer Vorteil ist die Anpassbarkeit des Quellcodes an die eigenen Bedürfnisse, wenn dies notwendig sein sollte. Nachteile von Open Source Software sind vor allem der fehlende Support durch den Hersteller und die teilweise schlechte Dokumentation. Bei der Entwicklung des Geoportals überwogen jedoch eindeutig die Vorteile, die man sich alle zunutze machen


38

konnte. Im Anhang 6.1 findet man eine Liste der im Geoportal verwendeten Software, in der gekennzeichnet ist, ob es sich um Open Source Software handelt.

3.3.1 Sicherheit

Separate Server Bereits von Anfang an war die Sicherheit der Geodaten vor Diebstahl eine Anforderung an die Geoportal-Architektur. Daten, die auf einem Webserver liegen, können bei einem Einbruch aus dem Internet von diesem Webserver entwendet werden.

Für die Architektur des Geoportals wurde entschieden, dass die Daten zudem auf einem separaten Datenserver gespeichert werden sollen, der unabhängig vom eigentlichen Webserver läuft. Auf diesem werden alle Daten in entsprechenden Datenbanken und im Dateisystem gespeichert. Der Datenserver ist nicht direkt aus dem Internet zu erreichen, so dass er keinen direkten Angriffen ausgesetzt ist. Eine Hardware-Firewall im zuständigen Rechenzentrum soll ihn nach außen hin komplett abschirmen, so dass der Server nur im Intranet erreichbar ist. Außerdem kann man auf dem Server nicht nur Daten ablegen, die vom Geoportal aus verfügbar sein sollen, sondern auch interne Projektdaten oder die Benutzerverzeichnisse im lokalen Netzwerk. Diese Daten wären nur für den Zugriff über das Intranet oder per SSH/SCP freigegeben.

Der Webserver, auf dem die eigentliche Geoportal-Software läuft, ist hingegen direkt aus dem Internet zu erreichen, um die Dienste des Geoportals anbieten zu können. Aber auch hier lässt die Firewall nur die unbedingt benötigten Ports offen, um den Webserver zu schützen. Der Webserver benötigt jedoch lesenden Zugriff auf den Datenserver, da das Geoportal dessen Daten für seine Darstellung unbedingt benötigt. Auch aus diesem Grund sollten auch auf dem Datenserver nur benötigte Dienste aktiv sein und es sollte nur lesender Zugriff auf die unbedingt benötigten Verzeichnisse und Daten gewährt werden. Dies gilt sowohl für den Dateizugriff vom Webserver oder aus dem Intranet über das SMB-Protokoll, als auch für den Datenbankzugriff über JDBC.

Servervirtualisierung und Betriebssysteme Dem GLOWA Volta Projekt steht jedoch nur ein Server zur Verfügung. Eine zusätzliche Neuanschaffung ist vor allem aus Gründen des Umweltschutzes (doppelter Stromverbrauch) und der doppelten Betriebskosten nicht erwünscht. Als Alternative wurde die Verwendung von Virtualisierung beschlossen [Wiki07d]. Als Software kommt hierfür die kostenlos verfügbare VMware Server Software zum Einsatz ([Vmwa07]), die auf dem Server innerhalb einer Virtuellen Maschine (VM) einen neuen Rechner bereitstellt. Dieser wird gegenüber seinem Wirtssystem oder anderen VMs hinreichend abgeschottet. Da das Geoportal voraussichtlich kein sehr stark frequentiertes System sein wird, ist die Leistungseinbuße durch die Virtualisierung vertretbar.

Als Wirtssystem wird GNU/Linux zum Einsatz kommen, welches kostengünstig und im Servereinsatz erprobt ist. Dieses System wird neben dem Virtualisierungsserver auch die Funktionen des Datenservers übernehmen, da hier auch das Datenbanksystem PostgreSQL und alle Daten untergebracht sind. In der Planungsphase war sogar der Einsatz zweier verschiedener Datenbanksysteme (PostgreSQL und Oracle 10g) geplant, weil M³Cat keine PostgreSQL-Datenbanken verwenden kann. Um den Dateizugriff aus dem Intranet und von dem Webserver aus zu ermöglichen, wird ebenfalls ein Samba-Serverdienst laufen. Alle diese Dienste benötigen


39

mehr Systemressourcen als ein reiner Webserver, so dass sie nicht in einer virtuellen Umgebung laufen sollten.

Innerhalb der VM wird ein Windows Betriebssystem verwendet. In der Planungsphase sollte die webbasierte Software M³Cat zur Verwaltung der Metadaten zum Einsatz kommen, was Microsofts Internet Information Server (IIS), und somit einen Windows Server, zwingend vorausgesetzt hätte. Diese Lösung wurde jedoch nachträglich verworfen. So kann nun sowohl der IIS, als auch der kostenlose Apache-Webserver, zum Einsatz kommen. Man kann jedoch trotzdem von der vereinfachten Installation und Konfiguration einiger Software unter Windows profitieren. Eine Adaption der Software auf Linux ist möglich, da alle verwendeten Programme sowohl für Linux, als auch Windows, vorliegen. Dies kann notwendig werden, um später die Lizenzkosten für Windows einzusparen, wenn im Einsatzgebiet in Afrika keine entsprechenden Lizenzen verfügbar sind. Die Verwendung der ArcGIS Engine Runtime unter Linux ist jedoch ungetestet.

Beim Zugriff aus dem Internet soll für die Virtualisierungslösung mit einem Server das Gleiche gelten, wie für die beiden geplanten, separaten Server. Der vorhandene Server benötigt hierfür zwei externe Netzwerkkarten, wobei eine an das Intranet und die andere an das Internet angeschlossen ist. Die Karte am Internet wird vom Wirtssystem (Datenserver) und vom Webserver in der Virtuellen Maschine gemeinsam verwendet. Jeder Server bekommt jedoch eine eigene IP-Adresse, so kann der Rechner nach außen hin agieren, wie zwei verschiedene Server.

Datensicherheit Der Zugriff auf den Datenserver über das Internet ist aus Sicherheitsgründen nur über SSH möglich. Zwischen dem Wirtssystem und der VM können Daten über eine interne virtuelle Netzwerkkarte ausgetauscht werden, die von dem Virtualisierungsdienst zur Verfügung gestellt wird und extern nicht zugreifbar ist. Der Server wird innerhalb einer Demilitarized Zone (DMZ) stehen. Hierbei ermöglicht die Hardware-Firewall des Rechenzentrums den Zugriff aus dem Internet auf die Netzwerkkarte des Webservers, gleichzeitig wird der Zugriff auf die zweite Netzwerkkarte des Datenservers nur aus dem Intranet ermöglicht. Aus dem Internet ist der Datenserver über die erste Netzwerkkarte, die er sich mit dem Webserver teilt, nur via SSH erreichbar. Eine Software-Firewall auf dem Datenserver beschränkt den Zugriff auf die virtuelle Netzwerkkarte. Dies erschwert Angriffe aus dem Internet auf das System.

Fehlersicherheit Um das Speichern von großen Datenmengen zu ermöglichen, ist ein RAID (Redundant Array of Independent Disks) aus mehreren Festplatten an den Datenserver angeschlossen. Je nach Konfiguration des RAIDs kann man nicht nur einen erhöhten Speicherplatz erreichen, sondern zusätzlich noch eine erhöhte Ausfallsicherheit gegenüber der Verwendung einer einzelnen Festplatte, was für den Datenserver sinnvoll ist. Hierfür werden die Daten automatisch über mehrere Festplatten verteilt, eine Festplatte jedoch enthält die sogenannten Paritätsinformationen, aus denen beim Ausfall einer Festplatte die verlorenen Daten wiederhergestellt werden können, nachdem die defekte Festplatte ersetzt wurde. Zusätzlich kann man eine Festplatte als Hot-Spare deklarieren, diese Festplatte dient dann als Reserve und wird automatisch aktiviert, wenn eine der anderen Festplatten ausfällt.

Derzeit wird das RAID zudem noch als provisorische Backupmöglichkeit eingesetzt. Hierfür werden gleich viele Festplatten zu zwei verschiedenen Verbünden zusammengeschlossen. Der


40

erste wird zum eigentlichen Speichern der Daten verwendet und der andere durch automatisches Umkopieren als Backupmedium. Dies ist jedoch kein vollwertiges Backup, da beim versehentlichen Löschen der Daten diese Änderung automatisch auf das Backup übertragen wird. Außerdem ist das Backup nicht räumlich von den Originaldaten getrennt, so dass einem schwerwiegenden Ausfall (z.B. durch ein Feuer) trotzdem alle Daten vernichtet wären. Hier muss eine zusätzliche Backuplösung beschafft werden.

3.3.2 Portalsoftware und Datamanager Sämtliche Software des Geoportals besteht entweder aus Javaklassen oder JSP-Dateien. In den JSP-Dateien wird in der Regel eine Ausgabe an den Benutzer beschrieben oder eine Eingabe des Benutzers entgegengenommen. In den Javaklassen wird die eigentliche Funktionalität beschrieben, die aus den JSP-Webseiten heraus aufgerufen werden kann. Es wäre ebenfalls möglich, die gesamte Funktionalität direkt in JSP-Dateien zu beschreiben, jedoch verliert man dann an Übersichtlichkeit und Wiederverwendbarkeit des Codes. Auch die Wartung und Fehlersuche im Code würde erschwert. Die JSP-Dateien benötigen Apache Tomcat als Anwendungsserver. Auch die Javaklassen werden über Tomcat ausgeführt. Mehr hierzu ist in Kapitel 2.3 zu finden.

Der zentrale Bestandteil des Geoportals ist der Datamanager. Dieser verwaltet sämtliche Daten des Portals und macht sie dem Benutzer gegebenenfalls verfügbar. Die Aufgaben des Datamanagers sind die Folgenden:

1. Vorbereiten aller Informationen für das Webinterface des Portals,

2. Datenaustausch zwischen dem Datenserver und dem Webserver,

3. Verwaltung von Benutzerdaten und Zugriffsrechten,

4. Erstellung, Bearbeitung, Zugriff und Suche sämtlicher Metadaten,

5. Zugriff auf ESRIs Personal und File Geodatabases,

6. Zugriff auf externe Schnittstellen und Daten (Beispiel: Parsen von GetCapabilities bei WMS).

Der Datamanager besteht aus Javaklassen und läuft gemeinsam mit den in JSP geschriebenen Webinterface-Seiten auf dem Webserver unter Tomcat. Der Datamanager und die JSP-Seiten sind miteinander verbunden und ergeben gemeinsam die eigentliche Portalsoftware.

Die Portalsoftware kann durch zusätzliche Komponenten erweitert werden, die in den jeweils zugehörigen Kapiteln beschrieben werden. Eine solche Komponente besteht ebenfalls aus JSP-Dateien für die Benutzerinteraktion und aus Javaklassen für die Implementierung der Funktionalität. Alle Komponenten können die Funktionalität des Datamanagers nutzen und sind über den Datamanager mit der Portalsoftware verbunden. Im Folgenden werden einige Funktionen der Portalsoftware beschrieben. Weitere folgen in den nachfolgenden Kapiteln, wenn das entsprechende Thema behandelt wird.

Webinterface Das Webinterface ist die primäre Zugriffsmöglichkeit eines jeden Benutzers auf das Geoportal. Es besteht aus mehreren dynamischen Webseiten, die jeweils eine bestimmte Funktion erfüllen. Um das serverseitige dynamische Erzeugen der Webseiten zu ermöglichen, sind sie in JSP geschrieben. Die Wahl fiel auf JSP und nicht auf eine andere Webbeschreibungssprache, wie zum


41

Beispiel PHP oder Python, da mit JSP ein einfaches Einbinden des in Java geschriebenen Datamanagers möglich war und man so den vollständigen Funktionsumfang von Java nutzen konnte. Auch die ArcGIS Engine Runtime konnte somit verwendet werden.

Jede Seite des Webinterfaces ist gleich aufgebaut. Auf der linken Seite findet man die Menüleiste, die den Zugriff auf verschiedene Funktionen des Geoportals ermöglicht. Rechts daneben steht ein Hilfetext, um die Funktionen der aktuellen Seite zu erläutern. Auf der rechten Seite steht der eigentliche Inhalt der jeweiligen Seite, der stark von der jeweiligen Funktion abhängt.

Abbildung 3.4 Hauptseite des GLOWA Volta Geoportals

Der Hilfetext wird als externe HTML-Seite eingebunden, damit man den Text einfacher editieren kann. Auch die Menüleiste und andere regelmäßig vorkommende Codezeilen wurden in externe Dateien ausgelagert, die in die jeweiligen Seiten eingebunden werden können. Hier wird redundanter Code vermieden.

Datenvorbereitung und Datenreduktion Wie bereits erläutert, sind sämtliche Daten auf dem Datenserver gespeichert, die Portalsoftware läuft jedoch auf dem Webserver. Wenn ein Benutzer über das Internet auf die Daten zugreifen möchte, dann müssen die Daten zunächst vom Datenserver auf den Webserver übertragen werden. Erst von dort sind sie im Internet verfügbar.

Es gibt auf dem Webserver zwei verschiedene Verzeichnisse für Daten. Das erste ist vom Internet aus zugreifbar. Hier müssen alle Daten abgelegt werden, auf die ein Zugriff aus dem Internet erforderlich ist. Neben allen Dateien, die der Benutzer herunterladen kann, sind dies auch Konfigurationsdateien, welche die Anzeigekomponente für Karten benötigt. Das zweite Verzeichnis ist nicht aus dem Internet zugreifbar. Hier liegen die Geodaten, die nur für die


42

Visualisierung benötigt werden und die nicht jedermann zugänglich seien sollen. Der Einfachheit halber heißen die beiden Verzeichnisse visible und hidden.

Es gibt mehrere Möglichkeiten, wie ein Benutzer Daten zugreifen kann. Wenn es sich um Karten handelt, kann der Benutzer diese im Browser visualisiert bekommen. Hierfür ist eine Anzeigekomponente zuständig. Diese benötigt jedoch die eigentlichen Geodaten und zusätzliche Konfigurationsdaten für ihre Arbeit, die in bestimmten Verzeichnissen vorliegen müssen. Der Datamanager kann die benötigten Daten vom Datenserver kopieren. Wenn die Geodaten in einer ESRI Geodatenbank abgelegt sind, kann der Datamanager den Export der Daten aus der Geodatenbank über eine spezielle Programmierschnittstelle von ESRI (ArcObjects API) veranlassen, die über die ArcGIS Engine Runtime zur Verfügung gestellt wird. Die Anzeigekomponente muss diese Funktionalitäten des Datamanagers aufrufen, falls sie benötigt werden.

Wenn der Benutzer die Karten nicht nur betrachten, sondern auch herunterladen möchte, kann er eine Downloadkomponente aufrufen und dort auswählen, welche Daten er anfordern möchte. Eine Karte kann aus mehreren Ebenen bestehen, deren Geodaten in separaten Dateien abgelegt sind. Welche der Dateien zu welcher Ebene gehören, muss der Datamanager, auf Anfrage der Downloadkomponente, aus der Konfigurationsdatei des Mapservers auslesen (siehe Kapitel 3.3.5), da nur dort die entsprechende Zuordnung gespeichert ist. Die Dateien werden anschließend als komprimiertes Archiv zum Download bereitgestellt.

Wenn die Daten keine Karten sind, ist der Vorgang weniger kompliziert. Eine Visualisierung als Karte steht hier nicht zur Verfügung. Die Daten müssen nur auf den Webserver kopiert und eventuell in ein ZIP-Archiv eingepackt werden, wenn der Benutzer sie herunterladen möchte. Diese Aufgaben kann der Datamanager übernehmen, wenn sie von der entsprechenden Downloadkomponente aufgerufen werden.

Um die Datenmengen bei einem Download zu reduzieren und Bandbreite zu sparen, nimmt der Datamanager die bereits beschriebenen Maßnahmen vor. Er komprimiert alle Daten verlustfrei mit dem verbreiteten ZIP-Format, wenn diese für den Download vorbereitet werden. Außerdem dient auch die Auswahl der herunter zu ladenden Ebenen der Reduktion von Datenmengen beim Download. Hier muss der Benutzer nicht sämtliche Daten herunterladen, wenn er nur an einem Teil interessiert ist.

Aufräumen Durch den Transfer von Daten vom Datenserver in temporäre Verzeichnisse auf den Webserver fallen regelmäßig Daten an, die nicht mehr benötigt werden, wenn der jeweilige Benutzer das Portal verlassen hat. Der Datamanager bietet hierfür die Funktion an, alle temporären Verzeichnisse auf Wunsch eines Administrators hin zu leeren. Ebenfalls denkbar ist ein zusätzliches, zeitgesteuertes Skript, das alte Dateien regelmäßig löscht, beispielsweise alle Dateien in den temporären Verzeichnissen, die älter sind als eine angegebene Anzahl Tage.

Dateien, die dem Benutzer zum Download angeboten werden, werden in speziellen Unterverzeichnissen des sichtbaren Verzeichnisses abgelegt und beim Abmelden des Benutzers automatisch vom Datamanager gelöscht.

Neben Dateien kann auch in der Konfigurationsdatenbank von Mapbender aufgeräumt werden, um alte, nicht mehr benötigte Einträge zu löschen. Auch dies kann von einem Administrator


43

veranlasst werden. Es ist jedoch nicht zwingend erforderlich, da Mechanismen vorgesehen sind, um alte Einträge bei Platzmangel zu überschreiben (siehe Kapitel 3.3.5).

Benutzerrechteverwaltung Nicht jeder Benutzer soll Zugriff auf alle Funktionen des Geoportals haben, so sollten natürlich administrative Aufgaben nicht von jedem Benutzer ausgeführt werden dürfen. Die Hauptaufgabe der Benutzerverwaltung ist jedoch das Beschränken der Downloads oder der Metadatenverwaltung auf bestimmte Personen oder Gruppen. Das reine Betrachten von Metadaten und auch das Betrachten von Karten mit dem MapViewer sollen nach den Anforderungen des ZEF nicht eingeschränkt werden. Im Folgenden werden alle Funktionen aufgelistet, die durch die Benutzerverwaltung beschränkt sind:

• Verwaltung von Benutzern und Gruppen, • Aufräumen temporärer Verzeichnisse und der Mapbender-Datenbank, • Statische Links und Informationsseiten verwalten, • Hinzufügen, Bearbeiten und Löschen von Metadateneinträgen, • Einblenden ungeprüfter Metadateneinträge für bestimmte Benutzer, • Ausblenden interner Metadatenelemente für reguläre Benutzer, • der Terminplaner. Wenn ein Benutzer sich beim Geoportal anmeldet, werden seine Daten in einem speziellen Javaobjekt in seiner aktuellen Sitzung (Session) gespeichert. Alle JSP-Seiten des Portals können auf dieses Objekt zugreifen und können somit die Session einem bestimmten Nutzer zuordnen. Wenn kein Benutzer angemeldet ist, gibt das Objekt als Benutzer- und Gruppenname immer guest zurück. Die Verwendung von Sessions erleichtert zudem den Umgang mit instabilen Internetanbindungen, da sie auch über einen Verbindungsabbruch hinweg bestehen bleiben.

Statische Links Es ist nicht immer sinnvoll, Links auf interne oder externe Webangebote fest in den Quellcode der JSP-Dateien einzuprogrammieren. So ist es zumindest an einigen Stellen notwendig, dass spätere Administratoren Links leicht ändern können, um sie an ihre eigenen Bedürfnisse anpassen zu können.

Das Geoportal bietet zwei Typen von Links an, die sich beide über ein Administrationsmenü verwalten lassen. Da sind zunächst die Links in der Menüleiste im Segment „Links“, die man beispielsweise nutzen kann, um externe oder eigene Webangebote in das Geoportal einzubinden oder um dem Benutzer bestimmte Unterseiten des Geoportals leichter zugänglich zu machen. Man könnte sie nutzen, um einige neu hinzukommende Komponenten mit dem Portal zu verlinken und sie so aufzurufen. Das Gleiche kann man auch mit den Links auf der Hauptseite im Abschnitt „Visual links“ machen. Der einzige Unterschied ist, dass auf der Hauptseite zusätzlich zum einfachen Text noch eine Grafik angezeigt wird. Diese muss man als URL angeben, wenn sie fehlt, wird ein Platzhalter angezeigt. Bei beiden Linktypen ist mindestens ein Name, ein Ziel als URL und der Typ anzugeben. Auch die Reihenfolge kann man festlegen.

Datenbankschema des Portals Die Daten der Benutzerverwaltung und Daten zu den statischen Links werden in einer eigenen PostgreSQL-Datenbank verwaltet. In der gleichen Datenbank werden in separaten Tabellen auch


44

Daten zu Informationsseiten und dem Terminplaner gespeichert, auf die erst im entsprechenden Kapitel 3.3.9 näher eingegangen wird. Das vollständige Datenbankschema des Portals findet man im Anhang 6.4.

Benutzer und Gruppen werden getrennt in den beiden Tabellen portal_users und portal_groups verwaltet. Neben den Benutzer- beziehungsweise Gruppennamen können hier auch noch weitere beschreibende Informationen angegeben werden. Für Benutzer kann man eine E-Mail-Adresse angeben, die vom Terminplaner verwendet wird. Außerdem wird das Passwort des Benutzers gespeichert, welches zur Anmeldung am Geoportal notwendig ist. Aus Sicherheitsgründen wird es nur als MD5-Hashwert abgelegt, so wird verhindert, dass Personen mit Zugriff auf die Datenbank die Passwörter der Benutzer als Klartext auslesen können. Die MD5-Hashfunktion wandelt das Passwort in einen eindeutigen Wert um, dies funktioniert jedoch nicht in umgekehrter Richtung. Das Passwort des Benutzers bleibt so geheim.

***

*

**

PrimärschlüsselFremdschlüsselCheck ConstraintUnique Constraint

* On Delete CascadeReferenz

***

*

**





Abbildung 3.5 Übersicht über Datenbankschema des Portals (ohne Informationsseiten und Terminplaner)

Die Zuordnung der Benutzer zu den jeweiligen Gruppen geschieht mit Hilfe der Tabelle portal_useringroup, die über eine Fremdschlüsselbeziehung mit der Benutzer- und der Gruppentabelle verknüpft ist. Eine „On Delete Cascade“-Anweisung stellt sicher, dass gelöschte Benutzer- oder Gruppeneinträge auch in dieser Tabelle gelöscht werden.

In Java wird ein Benutzer durch eine eigene Klasse repräsentiert, welche auch Angaben über die Gruppen enthält, denen der Benutzer angehört (Klasse User). Die Datenbank und diese Klasse stellen ein Datenmodell dar. Änderungen an der Datenbank oder das Auslesen eines Benutzers aus der Datenbank in das User-Objekt übernimmt eine eigene Klasse (UserGroupMgmt). Sie stellt eine Steuerung dar. Falls erforderlich, werden Benutzereingaben über eine JSP-Seite entgegengenommen, die Teil der Steuerung ist.

Statische Links werden in der Tabelle portal_links verwaltet. Sie enthält alle Angaben, die das entsprechende HTML-Element benötigt, um einen Link zu erzeugen (URL auf das Ziel, Name und Titel). Zusätzlich kann eine URL auf eine Grafik angegeben werden, die auf der Hauptseite des Portals zusammen mit dem Link angezeigt werden soll. Ob der Link auf der Hauptseite oder in der Menüleiste angezeigt wird, wird in der Typspalte festgelegt. In der Spalte für die Anordnung der Links kann über einen Zahlenwert die Reihenfolge der Links festgelegt werden. Links mit niedrigen Werten werden vor solchen mit hohen Werten angezeigt.


45

Auch Links werden im Geoportal durch ein eigenes Objekt repräsentiert, welches Teil eines Datenmodells ist. Die Steuerung ist in diesem Fall die Javaklasse Portal, die jedoch auch noch andere Aufgaben hat. Beim Einfügen oder Löschen von Links werden die Benutzereingaben von einer JSP-Seite entgegengenommen, die ebenfalls Teil der Steuerung ist.

3.3.3 Verwaltung der Metadaten Es gibt verschiedene Möglichkeiten, um in einer unüberschaubaren Menge von Daten einen bestimmten Datensatz zu finden. So kann man die Daten beispielsweise in einer Verzeichnisstruktur ablegen, die anhand bestimmter Themen sortiert ist. Das hat jedoch den Nachteil, dass man an diese Themeneinordnung gebunden ist. Zudem hat man keine weiteren Suchmöglichkeiten.

Es ist also sinnvoll, seine Daten mit festgelegten Informationen zu beschreiben, die dann von den Benutzern durchsucht werden können. Diese beschreibenden Informationen sind die Metadaten. Sie werden üblicherweise in einer Datenbank abgelegt, um den Zugriff auf sie zu erleichtern. An diese Datenbank kann man nun Suchanfragen stellen, die dann als Ergebnis eine Auswahl von Metadatensätzen zurückliefert, die den Suchkriterien entsprechen. Neben beschreibenden Informationen enthalten die Metadaten auch Angaben über den Ort der eigentlichen Daten. Dies kann sowohl eine interne Pfadangabe sein, als auch eine Kontaktinformation über den Besitzer, von dem man die Daten erhalten kann. Eine Metadatenbank kann auch in eine Geodatenbank integriert sein, wie dies beispielsweise bei den Produkten der Firma ESRI der Fall ist. Hier liegen Metadaten und Geodaten in einer gemeinsamen Datenbank. Im GLOWA Volta Geoportal wird jedoch ein anderer Ansatz verfolgt. Hier liegen die Daten an verschiedenen Orten, in einer Verzeichnisstruktur oder in Geodatenbanken auf dem Datenserver, vor. Die Metadatenbank kann die verschiedenen Lageorte berücksichtigen und außerdem auf nicht georeferenzierte Daten verweisen. Sie ermöglicht so die Suche nach allen beschriebenen Daten (georeferenziert und nicht georeferenziert), die Suche nach Objekten innerhalb von Geodaten ist jedoch nicht möglich. Hierfür würde man eine Geodatenbank benötigen.

Die Metadatenbank enthält ein bestimmtes Schema, nach dem die Informationen in ihr geordnet sind. Hier gibt es verschiedene Standards und auch angepasste Eigenentwicklungen, die verwendet werden können. Auch zum Verwalten der Metadatenbank gibt es verschiedene Möglichkeiten. Zunächst kann man vorgefertigte Programme verwenden, die teilweise sogar kostenlos verfügbar sind. Jedoch ist man in diesem Fall an den Funktionsumfang dieses Programms gebunden. Alternativ kann man eine eigene Lösung implementieren, das ist zwar aufwändiger, ermöglicht aber eine Lösung, die an die eigenen Bedürfnisse besser angepasst ist. Außerdem hat man so keine Probleme beim Zugriff auf die Metadaten, die bei externen Programmen nicht immer über eine dokumentierte Schnittstelle zugreifbar sind.

Begriffe Eine Metadatenbank besteht aus beliebig vielen Metadateneinträgen. Jeder Eintrag beschreibt einen bestimmten, zusammengehörenden Satz an Geodaten, einen Dienst oder sonstige Angebote. Das vom Eintrag Beschriebene nennt man die Ressource. Diese Ressourcen müssen nicht unbedingt vom Geoportal selbst bereitgestellt werden, es ist durchaus möglich, nur auf fremde Angebote zu verweisen. Dies kann über Verknüpfungen (Links) oder Kontaktinformationen zu verantwortlichen Personen oder Organisationen geschehen. Jeder Eintrag besteht aus mehreren Elementen, die je nach verwendetem Metadatenstandard in einer


46

bestimmten Reihenfolge vorkommen können. Die Namen, Bedeutung und Anzahl der jeweiligen Elemente werden vom Standard festgelegt. Ebenfalls durch den Standard definiert wird, ob das Element ausgefüllt werden muss („mandatory“) oder ob es optional ist. Um die Metadatenbank zu pflegen, wird ein spezielles Programm zur Metadatenverwaltung benötigt, das jedoch auch ein Bestandteil des Geoportals sein kann.

M³Cat Am ZEF wurde bereits vor dem Start der Entwicklung des Geoportals eine Metadatenverwaltung eingesetzt. Hierbei handelte es sich um das kostenlos verfügbare Programm M³Cat, dessen Name für Multistandard, Multilingual, Metadata Cataloguing Tool steht [Inte07]. Zunächst wurde das Geoportal so entwickelt, dass es M³Cat zur Metadatenverwaltung verwendet, da dies als Anforderung vom ZEF vorgegeben wurde. Diese Anforderung wurde jedoch später wieder verworfen, so dass entschieden werden musste, ob M³Cat weiterhin eingesetzt werden soll. Im Folgenden werden die wichtigsten Vor- und Nachteile von M³Cat aufgelistet und die Entscheidung gegen M³Cat begründet.

+ Unterstützt verschiedene Metadatenstandards, + Flexibel konfigurierbar, + Benutzerverwaltung, + Suche in den Metadaten, − Benötigt Windows und IIS, läuft nicht unter Linux und Apache, − Benötigt mit Microsoft Access oder Oracle ein kostenpflichtiges

Datenbankmanagementsystem, − Angebotene Metadatenstandards sind sehr umfangreich und fordern von den Produzenten

einen hohen Zeitaufwand bei der Eingabe, außerdem sind sie sehr unübersichtlich, − Unzureichende Dokumentation, − Keine Schnittstellen für den externen Zugriff auf die Metadaten. Ein weiterer Vorteil ist, dass M³Cat bereits am ZEF eingesetzt wird. Außerdem kann die vorhandene Funktionalität zur Verwaltung der Metadaten ohne eigenen Programmieraufwand genutzt werden. Die Nachteile überwiegen die Vorteile jedoch bei weitem. Vor allem die ausschließliche Nutzung unter Windows und die Verwendung von kostenpflichtigen Datenbankmanagementsystemen waren bei der Entscheidung gegen M³Cat wichtig. Auf dem Datenserver musste zusätzlich zu PostgreSQL noch Oracle installiert werden, was sehr ineffizient war. Außerdem musste der Webserver auf jeden Fall unter Windows betrieben werden, da nur dort der IIS verfügbar ist. Dieser wiederum wird für M³Cat benötigt, da es in ASP programmiert ist. Versuche mit Webservern, die ASP unter Linux anzeigen können, verliefen nicht zufriedenstellend. Entscheidend war außerdem, dass M³Cat keine Schnittstellen für den Zugriff auf seine Metadaten bietet. Das Geoportal musste direkt lesend auf die Oracle-Datenbank zugreifen, um die Metadaten anzeigen zu können. Das Datenbankschema war jedoch undokumentiert, so dass es mühsam durch Ausprobieren erkundet werden musste. Die gewonnenen Erkenntnisse waren trotzdem nicht ausreichend, um den vollständigen Funktionsumfang aus dem Geoportal heraus nutzen zu können. Eine Anfrage bei der Herstellerfirma nach Informationen über das Schema wurde zwar beantwortet, die Informationen waren jedoch unzureichend und bei der kanadischen Firma nur auf Französisch verfügbar.


47

Gemeinsam mit Mitarbeitern vom ZEF wurde entschieden, dass die bestehende Metadatenverwaltung ersetzt werden muss. Somit konnte auch M³Cat ersetzt werden. Dies hatte aus Sicht des ZEF vor allem damit zu tun, dass der bis dahin verwendete Metadatenstandard FGDC zu umfangreich war. FGDC bietet sehr viele Metadatenelemente an, von denen eine große Anzahl verpflichtend ist. Die Datenproduzenten mussten also für jeden Datensatz sehr viele Informationen ausfüllen, was erfahrungsgemäß nicht gemacht wurde. Also wurde entschieden, FGDC durch den einfacheren Dublin Core Standard zu ersetzen, der deutlich weniger Elemente umfasst. Der Standard wird jedoch von M³Cat nicht unterstützt, so dass eine eigene Lösung notwendig und sinnvoll wurde.

Eigene Metadatenverwaltung Der Dublin Core Standard, der im Geoportal verwendet wird, stammt von der Dublin Core Metadata Initiative (DCMI, [Dcmi08]). Er umfasst nur 15 sogenannte Kernelemente („core elements“), die man jedoch noch präzisieren kann („element refinements“). Außerdem kann man eigene Felder zu dem Standard hinzufügen oder beliebige Elemente – sogar Kernelemente – weglassen. Jedes Element darf beliebig oft vorkommen, die Reihenfolge der Elemente ist ebenfalls beliebig. Der Wert eines Elements darf eine beliebige Länge haben und hat keinen vorgegebenen Datentyp. Der Standard bietet somit eine hohe Flexibilität und kann genau an die Bedürfnisse der jeweiligen Benutzer angepasst werden. Für das Geoportal kann man so die Anzahl der verwendeten Elemente auf ein notwendiges Minimum reduzieren, so dass die Datenproduzenten diese mit größerer Wahrscheinlichkeit auch ausfüllen werden. Die 15 Kernelemente werden alle im Geoportal verwendet, einige wurden jedoch präzisiert, zudem wurden neue Elemente hinzugefügt. Die folgende Tabelle gibt einen Überblick über alle im Geoportal verwendeten Elemente und eventuelle Beschränkungen abweichend zum Standard. Element Präzisiert Beschreibung Beschränkung identifier - Identifiziert einen

Metadateneintrag eindeutig über eine URN.

Nur URNs nach festgelegtem Muster. Nur ein Element pro Eintrag. Maximal 255 Zeichen.

title - Titel des Eintrags. Maximal 255 Zeichen. description Beschreibender Text zum Eintrag. - creator - Urheber der Ressource. Maximal 255 Zeichen. publisher - Herausgeber der Ressource (hat

die Daten veröffentlicht). Maximal 255 Zeichen.

contributor - Weitere Beteiligte bei der Erstellung der Ressource.

Maximal 255 Zeichen.

subject - Themen, denen die Ressourcen zugeordnet werden können.

Vorgegebene Werte oder freie Eingabe. Maximal 255 Zeichen.

date - Datum an dem der Eintrag in die Datenbank eingefügt wurde.

Muss ein Datum sein. Empfohlen: maximal 10 Zeichen, Format YYYY-MM-TT. Nur ein Element pro Eintrag (mehrere sind technisch möglich).

access-information

(eigenes Element)

Angaben über Zugriffsmöglichkeiten auf die Ressource (z.B. Download).


type - Typ der Daten (z.B. WebMapService).

Vorgegebene Werte. Nur ein Element pro Eintrag (mehrere sind technisch möglich). Maximal 255 Zeichen.

format - Format der Daten. Vorgegebene Werte. Maximal 255 Zeichen.


48

qualitycontrol (eigenes Element)

Angaben über Qualität der Daten. Maximal 255 Zeichen.

temporal-coverage

coverage Daten aus diesem Zeitraum / aus dieser Zeit.


spatial-coverage

coverage Daten über diesen Ort / Raum. Maximal 255 Zeichen.

language - Daten in dieser Sprache. Angabe der Sprache nach ISO 3166. Maximal 255 Zeichen.

source - Verweis auf Einträge / Daten / Dokumente von denen dieser Eintrag abhängt (Quelle).

Maximal 255 Zeichen. Empfohlen: bei Verweisen auf Einträge in dieser Metadatenbank URN verwenden.

relation - Verweis auf abhängige Einträge / Ressourcen.

Maximal 255 Zeichen. Empfohlen: bei Verweisen auf Einträge in dieser Metadatenbank URN verwenden.

coordinate-system

(eigenes Element)

Angaben zum verwendeten Koordinatensystem.

Vorgegebene Werte. Maximal 255 Zeichen.

url* (eigenes Element)

Verweise auf verknüpfte Daten / Konfigurationsdateien auf dem Datenserver oder Links auf externe Webseiten.

URLs, die mit reldata, relmapfile, relmapdata, relmapgdb, relgdb, googlemaps, map, wms, http, https oder ftp beginnen (gefolgt von :// und dem Wert der URL). Mehr zu den URLs: siehe Tabelle im Anhang 6.10. Maximal 255 Zeichen.

accessrights* rights Beschränkung des Downloads auf hier angegebene Benutzer und Gruppen.

Muss entweder in der Form u:Benutzername oder g:Gruppenname oder all sein. Benutzer- und Gruppennamen aus der Geoportal Benutzerdatenbank. Maximal 255 Zeichen.

attribute (eigenes Element)

Angaben zu Attributen von strukturierten / tabellarischen Daten (pro Attribut ein Element).


si_type (eigenes Element)

Typangabe bei verknüpften Satellitenbildern.

Vorgegebene Werte. Nur ein Element pro Eintrag (mehrere sind technisch möglich). Maximal 255 Zeichen.

si_acquisition-date

(eigenes Element)

Erfassungszeit bei verknüpften Satellitenbildern.

Nur ein Element pro Eintrag (mehrere sind technisch möglich). Maximal 255 Zeichen.

box (northlimit, southlimit, eastlimit, westlimit, unit)

(kein Element, syntax encoding scheme)

Koordinaten („bounding box“) zu den Daten.

Nur ein Element pro Eintrag. Unit muss „decimal degrees“ oder „meters“ sein. North- und Southlimit: zw. -90 und 90 (dd) oder 99999999.999 und 0 (m), max. 8 Vor- u. 7 Nachkommastellen. East- und Westlimit: zw. -180 u. 180 (dd) oder 9999999.999 und 0 (m), max. 7 Vor- und 7 Nachkommastellen.

(* Interne Metadatenelemente; werden nicht allen Benutzern angezeigt.)

Neben der guten Anpassung an die Bedürfnisse der Benutzer bietet eine eigene Metadatenverwaltung nach dem Dublin Core Standard den Vorteil, dass sie sich gut in das Portal integriert. So kann man die Benutzerverwaltung des Portals auch für die Beschränkung der Metadatenverwaltung verwenden. Da man das Datenbankschema für die Metadatenbank selbst entwirft, ist es genau bekannt, und es treten keine Probleme mit fehlenden oder schlecht


49

dokumentierten Zugriffsschnittstellen auf, wie es bei M³Cat der Fall war. Ein Nachteil ist sicherlich der erhöhte Programmieraufwand, weil man viele Funktionen selbst implementieren muss, die vorher von M³Cat bereitgestellt wurden.

Die Metadatenverwaltung des GLOWA Volta Geoportals funktioniert wie folgt. Man muss unterscheiden zwischen dem Hinzufügen neuer Metadateneinträge, dem Bearbeiten oder Aktualisieren bestehender Einträge und dem Löschen von Einträgen.

Beim Hinzufügen neuer Einträge muss zunächst ein eindeutiger Uniform Ressource Name (URN) generiert werden. Dies geschieht mit Hilfe des am ZEF in Javascript entwickelten URN-Generators, der in das Geoportal eingepasst wurde. Mit der URN wird ein Eintrag eindeutig identifiziert, außerdem gibt die URN bereits einen kurzen Überblick über die beschriebene Ressource. Das Format wurde gemeinsam mit den zuständigen ZEF-Mitarbeitern entworfen. Jede URN im Geoportal ist wie folgt aufgebaut:

urn:x-gvp:<uid>:<resource-type>-<subtype>.<short-title>.v<version>.<format>.<medium>

Das Präfix urn: ist bei jeder URN gleich, x-gvp: bezeichnet den Namensraum der URN, um verschiedene URNs gegeneinander abzugrenzen. Das x steht für experimentell, was bedeutet, dass die URN nicht offiziell registriert ist. Als Namensraum wurde hier gvp gewählt, was für GLOWA Volta Projekt steht. Es folgt der Teil der URN, der für den angegebenen Namensraum spezifisch ist. Hier wird zunächst eine Nummer angegeben, die den Benutzer eindeutig identifiziert (<uid>). Sie soll verhindern, dass zwei Benutzer versehentlich die gleiche URN generieren, da dieser Vorgang auch ohne Internet- und somit Datenbankverbindung geschehen kann. Außerdem kann eine URN so eindeutig ihrem Erzeuger zugeordnet werden. Nach dem Doppelpunkt folgt eine Angabe über den Typ der beschriebenen Ressource (<resource-type>), also beispielsweise, ob es sich um einen Datensatz oder ein Dokument handelt. Durch einen optionalen Untertyp kann noch weiter spezifiziert werden (<subtype>). Diese Angaben kann der Benutzer beim Erzeugen der URN aus vorgegebenen Werten auswählen. Ein Kurztitel gibt einen schnellen Überblick über die beschriebene Ressource (<short-title>), er sollte Angaben zu Thema, Ort und Zeit enthalten. Um verschiedene Versionen der gleichen Daten beschreiben zu können, kann der Benutzer eine Versionsnummer angeben (<version>). Abschließend steht ein Kürzel, welches das (Datei-)Format beschreibt, in dem die Daten vorliegen (<format>), sowie ein Kürzel, welches das Medium beschreibt, auf dem die Daten gespeichert sind (<medium>). Auch für diese Werte gibt es eine Auswahlliste, aus der der Benutzer wählen kann. In keinem Segment darf ein Punkt oder Doppelpunkt vorkommen, da diese als Trennzeichen verwendet werden.

Nachdem die URN erzeugt wurde, müssen die Elemente des Metadateneintrags mit Werten gefüllt werden. Die URN wird automatisch in das Element identifier eingetragen. Das Geoportal bietet für das Ausfüllen der Elemente einen eigenen Editor. Dieser benötigt jedoch einen Internetzugriff auf die Seiten des Portals, da es sich um ein Webformular handelt. Es kann aber sein, dass die Datenproduzenten zwar ihre Daten beschreiben möchten, ihnen aber momentan kein Internetzugang zur Verfügung steht. Dies kann beispielsweise bei einem Feldeinsatz der Fall sein, bei dem Daten erhoben werden. Hierfür wird von einem Mitarbeiter des ZEF ein Java-Programm entwickelt, welches ebenfalls URNs generieren kann und einen Metadateneditor enthält. Das Programm kann die erzeugten Metadateneinträge in Form von XML-Dateien speichern, die dann auf einer Seite des Geoportals hochgeladen und eingelesen werden können.


50

Mehr zu diesem Vorgang und dem verwendeten XML-Format findet man in Abschnitt „Eigenes XML-Format“.

Wenn ein Benutzer existierende Metadateneinträge bearbeiten möchte, kann er sie auswählen und in den Online-Metadateneditor laden. Hier kann er Einträge verändern und schließlich den alten Eintrag überschreiben. Auch offline ist eine solche Funktionalität möglich. Wenn der Benutzer einen Metadateneintrag erzeugt und als XML-Datei hoch lädt, der die gleiche URN wie ein bereits existierender Eintrag hat, wird der alte Eintrag ebenfalls überschrieben. Um sicherzustellen, dass nur alte Einträge überschrieben werden, enthalten die Metadatenbank und die XML-Dateien einen Zeitstempel für jeden Eintrag.

Das Löschen von existierenden Metadateneinträgen ist nur online möglich, weil hierfür eine Verbindung zur Metadatenbank erforderlich ist. Gerade diese Funktion macht aber deutlich, dass Schutzmaßnamen gegen Vandalismus getroffen werden müssen. Nicht jeder Benutzer soll Metadateneinträge erzeugen, bearbeiten und löschen dürfen. Das Geoportal verwendet hierfür die integrierte Benutzerverwaltung. Es gibt zwei verschiedene Gruppen, denen Benutzer angehören können, um bestimmte Rechte für den Zugriff auf die Metadatenbank zu erhalten. Benutzer, die keiner der beiden Gruppen angehören, können Metadateneinträge nur über die Viewer betrachten (siehe Kapitel 3.3.5).

Gruppe: metadataadmins Gruppe: metadatauploader

• Hinzufügen, Editieren, Löschen und Hochladen beliebiger Metadateneinträge,

• Ändern des Status („checked/unchecked“).

• Hinzufügen, Editieren, Löschen und Hochladen ihrer eigenen Metadateneinträge (also von Einträgen, die die UID des Benutzers in der URN stehen haben).

Der Status ist ein boolescher Wert, der für jeden Metadateneintrag angibt, ob er bereits von einem Administrator auf Richtigkeit geprüft wurde. Nur geprüfte Einträge werden den normalen Benutzern angezeigt und durchsucht. So kann eine hohe Qualität der Metadatenbank sichergestellt werden, obwohl möglicherweise sehr viele Personen das Recht haben, eigene Einträge hinzuzufügen. Diese Funktion war eine Anforderung des ZEF.

Den Mitgliedern der beiden Metadatengruppen werden zudem auch die Metadatenelemente angezeigt, die in der Tabelle oben als interne Elemente gekennzeichnet sind. Diese Elemente beinhalten Informationen, die direkt vom Geoportal ausgewertet werden und die dem normalen Benutzer nicht direkt angezeigt werden müssen. Derzeit sind dies nur die Elemente zur Beschränkung des Downloads auf bestimmte Benutzer und die Elemente für Verknüpfungen.

Schema der Metadatenbank Das Schema der Metadatenbank wurde entworfen, um den Ansprüchen des Dublin Core Standards zu genügen. So sollen alle Elemente beliebig oft und in beliebiger Reihenfolge vorkommen können. Auch Angaben über präzisierte und eigene, neue Elemente sollten gespeichert werden können, so dass diese Information nicht verloren gehen und in zukünftigen Funktionen verwendet werden können. Da zu diesem Zeitpunkt noch nicht alle Anforderungen der späteren Nutzer in Afrika und des ZEF bekannt sind, muss das Schema flexibel sein. Es ist vor allem wichtig, dass man später noch neue Elemente hinzufügen kann, wenn dies erforderlich werden sollte. Das vollständige Schema der Metadatenbank findet man im Anhang 6.7.


51

Zunächst wird für jeden neuen Datensatz ein Eintrag in der Tabelle md_datasets vorgenommen. Über den Primärschlüssel auf dem Identifikator wird sichergestellt, dass es jeden Datensatz nur einmal geben kann. Außerdem werden der bereits erwähnte Zeitstempel und der ebenfalls bereits bekannte Status hier gespeichert.



** *

*PrimärschlüsselFremdschlüsselCheck ConstraintUnique Constraint




** *

*

Abbildung 3.6 Übersicht über das Schema der Metadatenbank

Damit alle Elemente beliebig oft vorkommen können, werden ihre Werte in der Tabelle md_dc_values gespeichert. Hier werden für jedes Element der Name und der Wert abgelegt, außerdem wird ein Eintrag über eine Fremdschlüsselbeziehung einem bestimmten Datensatz zugeordnet. Wenn ein Name pro Eintrag mehrfach vorkommt, kommt auch das Element mehrfach vor, das in diesem Eintrag gespeichert wird. Werte werden Platz sparend als VARCHAR, mit der Maximallänge von 255 Zeichen, abgelegt, was für normale Elemente ausreichend ist. Abgesehen von der Maximallänge kann so beliebiger Inhalt in dem Element abgelegt werden, wie im Dublin Core Standard vorgesehen. Da die Beschreibungstexte auch aus mehr als 255 Zeichen bestehen können, wurden sie in die separate Tabelle md_dc_description ausgelagert. Die Verwendung dieser Tabelle entspricht der von md_dc_values, allerdings muss bei dieser spezialisierten Tabelle kein Elementname gespeichert werden, weil sie nur die Elemente des Typs description enthält. Die Werte werden als Datentyp TEXT gespeichert, so dass sie eine beliebige Länge haben können.

Die geografische Lage der beschriebenen Ressource kann mit Hilfe einer sogenannten Bounding Box beschrieben werden. Die Box repräsentiert ein gedachtes Rechteck, das auf der Erde aufgespannt wird. In diesem liegt dann der beschriebene Ort. Um so ein Rechteck aufzuspannen, benötigt man vier Begrenzungen (Nordgrenze, Südgrenze, Ostgrenze und Westgrenze) sowie eine Angabe über die Einheit in der diese Grenzen gespeichert sind. Im Geoportal sollen in der Regel Dezimalgrade verwendet werden, aber auch Angaben in Metern sind möglich. Diese werden allerdings voraussichtlich nicht verwendet. Da dieses Element sich aus mehr als einem Wert zusammensetzt und diese Werte einen anderen Datentyp als VARCHAR haben, muss man die Box ebenfalls in einer separaten Tabelle speichern. Im Geoportal ist dies die Tabelle md_dc_box, die auch wieder über eine Fremdschlüsselbeziehung mit md_datasets verknüpft ist. Eine UNIQUE-Constraint stellt sicher, dass ein Eintrag nur eine Box enthalten kann, mehrere sind nicht notwendig. Verschiedene CHECK-Constraints stellen sicher, dass die Werte der Boxen in einem gültigen Bereich liegen.

Nun fehlt nur noch eine Möglichkeit, das Schema nachträglich um Elemente zu erweitern oder Elemente wegfallen zu lassen, um es an später bekannt werdende Anforderungen anzupassen.


52

Die Tabelle md_dc_values kann bereits beliebige Elementnamen mit den zugehörigen Werten aufnehmen, so dass man sie für diesen Zweck nutzen kann. Das Geoportal enthält jedoch verschiedene Benutzeroberflächen, die dazu dienen, Metadaten anzuzeigen, zu erstellen oder zu editieren. Sie alle müssten ebenfalls an neue Elemente angepasst werden. Dies geschieht im Geoportal jedoch automatisch. Hierfür werden Informationen über alle Elemente, deren Werte in md_dc_values gespeichert werden, in der Tabelle md_elements hinterlegt. Neben dem internen Elementnamen für eine eindeutige Zuordnung zu den jeweiligen Werten, wird auch ein Etikett angegeben, dessen Inhalt dem Benutzer anstatt des Namens angezeigt wird. Dies ist sinnvoll, da der interne Name in der Regel nur aus Kleinbuchstaben ohne Sonderzeichen – und teilweise aus Abkürzungen – besteht, was die Lesbarkeit für den Benutzer erschwert. Der interne Name wird in der Datenbank und auch in den XML-Dateien verwendet (siehe Abschnitt „Eigenes XML-Format“). Der Dublin Core Standard empfiehlt für XML die Nutzung von Kleinbuchstaben [Dcmi03], so dass der interne Name keine Großbuchstaben enthalten sollte. Die Tabelle enthält weiterhin Angaben darüber, ob das Element dem Benutzer angezeigt werden soll oder ob es vom Geoportal nur intern verwendet wird. Letzteres kann sinnvoll sein, um die Übersichtlichkeit für den Benutzer zu erhöhen und ihm interne Angaben vorzuenthalten. Es folgt eine Information, ob das Element mehrfach vorkommen darf, wie es im Dublin Core Standard vorgesehen ist, oder nur einmal. Das einfache Vorkommen eines Elements war eine Anforderung des ZEF an die Datenbank. Diese Beschränkung wird ausschließlich über die Benutzeroberfläche und nicht durch das Datenbankmanagementsystem durchgesetzt, da in der Tabelle md_dc_values natürlich weiterhin beliebig viele Elemente desselben Namens stehen könnten. Die Anordnung der Elemente auf der Benutzeroberfläche wird, wie bei den Links, über einen Zahlenwert angegeben (vgl. Kapitel 3.3.2). Die Spalte refines wird derzeit nicht verwendet. Sie enthält bei verfeinerten Elementen den Namen des ursprünglichen Elements, bei Kernelementen steht hier NULL, bei selbst hinzugefügten Elementen der Wert „notdc“, um den Unterschied zu Dublin Core Standardelementen zu kennzeichnen.

Manche Elemente können auch Vorgabewerte haben, die dem Benutzer die Eingabe erleichtern sollen, die aber auch die Eingabe des Benutzers steuern können. So kann man sicherstellen, dass alle Benutzer einheitliche Begriffe verwenden und nicht mehrere Begriffe für denselben Sachverhalt verwendet werden. Die Benutzeroberfläche zeigt diese Vorgabewerte automatisch im Editor und in der erweiterten Suche an, wenn zu dem jeweiligen Elementnamen passende Vorgabewerte in der Tabelle md_preset_values gespeichert sind.

Für einzelne Metadateneinträge gibt es im Geoportal die Javaklasse MetadataEntry, die alle Daten eines Eintrags enthält. Um mehrere Einträge zusammenzufassen, gibt es die Klasse MetadataEntries. Die Informationen zur Anpassung der Benutzeroberfläche werden im Objekt Portal abgelegt. Gemeinsam mit der Metadatenbank stellen diese Klassen ein Datenmodell dar. Die passende Steuerung ist die Javaklasse Metadata, die diese Objekte aus der Datenbank erzeugt und die Änderungen in der Datenbank vornehmen kann. Benutzereingaben werden von einer JSP-Seite entgegengenommen, falls dies erforderlich ist. Diese Seite gehört ebenfalls zur Steuerung.

Eigenes XML-Format Wenn Datenproduzenten ihre Daten mit Metadaten beschreiben wollen, aber keinen Internetzugang zur Verfügung stehen haben, können sie die Metadaten in einem speziell entwickelten XML-Format abspeichern. Diese XML-Datei(en) kann/können sie dann später im Portal hochladen. Alternativ können sie die XML-Datei zusammen mit den Daten anlegen und


53

auch gemeinsam auf den Datenserver hochladen. So geht der Zusammenhang zwischen den Daten und den zugehörigen Metadaten nicht verloren und es liegen keine unbeschriebenen Daten auf dem Server. Ein Administrator kann die Metadaten dann später in das Geoportal einpflegen, dabei auch gleich die korrekten Verknüpfungen zu den Daten auf dem Datenserver eintragen und nach einer Kontrolle den Status der Metadaten auf geprüft setzten.

Das XML-Format wurde anhand der Richtlinie [Dcmi03] der Dublin Core Metadata Initiative zur Implementierung von Dublin Core in XML entworfen. Das Schema der XML-Datei wurde auch im XML-Schema-Format beschrieben. Dieses findet man vollständig im Anhang 6.8f, gemeinsam mit einer Beispieldatei. Mit diesem Schema kann man die Korrektheit einer XML-Datei mit speziellen Programmen auch automatisiert prüfen.

Jede XML-Datei beginnt mit dem typischen XML-Header. Außerdem werden 3 verschiedene Namespaces definiert, um die einzelnen Elemente unterscheiden zu können. So gibt es einen eigenen Namespace für die Dublin Core Kernelemente (dc), einen für die verfeinerten Elemente (dcterms) und einen für selbst ergänzte Elemente (zef). Da es in XML ebenfalls Elemente gibt, die man mit den Metadatenelementen verwechseln könnte, werden die XML-Elemente im Folgenden als Tags bezeichnet. Jeder Tag hat einen Namen, der sich aus dem Kürzel für den Namespace und dem eigentlichen Tagnamen zusammensetzt. Dies kann so aussehen: <ns:tagname>Inhalt</ns:tagname>. Außerdem kann man zu jedem Tag Attribute angeben und Tags ineinander schachteln, um eine Baumstruktur zu erzeugen. Der Wurzeltag der GLOWA Volta XML-Dateien heißt metadata und gehört zum Namespace zef. Hier werden alle benötigten Namespaces in Form von Attributen definiert und auch eine Versionsnummer für das verwendete XML-Format angegeben. Innerhalb dieses Tags stehen ein oder mehrere record Tags, die ebenfalls dem Namespace zef angehören. Jeder record Tag enthält einen kompletten Metadateneintrag, so dass man auch mehrere Metadatensätze in einer XML-Datei speichern kann. Dies ermöglicht das Hochladen vieler Metadaten auf einmal, falls dies erforderlich sein sollte. Als Attribut enthält er zudem einen Zeitstempel.

In jedem record Tag befinden sich nun die einzelnen Tags, die jeweils ein Element beschreiben. Der Tagname entspricht dem Namen des beschriebenen Elements aus der Tabelle im Abschnitt „Eigene Metadatenverwaltung“. Abgesehen vom Identifikator ist jedes Element optional, muss also in der XML-Datei nicht auftauchen. Für eine sinnvolle Verwendung im Geoportal ist jedoch zumindest die Angabe der Elemente title, url und accessrights empfohlen, die jedoch später durch einen Administrator vorgenommen werden kann. Sie enthalten Informationen, anhand derer das Portal verknüpfte Daten auffinden und die Downloadrechte zu diesen Daten auslesen kann. Sind keine Daten verknüpft, sind die Elemente accessrights und url nicht notwendig. Der Benutzer des Portals kann aus dem Metadateneintrag später jedoch nur einen Nutzen ziehen, wenn alle für ihn relevanten Informationen in dem Eintrag auch angegeben sind. Es sollten also möglichst viele Elemente ausgefüllt werden, auch wenn dies nach dem Dublin Core Standard nicht verpflichtend ist. Die in der Tabelle, im Abschnitt „Eigene Metadatenverwaltung“, beschriebenen Beschränkungen für die Elemente gelten auch in den XML-Dateien. Ein stark verkürztes Beispiel für eine solche XML-Datei, ohne Namespace-Definitionen, mit nur einem Record und sehr wenigen ausgewählten Elementen, sieht so aus: <?xml version="1.0" encoding="UTF-8" standalone="no"?>

<zef:metadata version="1.0">

<zef:record>


54

<dc:identifier> urn:x-gvp:0:test...</dc:identifier> <dc:title>Dies ist ein Testtitel</dc:title>

<dc:description>Dies ist eine Beschreibung.</dc:description>

<dcterms:temporalcoverage>2008</dcterms:temporalcoverage>

<zef:qualitycontrol>Nur ein Test.</zef:qualitycontrol>

</zef:record>

</zef:metadata>

Die hochgeladenen XML-Dateien werden von einer JSP-Seite in Empfang genommen und an einen Parser weitergereicht. Der Parser in der Javaklasse MetadataJDOM erzeugt ein MetdataEntries-Objekt, welches dann mit Hilfe der bereits bekannten Metadata-Klasse in die Datenbank geschrieben wird. Hierbei wird der Zeitstempel des Eintrags berücksichtigt, falls in der Datenbank bereits ein Eintrag mit dem gleichen Identifikator existiert. Neuere Einträge überschreiben hier die älteren, ältere Einträge werden verworfen. Zudem werden die Benutzerrechte des aktuell angemeldeten Benutzers berücksichtigt. Nur die Benutzer, die zu den beiden im Abschnitt „Eigene Metadatenverwaltung“ beschriebenen Gruppen gehören, dürfen Metadateneinträge hochladen.

Externes Javaprogramm Das bereits erwähnte Javaprogramm, welches am ZEF entwickelt wird, soll verschiedene Aufgaben übernehmen. Mit ihm kann man auch ohne Internetverbindung eigene Daten durch Metadateneinträge beschreiben. Es enthält einen URN-Generator, um dem Benutzer das Erzeugen der URNs für den Identifikator zu erleichtern. Außerdem kann man über einen Editor die Metadatenelemente ausfüllen und als XML-Datei speichern. Diese XML-Datei kann man dann im Geoportal hochladen. Es ist zudem geplant, dass das Programm auch die Aufgabe übernehmen soll, die eigentlichen Geodaten über das SSH-Protokoll (SCP) auf den Datenserver zu übertragen. Die Metadaten könnten hier als XML-Datei im gleichen Verzeichnis mit übertragen werden, so dass sie nicht von den zugehörigen Daten getrennt werden. Mehr hierzu wird in Kapitel 4.3 erläutert.

Das Programm muss ebenfalls, wie das Schema der Metadatenbank, nachträglich an die Bedürfnisse der Benutzer anpassbar sein. Für die URN benötigt es zudem die UID des jeweiligen Benutzers. Da ein Computer mit dem Programm auch von mehreren Benutzern gemeinsam genutzt werden kann, ist eine einfache Benutzerauswahl beim Start des Programms sinnvoll. Bei bestehender Internetverbindung kann das Programm vom Geoportal generierte Textlisten verwenden, die Informationen zu allen Benutzern inklusive UID oder alle bereits verwendeten Identifikatoren enthalten.

3.3.4 Suchfunktionen

Suchen in der Metadatenbank Eine umfangreiche Metadatenbank kann nur sinnvoll genutzt werden, wenn der Benutzer die gewünschten Einträge darin auch finden kann. Hierfür enthält das Geoportal Suchfunktionen, welche die Metadatenbank verwenden. Für die Suche im Metadatenkatalog gibt es im GLOWA Volta Geoportal sechs verschiedene Möglichkeiten:

• Blättern durch eine vollständige Liste aller Metadateneinträge,


55

• Einschränkung dieser Liste durch Auswahl eines Themas aus einer Liste, die automatisch aus dem Metadatenelement subject generiert wird,

• eine Standardsuche mit nur einem einzigen Suchfeld, • eine erweiterte Suche mit Suchfeldern zu jedem Metadatenelement (außer internen), • eine Eingabemöglichkeit für bereits bekannte Identifikatoren, um direkt diesen Eintrag

aufzurufen, • eine Koordinatensuche. Eine Suche nach Objekten innerhalb von (vektorbasierten) Geodaten wäre nur über eine zusätzliche Geodatenbank möglich (vgl. Kapitel 3.3.3). Alle vorhandenen Suchmöglichkeiten liefern als Resultat gleich aussehende Ergebnislisten, die dem Benutzer einen schnellen Überblick über die gefundenen Metadateneinträge geben sollen. Die Ergebnisse zeigen nur einen geringen Teil der Metadatenelemente an. So kann der Benutzer entscheiden, ob er die richtigen Einträge gefunden hat, ohne alle Details betrachten zu müssen. Auf Wunsch kann aber auch ein geeigneter Viewer aufgerufen werden, der eine vollständige Ansicht des jeweiligen Metadateneintrags bietet (siehe Kapitel 3.3.5).

Das Blättern („browsing“) ermöglicht eine sequenzielle Suche in allen Metadateneinträgen oder in den Einträgen zu einem bestimmten Thema. Dies ist sinnvoll, wenn der Benutzer nicht genau weiß, wonach er sucht und einfach alle Einträge anschauen möchte. Diese Funktion wurde von den Verantwortlichen am ZEF gefordert. Über die Informationsseiten (siehe Kapitel 3.3.9) können verantwortliche Personen auch informative Texte zu ausgewählten Themen zusammenstellen, die mit Einträgen aus der Metadatenbank verknüpft werden können. Dies bietet dem Benutzer einen einfachen Einstieg in vorbereitete Themen, erfordert jedoch zusätzlichen Aufwand der verantwortlichen Personen, weil die entsprechenden Informationsseiten erst manuell erstellt werden müssen. Beim Blättern ist dies nicht notwenig, dafür fehlen hier die Informationstexte. Außerdem kann die Liste der Themen kann sehr lang und unübersichtlich werden, da sie automatisch erzeugt wird.

Erweiterte Suche Die erweiterte Suche bietet dem Benutzer die Möglichkeit, alle Metadatenelemente getrennt zu durchsuchen und so sehr genaue Suchanfragen zu stellen. Für jedes für den Benutzer sichtbare Element der Metadatenbank gibt es ein Eingabefeld oder eine Auswahlliste mit Vorgabewerten, so dass der Benutzer seine Anfrage einfach stellen kann. Die Metadatenbank unterscheidet zwischen mehrfach und einfach vorkommenden Elementen, so dass auch die Benutzeroberfläche daran angepasst werden muss. Mehrfaches Element Einfaches Element Ohne Vorgabewerte Mehrzeiliges Textfeld (eine

Suchanfrage pro Zeile) Einzeiliges Textfeld

Mit Vorgabewerten Mehrfachauswahlliste Einfachauswahlliste Im GLOWA Volta Geoportal werden alle Schlüsselwörter automatisch durch UND verknüpft, weitere Verknüpfungen (ODER, NICHT) sind nicht möglich. Neben kompletten Wörtern kann man in Textfelder auch Teilwörter eingeben, beispielsweise führt die Suche nach „Haus“ auch zu Ergebnissen, die „Haushalt“ oder „Wohnhaus“ enthalten. Dies ist sinnvoll, wenn der Benutzer die Suchbegriffe nicht exakt spezifizieren kann. An dem Beispiel kann man ebenfalls sehen, dass die Groß- und Kleinschreibung bei der Suche keine Rolle spielt.


56

Abbildung 3.7 Ausschnitt der erweiterten Suche

Eine JSP-Seite nimmt die Benutzereingaben aus den Textfeldern oder Auswahllisten entgegen und reicht sie an die Javaklasse Metadata weiter, die im Geoportal für alle Operationen auf der Metadatenbank zuständig ist. Von dort wird die Suchanfrage über einen SQL-Befehl an die Metadatenbank abgesetzt. Alle Ergebnisse, auf die die Suchanfrage zutrifft, werden zunächst nur in Form einer Liste von Identifikatoren geliefert. In einem zweiten Schritt werden dann die passenden Metadateneinträge zu den Identifikatoren ausgelesen. So lässt sich Redundanz im Programmcode vermeiden, da das Auslesen der Metadateneinträge auch noch in anderen Funktionen benötigt wird. Die Ergebnisse werden in Form eines MetadataEntries-Objekts (Datenmodell) zurückgeliefert. Die SQL-Anfrage nach den Identifikatoren sieht vereinfacht so aus: SELECT DISTINCT d.identifier FROM md_datasets AS d, md_dc_values AS v0, md_dc_values AS v1, [...] WHERE (v0.identifier=d.identifier AND v0.element=? AND v0.e_value ILIKE ?) AND (v1.identifier=d.identifier AND v1.element=? AND v1.e_value ILIKE ?) AND [...] Mit dem Schlüsselwort DISTINCT werden doppelt gefundene Identifikatoren eliminiert, im FROM-Teil stehen die Tabellen, in denen gesucht wird. In dem Beispiel werden die Werte der im WHERE-Teil ausgewählten Elemente in der Tabelle md_dc_values gesucht. Diese Tabelle enthält alle Werte unter Angabe der zugehörigen Elementnamen. Um nur vom Administrator geprüfte Metadateneinträge zu erhalten, kann man anstatt der Tabelle md_datasets auch die Sicht md_checked_datasets durchsuchen. Falls erforderlich, muss auch die Tabelle md_dc_description durchsucht werden, da nur dort die Beschreibungen abgelegt sind. Mit dem Schlüsselwort LIKE


57

kann man nach Teilwörtern suchen, wenn man den Suchbegriff in Platzhalterzeichen % einschließt. Dies macht jedoch nur bei Schlüsselwörtern aus Textfeldern Sinn, da die Auswahllisten sowieso feste Begriffe enthalten, die genau bekannt sind. Um zusätzlich die Groß- und Kleinschreibung zu ignorieren, verwendet man ILIKE anstatt LIKE.

Die Anfrage wird in Java mit einem sogenannten Prepared Statement an die Datenbank abgesetzt. Hierbei kann man variable Werte in SQL-Befehlen, in diesem Fall Elementnamen und Suchwörter, durch ein Fragezeichen kennzeichnen und später über spezielle Funktionen einsetzten. Dies ist aus Sicherheitsgründen sinnvoll, da so SQL-Injections verhindert werden. Hierbei handelt es sich um eine Sicherheitslücke, die ausgenutzt werden könnte, um zusätzlichen Code in einen SQL-Befehl einzuschmuggeln. Anstatt nur einen Suchwert einzugeben, könnte der Benutzer ohne Prepared Statements den vorherigen SQL-Befehl abschließen und einen vollständigen, neuen SQL-Befehl eingeben, der dann von der Datenbank ausgeführt wird. Dies wäre möglich, wenn die Eingabe des Benutzers einfach nur an einer bestimmten Stelle in den SQL-Befehl eingefügt werden würde. Bei Prepared Statements wird sichergestellt, dass die Benutzereingabe nur als Wert, und nicht als Teil des SQL-Befehls verwendet wird. Mehr zu SQL-Injections findet man unter [Wiki08e].

Standardsuche Bei der Standardsuche kann der Benutzer nach einzelnen Schlüsselwörtern suchen, die er in ein einzelnes Textfeld eingibt. Diese Art der Suche ist sehr einfach, da es keine umfangreichen und unübersichtlichen Eingabemöglichkeiten gibt, die vor allem neue Benutzer verwirren könnten. Hier wird jedes einzelne Wort durch UND verknüpft und gesucht, in der erweiterten Suche müsste man hierfür neue Zeilen in den Textfeldern verwenden. Dies ist notwendig, da nur eine einzige Zeile als Eingabemöglichkeit zur Verfügung steht. Die Standardsuche unterscheidet sich weiterhin von der erweiterten Suche, da sie alle Elemente auf einmal nach den eingegebenen Suchbegriffen durchsucht. Eine Spezifizierung anhand einzelner Elemente findet hier nicht statt. Die Tabellen md_dc_values und md_dc_description werden getrennt durchsucht, die Ergebnisse werden jedoch ohne Duplikate gemeinsam dargestellt.

Auch hier ist die Javaklasse Metadata für die Verarbeitung der Suchanfrage zuständig, die von einer JSP-Seite entgegen genommen wurde. Der abgesetzte SQL-Befehl ist ähnlich zu dem der erweiterten Suche, jedoch gibt es Unterschiede. So ist es beispielsweise nicht notwenig, die durchsuchten Elemente zu spezifizieren, da hier nicht nach Elementen unterschieden wird. Die Suche nach Teilwörtern mit Hilfe von ILIKE findet aber auch hier statt. Es wird zudem ebenfalls ein Prepared Statement verwendet. Ergebnisse werden ebenfalls in Form eines MetadataEntries-Objekts zurückgeliefert, welches mit der gleichen Methode aus den Identifikatoren gebildet wird, wie bei der erweiterten Suche.

Koordinatensuche als Schnittsuche Alle bislang betrachteten Suchfunktionen haben die räumliche Lage der Daten außer Acht gelassen, sie haben sich nur auf die Textinformationen der Metadatenelemente gestützt. Die Metadaten können die räumliche Lage jedoch in Form von Koordinaten enthalten, nach denen man ebenfalls suchen kann.


58

S/O

Y

X

N/WN

W

Bounding Box

S

O

Abbildung 3.8 Koordinatensystem für eine Bounding Box

Von den Koordinaten wird ein rechteckiges Gebiet auf der Erde aufgespannt, welches den gesuchten Ort darstellt. Um dieses Rechteck – genannt Bounding Box – zu beschreiben, benötigt man vier verschiedene Koordinaten. Abbildung 3.8 zeigt den Aufbau einer solchen Bounding Box. Die vier Koordinaten Nord, Süd, Ost und West beschreiben zwei diagonal gegenüberliegende Ecken des Rechtecks. Es ist egal, welche der Ecken beschrieben werden. Hier wurden die nordwestliche und die südöstliche Ecke gewählt, die durch die entsprechenden Koordinaten angegeben werden. Die Werte der Koordinaten können in verschiedenen Einheiten vorliegen. Im Geoportal wird hauptsächlich die Angabe in Dezimalgraden verwendet, aber auch eine Angabe in Metern wäre möglich. Die verwendete Einheit wird gemeinsam mit den Koordinatenwerten in der Metadatenbank gespeichert.

S/O

Y

X

N/WN

W

S

O

a

b

Abbildung 3.9 Suchanfrage nach Rechteck a findet b und umgekehrt


59

Bei einer Suchanfrage wäre es nicht sinnvoll, nur nach exakt übereinstimmenden Koordinaten suchen zu können, da diese dem Benutzer in den meisten Fällen nicht bekannt sind. Stattdessen wäre es praktisch, wenn der Benutzer nach den Koordinaten eines bestimmten Gebiets suchen könnte, für das er sich interessiert, und als Ergebnis bekäme er alle Metadateneinträge präsentiert, die Daten aus diesem Gebiet beschreiben. Das gesuchte Gebiet muss jedoch nicht vollständig in dem Suchgebiet liegen, sondern es kann sich auch nur überlappen oder das Suchgebiet kann nur einen Teilausschnitt des gesuchten Gebiets darstellen. Trotzdem sollen die entsprechenden Metadateneinträge gefunden werden. Die Suche sollte also als Schnittsuche implementiert werden, die bei jeder Art von Überschneidung des Suchgebiets mit einem passenden Zielgebiet einen Treffer liefert.

Die gewünschten Eigenschaften kann man mit Hilfe einer Schnittfunktion erreichen, die mit einem SQL-Befehl an die Datenbank abgesetzt wird. In Abbildung 3.9 sieht man zwei Rechtecke, welche die Suchanfrage und eine der zu vergleichenden Bounding Boxen darstellen. Nehmen wir nun an, Rechteck a sei das gesuchte Gebiet – also die Suchanfrage – und Rechteck b sei eine der Bounding Boxen aus der Metadatenbank. Nun muss überprüft werden, ob die Rechtecke sich schneiden oder vollständig ineinander liegen. Dies ist der Fall, wenn

( ) ( ) ( ) ( )( )abababab NSSNWOOW >∨<∨<∨>¬ ,

erfüllt ist, wobei aaaa WOSN ,,, die Nord-, Süd-, Ost- und Westkoordinaten der Suchanfrage a und bbbb WOSN ,,, die Koordinaten der zu vergleichenden Bounding Box b darstellen. Es wird hier getestet, ob der westliche Rand von b östlicher liegt als der östliche Rand von a, oder ob der östliche Rand von b westlicher liegt als der westliche Rand von a, oder ob der nördliche Rand von b südlicher liegt als der südliche Rand von a, oder ob der südliche Rand von b nördlicher liegt als der nördliche Rand von a. Dieser Test ist genau dann erfüllt, wenn kein Schnitt vorliegt, so dass man diese Formel noch negieren muss. Nun ist die Formel genau dann erfüllt, wenn a und b sich schneiden oder ineinander enthalten sind, denn es liegt eben kein Rechteck vollständig nördlich, südlich, östlich oder westlich vom anderen. Dieses vereinfachte Verfahren kann jedoch nur angewendet werden, wenn man keine schrägen Linien miteinander vergleicht. Schräge Linien würden nicht durch einen eindeutigen Wert repräsentiert werden. Dies ist hier aber nicht der Fall, da die Grenzlinien von Karten niemals diagonal liegen können, sondern nur waagerecht oder senkrecht und parallel zueinander.

Auch die Koordinatensuche wird von der Javaklasse Metadata durchgeführt. Es wird hier ein SQL-Befehl als Prepared Statement an die Metadatenbank abgesetzt, der alle Identifikatoren der Einträge zurückliefert, in denen sich die Koordinaten mit denen der Suchanfrage schneiden. Die vom Benutzer eingegebenen Werte werden über eine JSP-Seite entgegengenommen und an Metadata weitergereicht. In SQL sieht die Formel von oben so aus: SELECT DISTINCT identifier FROM md_dc_box WHERE unit ILIKE ? AND NOT((westlimit > ?) OR (eastlimit < ?) OR (northlimit < ?) OR (southlimit > ?)) Anstatt der Tabelle md_dc_box kann auch die Sicht md_checked_dc_box verwenden werden, die nur geprüfte Metadateneinträge enthält. Wie man in der zweiten Zeile sehen kann, wird auch die verwendete Einheit mit einer entsprechenden Angabe des Benutzers verglichen, dies ist jedoch nur optional. Entscheidend sind die unteren beiden Zeilen, in denen die Formel in SQL umgesetzt


60

wird. Die Benutzereingaben zur Suchanfrage werden in dem Prepared Statement anstelle der Fragezeichen passend eingesetzt. Abschließend wird auch hier die gleiche Methode aufgerufen, wie bei den anderen Suchen, um die Ergebnisse in Form eines MetadataEntries-Objekts aus der Datenbank zu laden.

3.3.5 Visualisierung

Anzeigekomponenten Nachdem der Benutzer einen geeigneten Metadateneintrag gefunden hat, möchte er diesen in der Regel auch angezeigt bekommen. Hierfür sind im Geoportal die Anzeigekomponenten zuständig. Im einfachsten Fall müssen sie nur alle Elemente des jeweiligen Metadateneintrags anzeigen, es sind allerdings noch weitere Funktionen denkbar. Diese unterscheiden sich je nach dem, welche Daten mit dem Metadateneintrag verknüpft sind. Beispiele für verschiedene Typen von Daten sind Karten, Dokumente, Google Maps Karten und Andere. Eine Karte benötigt andere Funktionen bei der Betrachtung, als ein Textdokument oder eine Tabelle. Derzeit verfügt das Geoportal über drei Viewer, die jedoch später durch weitere ergänzt werden können. Bereits implementiert wurden:

• der MapViewer zur Anzeige von Karten, • der GooglemapsViewer zur Anzeige von Google Maps Karten und • der DataViewer für beliebige dateibasierte Daten oder reine Metadaten. Diese existierenden Viewer werden in den nachfolgenden Abschnitten genauer erläutert. Den größten Aufwand stellt hierbei der MapViewer dar, der zugleich auch die wichtigste Visualisierungsmöglichkeit eines Geoportals repräsentiert. Nahezu alle Geoportale bieten die Möglichkeit, Karten anzeigen zu können.

Package (optional)(z.B. beispielviewer)

Ergebnisliste

Verzeichnis(z.B. beispielviewer/)

JSP-Datei(en)

index.jsp

weitere.jsp

Aufru

f mit

Iden

tifik

ator

Datamanager(Package datamanager)

Javaklasse(n)

Beispielviewer.class

Weitere.class

Javaklassen

Metadata.class

MetadataEntry.class

…

… …

…

wird

ang

ezei

gt

verwendet

erzeugt

verwendet

id

id

•Eintrag 1[link zu viewer]



•Eintrag 4

Steuerung

Datenmodell

Präsentation

Abbildung 3.10 Aufbau und Aufruf eines beliebigen Viewers


61

Der Typ der Daten ist in einem eigenen Metadatenelement angegeben, so dass das Geoportal anhand dieses Elements entscheiden kann, mit welchem Viewer der jeweilige Eintrag betrachtet werden muss. Dies geschieht direkt in den Ergebnislisten der in Kapitel 3.3.4 beschriebenen Suchen, die für jedes Ergebnis einen Link zum passenden Viewer enthalten. Die Zuordnung eines Typs zu einem Viewer geschieht in der Konfigurationsdatei viewertypes.properties, in der auch ein Standardviewer für unbekannte Typen angegeben werden kann. Wenn der Benutzer einen Viewer aus einem Eintrag der Ergebnisliste heraus aufruft, wird dem Viewer gleich ein Parameter mit dem Identifikator des ausgewählten Eintrags mitgegeben. So wird dem Viewer bekannt gemacht, welchen Eintrag er anzeigen soll.

Ein Viewer besteht mindestens aus einem Verzeichnis und einer enthaltenen JSP-Datei, die mit dem Identifikator als Parameter aufgerufen wird. Zunächst sollte diese Seite alle Metadatenelemente des aufgerufenen Eintrags anzeigen. Hierfür ist nur sehr wenig Code notwendig. Es muss der Identifikator aus dem Parameter ausgelesen werden und zu diesem Identifikator müssen alle Elemente aus der Metadatenbank geladen werden. Für letzteres kann eine Methode aus der Javaklasse Metadata des Datamanagers verwendet werden, die den vollständigen Metadateneintrag als MetadataEntry-Objekt zurückliefert. Dieses Objekt kann nun einer weiteren Methode aus dem Datamanager übergeben werden, die alle verwendeten Elemente anzeigt (Klasse Out). Neben der Anzeige der Elemente werden auch Verknüpfungen zu abhängigen Metadateneinträgen angezeigt, falls die entsprechenden Elemente source und relation als Wert eine URN des gewünschten Eintrags enthalten. Links auf externe Quellen können im Element url als URLs mit den Protokollen HTTP, HTTPS und FTP angegeben werden. Sie werden dann ebenfalls angezeigt, obwohl das interne Element selbst eigentlich nicht angezeigt wird. Um weitere Funktionalität zu ermöglichen, können auch weitere JSP-Seiten zu dem Viewer hinzugefügt werden. Außerdem kann zu einem Viewer ein eigenes Java-Package gehören, welches den gleichen Namen wie das Verzeichnis mit den JSP-Seiten tragen sollte, um es einfacher zuordnen zu können. In diesem Package liegen Klassen, die entweder Datenmodelle oder Steuerungen dieses Viewers repräsentieren. Die Steuerungen enthalten im Geoportal auch die vollständige Anwendungslogik der Viewer. Die JSP-Seiten sind in der Regel Präsentationen, da sie dem Benutzer Informationen anzeigen. Jedoch können sie auch Benutzereingaben entgegennehmen, dann sind es ebenfalls Steuerungen. Die Einordnung der Dateien der bereits existierenden Viewer in das MVC-Modell kann der entsprechenden Tabelle im Anhang 6.2 entnommen werden. Wie mit dem Beispiel des verwendeten MetadataEntry-Objekts gezeigt wird, kann jeder Viewer auch die Klassen des Datamanagers ergänzend zu seinen eigenen Klassen verwenden.

Die Trennung nach dem MVC-Ansatz ermöglicht es, Teile eines Viewers gegen kompatible andere Teile auszutauschen, wenn dies erforderlich sein sollte. Wenn neue Typen von Daten betrachtet werden müssen, kann außerdem einfach ein neuer Viewer programmiert und gleichberechtigt neben den anderen verwendet werden. Das Geoportal ermöglicht so eine große Flexibilität für zukünftige Änderungen in der Visualisierung. Die Viewer stellen die hauptsächliche und wichtigste Erweiterungsmöglichkeit der komponentenbasierten Architektur des Geoportals dar.

Neben der Anzeige von Metadaten haben alle Viewer auch die sogenannten permanenten Links gemeinsam. Am Ende eines jeden detailliert angezeigten Metadateneintrags sollte ein Link stehen, mit dem der Benutzer den Viewer gemeinsam mit dem aktuellen Metadateneintrag direkt aufrufen kann. Dies ist praktisch, wenn von extern auf einen Eintrag der Metadatenbank verlinkt


62

werden soll, oder wenn der Benutzer in seinem Browser Lesezeichen auf einen bestimmten Eintrag setzten möchte. Alle drei Viewer des Geoportals bieten diese Funktion.

MapViewer Der wichtigste Viewer des Geoportals ist der MapViewer. Der Name legt bereits die Funktion nahe, es sollen dem Benutzer Karten des Geoportals direkt in seinem Browser angezeigt werden. Diese Funktionalität ist sehr komplex und der Programmieraufwand für eine vollständige Eigenentwicklung wäre sehr hoch, so dass der MapViewer als Bestandteile auch externe Software enthält, die große Teile der Funktionalität bereitstellt. Die Überlegungen zur Auswahl der entsprechenden Software werden in den folgenden drei Abschnitten dieses Kapitels beschrieben. Die Integration der externen Software in den MapViewer, und somit in das Geoportal, ist nicht trivial zu lösen und wird in weiteren Abschnitten näher erläutert.

Zunächst muss jedoch der Funktionsumfang des MapViewers näher betrachtet werden. So soll das Geoportal dem Benutzer vorbereitete Karten anzeigen können. Diese Karten können zudem als Grundlage für die räumliche Zuordnung von Daten dienen. Ein Beispiel verdeutlicht dies: Angenommen, Forscher haben Studien zur Bevölkerung bestimmter Orte betrieben und die Ergebnisse in einzelnen Textdokumenten oder Tabellen zu den einzelnen Orten beschrieben. Nun könnte eine Karte erstellt werden, die alle diese Orte zeigt. Wenn ein Benutzer nun Interesse an den Ergebnissen zu einem bestimmten Ort hat, kann er diesen auswählen und erhält als Ergebnis eine Verknüpfung auf das passende Dokument. Natürlich sind auch Karten denkbar, die selbst die Information bereitstellen. Beispielsweise können Karten erstellt werden, die alle Hochwassergebiete kennzeichnen. An den genannten Beispielen kann man bereits die Notwendigkeit einer weiteren Funktion erkennen. Wenn der Benutzer auf einen Blick sehen möchte, welche der zuvor untersuchten Orte von dem Hochwasser betroffen sind, wäre es hilfreich, die beiden Karten übereinander legen zu können.

Die Anzeige von Informationen zu bestimmten Objekten auf einer Karte wird Querying genannt und muss von der Benutzeroberfläche zur Anzeige von Karten (im Fall des Geoportals der Mapbender, s.u.) unterstützt werden. Im einfachsten Fall werden hier einfach ausgewählte Attribute aus den Geodaten der Karte angezeigt, was bei einem Ort beispielsweise die Einwohnerzahl seien könnte. Aber auch Links auf Dokumente, wie in dem oben genannten Beispiel, sind denkbar. Die gleichzeitige Anzeige verschiedener Karten wird im MapViewer des Geoportals über den sogenannten Mapbasket ermöglicht. In diesem Korb kann der Benutzer mehrere Karten sammeln, die dann gemeinsam in einer Benutzeroberfläche angezeigt werden. Natürlich muss die Benutzeroberfläche zur Anzeige von Karten der MapViewer-Komponente zusätzlich alle üblichen Funktionen zur Anzeige von Karten anbieten, die im Abschnitt „Vergleich verschiedener Benutzeroberflächen“ aufgelistet sind.

Die Vorteile des komponentenbasierten Ansatzes des MapViewers werden praktisch sichtbar, wenn man den alternativen MapViewer betrachtet. Im Verzeichnis des MapViewers liegt noch eine weitere JSP-Datei, welche die Funktionalität zur Anzeige von Karten des MapViewers nutzt, jedoch auf die Verwendung des Mapbaskets verzichtet. So wurde ohne großen zusätzlichen Aufwand ein weiterer MapViewer programmiert, der eine schnellere Anzeige einzelner Karten ermöglicht. Dies kann zum Beispiel praktisch sein, wenn man in einem Text einen Link direkt auf einen bestimmten Metadateneintrag mit einer Karte angeben möchte. In diesem Fall will der Benutzer nur diese bestimmte Karte betrachten und kann auf die Funktion des „Sammelns“ von


63

Karten mit Hilfe des Mapbaskets verzichten. Im GLOWA Volta Geoportal könnte diese Funktion für Übersichtskarten zu bestimmten Themen zum Einsatz kommen.

Um dem Benutzer die Möglichkeit zu bieten, die den Karten zugrunde liegenden Geodaten herunter zu laden, kann er aus dem MapViewer heraus die MapDownloader-Komponente aufrufen. Diese ist für den Download von Geodaten zuständig (siehe Kapitel 3.3.7).

Die Steuerung der externen Softwareprogramme ist die Hauptaufgabe, welche die MapViewer-Komponente selbst übernimmt. Dem Benutzer sollen die Vorgänge im Hintergrund verborgen bleiben, er soll auf intuitive Art und Weise eine Karte betrachten können, ohne sich Gedanken über die technischen Hintergründe zu machen. Zwar wird die Einbindung der Software in den MapViewer in späteren Abschnitten erläutert, jedoch soll hier in Abbildung 3.11 bereits ein Überblick über den Aufbau und die Funktionsweise der MapViewer-Komponente gegeben werden.

Mapserver(UMN MapServer)

Geodaten(Vektordaten)

Geodaten(Rasterdaten)

Konfiguration(Karte 1)

Benutzeroberfläche zur Anzeige von Karten(Mapbender)

Benutzer

Konfiguration(Karte 2)

WMS-Dienst (Karte 1) WMS-Dienst (Karte 2)

Anzeige

MapV

iewer-

Steuerung

bereitet vor

liest WMS-Informationen

konfiguriert

MapViewer-Komponente

zeigt Link zu konfiguriertem MapbenderKartensteuerung

Abbildung 3.11 Aufbau und grundlegende Funktionsweise der MapViewer-Komponente

Wenn der Benutzer sich für eine oder mehrere Karten entschieden hat, bereitet die MapViewer-Komponente zunächst die zugehörigen Geodaten vor, die vom Datenserver auf den Webserver transferiert werden müssen. Das Gleiche geschieht mit den Konfigurationsdateien für den Mapserver, in denen – neben anderen Informationen – die Zusammensetzung der Karte aus einzelnen Ebenen und die Zuordnung der passenden Geodaten zu den einzelnen Ebenen beschrieben ist. Die Lage der Geodaten und der Konfigurationsdaten erfährt der MapViewer aus dem Metadatenelement url, dessen mögliche Werte im Anhang 6.10 näher beschrieben werden. Mit den Daten kann der Mapserver nun WMS-Dienste für die ausgewählten Karten bereitstellen und auf Anfrage internetkompatible Grafiken für den angezeigten Kartenausschnitt generieren. Die Benutzeroberfläche für Karten stellt dann Funktionen für die Anzeige der WMS-Dienste bereit. Hierfür muss sie jedoch zunächst für die Verwendung der jeweiligen WMS-Dienste konfiguriert werden. Außerdem benötigt der Benutzer einen Link, um die konfigurierte Oberfläche aufrufen zu können. Damit der Benutzer den WMS-Dienst auch mit einer externen Applikation aufrufen kann, zeigt der MapViewer zusätzlich einen Link zu den jeweiligen WMS-Diensten („GetCapabilities“) an. Bei extern angebotenen Karten entfällt diese komplette


64

Prozedur. Hier wird einfach ein Link auf einen externen Viewer und – falls verfügbar – auf einen externen WMS-Dienst angezeigt.

Theoretischer Vergleich verschiedener Mapserver Das GLOWA Volta Geoportal soll eigene Geodaten im Internet anbieten können. Jeder Benutzer soll sie mit einem einfachen Webbrowser betrachten können. Kein Webbrowser unterstützt jedoch die verfügbaren Geodatenformate, so dass eine Umwandlung in kompatible Grafikformate notwendig ist. Außerdem ist es notwendig, bestimmte Funktionen anzubieten, um eine sinnvolle Betrachtung der Karten zu ermöglichen. So wird beispielsweise das An- und Abschalten von Kartenebenen oder das Anzeigen eines bestimmten Kartenausschnitts ermöglicht, so dass der Nutzer nicht nur statische Grafiken betrachten muss. Diese Aufgaben übernimmt der sogenannte Mapserver. Hier kann man unter einer großen Auswahl von Servern wählen, die alle unterschiedliche Vor- und Nachteile haben.

Verglichen wurden hier die beiden bekanntesten Vertreter für Open Source beziehungsweise kommerzielle Mapserver, UMN MapServer und ESRI ArcIMS, sowie eine Auswahl von vier weiteren Servern, um weitere Vergleichsmöglichkeiten zu bieten. Diese sind AutoDesk MapGuide, Geoserver, Intergraph GeoMedia WebMap und deegree. Im Internet auf Hersteller- beziehungsweise Projektseiten, in Mailinglisten und Foren, in denen sich Benutzer austauschen, oder auf eigenen Erfahrungen beruhende Informationen sind in folgender Tabelle zusammengefasst. MapServer ArcIMS MapGuide Open

Source Geoserver deegree GeoMedia

WebMap Hersteller UMN / Open

Source ESRI AutoDesk /

Open Source Open Source Community

Lat/lon / Open Source

Intergraph

Webseite mapserver.gis. umn.edu

www.esri.com/ software/ arcgis/arcims/

mapguide. osgeo.org

geoserver.org deegree.org www.inter graph.de/ products/geomedia.asp

Clients Verschiedene (Mapbender, Chameleon, ka-map, GDV, andere)

HTML, Java, ESRI-Programme, andere

AJAX, ActiveX Community MapBuilder, verschiedene

iGeoPortal (AJAX), deeJump (Java)

ActiveX Control, Java Applet

Quellcode (+) Open (-) Closed (+) Open (+) Open (+) Open (-) Closed Kosten (+) keine (-) teuer (+) keine (+) keine (+) keine (-) teuer Standards (+) OGC (+) OGC (+) OGC (+) OGC

(+) WFS-T (+) OGC (+) Referenz-Implementierung

(+) OGC

Formate (+) viele (über OGR- und GDAL- Bibliotheken)

(+) viele (ESRI und andere)

(+) viele (z.B. über GDAL)

(+) viele (+) viele (+) viele

Systeme (+) viele (Windows, Linux, Mac, div. Unix)

(+) viele (Windows, Linux, div. Unix)

(-) nur Windows und Linux

(+) viele (JSP)

(+) viele (über Java / Tomcat)

(-) nur Windows

Webserver (+) universelles CGI-Modul

(+) 10 verschiedene

(-) nur Apache und IIS

(+) als JSP (+) viele (über Java / Tomcat)

(-)nur IIS


65

Performance und Stabilität

(+) performanter als ArcIMS (+) schnelles Umprojizieren (+) stabil und über lange Zeit bewährt (+) geringer Ressourcen-Verbrauch

(-) Client reagiert träge (-) weniger zuverlässig und stabil als MapServer (-) hoher Ressourcen-Verbrauch

(+) multithread-/prozessorfähig

(+) Stabil und performant (Hersteller-angaben)

Installation (+) einfach unter Windows (-) kompliziert unter Linux

(+/-) angeblich einfach oder kompliziert (je nach Quelle)

(+) einfach unter Windows(-) kompliziert unter Linux

(+) einfach (+) einfach

Dokumenta-tion

(-) unübersicht-lich, teilweise unvollständig

(+) gut (+) gut (+) umfang-reich

(+) umfangreich (-) unvollständig

Administration und Integration

(+) flexible Administration (Textdateien) (-) komplizierte Administration (+) Integration in ESRI-Produkte durch AmeiN

(+) einfache Administration für Standard-aufgaben (-) schlechte Administration für spezielle Aufgaben (+) Integration in andere ESRI-Produkte

(+) webbasierte Administration (-) keine Integration in ESRI-Produkte

(+) webbasierte Administration(-) keine Integration in ESRI-Produkte

(-) keine Integration in ESRI-Produkte (+) flexible Administration (XML-Dateien) (-) komplizierte Administration

Sonstiges (+) viele Anwender

(+) Verwaltet Metadaten (+) Marktführer

(+) zweiter Platz in der Verbreitung nach ESRI

Begründung für UMN MapServer Für das GLOWA Volta Geoportal kommt nur einer der kostenlosen Mapserver in Frage, die beiden kommerziellen Produkte sind, stellvertretend für andere kommerzielle Mapserver, zu teuer. Die Entscheidung fiel auf den UMN MapServer, da er kostenlos ist, laut Benutzerberichten auch unter Belastung stabil arbeitet und sich schon über lange Zeit im Einsatz bewährt hat. Eine flexible Nutzung durch offene Standards (z.B. WMS) ist möglich. Zudem arbeitet er schnell (z.B. schneller als ArcIMS) und zeichnet sich durch einen geringen Ressourcenverbrauch aus. Wenn Karten nicht in der richtigen Projektion vorliegen, kann der UMN MapServer sie im laufenden Betrieb in das gewünschte Format umprojizieren, ohne dass die Originaldateien anpasst werden müssen. Da das Programm direkt beziehungsweise über zusätzliche Bibliotheken sehr viele Formate ohne Konvertierung unterstützt, ist es auch für zukünftige, noch nicht absehbare, Formate höchstwahrscheinlich nutzbar. Die Konfiguration erfolgt über Textdateien, die sogenannten Mapfiles, die für jede Karte vorliegen müssen. Die vom ZEF genutzte Software zur Erstellung von Karten, ArcMap von ESRI, kann mit Hilfe der Erweiterung AmeiN alle benötigten Konfigurationsdateien erzeugen (siehe Abschnitt „Integration und Verwendung des UMN MapServers im Portal“). Gerade diese einfache Integration mit ESRI-Produkten hat der UMN MapServer den anderen Open Source Programmen voraus.


66

Nachteile sind die gerade unter Linux oft sehr umständliche Installation, die durch die Nutzung von Windows auf dem Webserver jedoch teilweise umgangen werden kann, sowie die komplizierte Administration. Hier sind die Textdateien im Vergleich zu einer einfachen grafischen Oberfläche im Nachteil. Sie ermöglichen jedoch eine flexible Integration in das Geoportal. Die Dokumentation des UMN MapServers ist unübersichtlich und es fehlen wichtige Informationen. Dies kann jedoch teilweise durch den Kontakt zu anderen Benutzern und Entwicklern über Mailinglisten wieder ausgeglichen werden. Außerdem gibt es externe Literatur über den UMN MapServer, beispielsweise Bücher.

Die anderen getesteten Produkte sind entweder zu teuer, haben einen hohen Ressourcenverbrauch, sind instabil und träge oder bieten keine Integration mit ESRI-Produkten. Dafür sind sie oft einfacher zu Installieren und zu Administrieren. Die Installation muss jedoch nur selten vorgenommen werden und eine Administration über eine grafische Oberfläche erschwert die Integration ins Geoportal, da diese Oberflächen vom Portal nicht oder nur schlecht genutzt werden können.

Vergleich verschiedener Benutzeroberflächen Der UMN MapServer kann die Geodaten internetkompatibel aufbereiten und als WMS-Dienst bereitstellen. Der Benutzer benötigt dann noch eine einfache Benutzeroberfläche mit Bedienelementen, um die umfangreichen Funktionen eines WMS-Dienstes auch nutzen zu können. Diese ist, genau wie der Mapserver, ein Bestandteil der MapViewer-Komponente des Geoportals. Bei den Benutzeroberflächen gibt es eine große Auswahl von Produkten. Die kommerziellen Oberflächen sind normalerweise Bestandteil eines Mapservers, deren Verwendung ja bereits ausgeschlossen wurde. Für den UMN MapServer kann man jedoch viele verschiedene kostenlose Oberflächen verwenden.

Eine Möglichkeit ist das Programmieren einer eigenen Oberfläche, die mit Hilfe der UMN MapServer Erweiterung PHP/Mapscript auf diesen zugreifen kann, wie es beispielsweise in [UnSc05] realisiert wurde. Hier kann zwar jede Funktion implementiert werden, jedoch muss viel Zeit und Aufwand in die Programmierung gesteckt werden. Eine Nutzung bereits fertiger Oberflächen ist hier sinnvoller. In [Schu07] ist ein umfangreicher Vergleich verschiedener Oberflächen zufinden, die dort als Webmapping-Anwendungen bezeichnet werden.

Für das GLOWA Volta Geoportal fiel die Entscheidung auf das kostenlose Open Source Programm Mapbender. Das Programm bietet alle benötigten Funktionen, die für eine dynamische Karte im Internet benötigt werden:

• Visualisieren eines WMS-Dienstes als Karte, • Verschieben des aktuellen Kartenausschnitts („panning“), • Zoomen und zoomen durch Aufziehen eines Rechtecks, • Zentrieren der Karte auf einen bestimmten Punkt, • Gesamtkarte wieder anzeigen, • Anzeigen von Strecken und Koordinaten, • Drucken der Karte (über PDF), • Hinzufügen weiterer WMS-Dienste, • Anzeige aller Karten und Ebenen („layer“) in einer Baumansicht, • Ein- und Ausblenden einzelner Layer, • Legende für alle aktiven Layer,


67

• Übersichtskarte, • Maßstabsbalken, • Vor- und Zurückblättern in den bisherigen Änderungen, • Anzeige von Informationen zu den WMS-Diensten, • Links auf den WMS-Dienst anzeigen. Neben diesen Funktionen bietet Mapbender seit der Version 2.5 auch einen integrierten SLD-Editor, um einfache Filter für die einzelnen Layer zu setzen. Diese Funktion ist jedoch zunächst nur aus dem Administrationsmenü von Mapbender erreichbar und für den normalen Benutzer nicht zu erreichen (siehe hierzu auch Kapitel 3.3.6). Neben den genannten Eigenschaften hat Mapbender noch weitere Vorteile. Er setzt nicht auf kostenpflichtiger Software auf, sondern kann mit PHP, einer PostgreSQL- oder MySQL-Datenbank und beispielsweise dem Apache Webserver betrieben werden. Außerdem kann er sowohl unter Windows als auch unter Linux arbeiten. Dies sorgt für geringe Kosten und eine hohe Flexibilität beim späteren Einsatz.

Die Dokumentation zu Mapbender findet man in dem zum Projekt gehörenden Wiki [Mapb08]. Sie ist umfangreich, jedoch nicht immer vollständig. Dies wird aber durch mehrere Mailinglisten wieder ausgeglichen, auf denen man von den Entwicklern und anderen Benutzern von Mapbender schnelle Antworten auf Fragen erhält.

Die Integration von Mapbender in das Geoportal stellte zunächst ein Problem dar, weil man Mapbender nicht einfach die URL zu einem WMS-Dienst übergeben kann, der dann angezeigt wird. Stattdessen ist eine Manipulation der Konfigurationsdatenbank notwendig, die immerhin eine hohe Flexibilität ermöglicht, da dort alles konfiguriert werden kann, was Mapbender als Funktion anbietet. Die hierfür benötigten Schritte sind im Abschnitt „Integration von Mapbender in das Portal“ näher erläutert.

Als Alternative zu Mapbender wurde auch der Community MapBuilder in die nähere Auswahl aufgenommen und getestet. MapBuilder bietet einen zu Mapbender vergleichbaren Funktionsumfang. Letztlich wurde jedoch eine Entscheidung gegen dieses Programm getroffen, da es hauptsächlich ein Framework ist, das sehr umständlich und unintuitiv über XML-Dateien konfiguriert werden muss. Die Integration ins Portal wäre so mit größerem Aufwand verbunden gewesen, als die Lösung mit Mapbender. Außerdem war die Implementierung des SLD-Editors in MapBuilder im Testzeitraum weniger weit fortgeschritten, als in Mapbender.

Integration und Verwendung des UMN MapServers im Portal Der UMN MapServer läuft als CGI-Programm auf dem Webserver. Im Geoportal wird hierfür und für Mapbender der Apache Webserver verwendet. Um eine Karte als WMS-Dienst anbieten zu können, die dann von Mapbender angezeigt werden kann, sind folgende Dateien notwendig:

• Geodaten für alle Ebenen der Karte, • Konfigurationsdateien für jede Karte, die deren Aufbau beschreiben („Mapfiles“), • Vorlagen für Ergebnisse von Anfragen an Kartenobjekte („query templates“), • Weitere Konfigurationsdateien, die von den Mapfiles benötigt werden. Auf dem Webserver werden die Geodaten vom Geoportal in Dateiform in Unterverzeichnissen des Verzeichnisses hidden abgelegt. Die Lage des Verzeichnisses ist für das Portal in der Konfigurationsdatei portal.properties hinterlegt. Der UMN MapServer kann auf diese


68

Information nicht zugreifen, weshalb das Verzeichnis auch in den Konfigurationsdateien für die Karten hinterlegt ist. Das Verzeichnis hidden ist nicht aus dem Internet zu erreichen, um einen unbefugten Zugriff auf die Geodaten zu verhindern, der UMN MapServer kann jedoch darauf zugreifen.

Alle Konfigurationsdateien des Geoportals werden im Verzeichnis visible abgelegt, das aus dem Internet erreichbar seien muss. Genau wie die Geodaten, werden auch die Konfigurationsdateien einer Karte gemeinsam in einem Unterverzeichnis abgelegt. Die Konfigurationsdateien können nicht automatisch vom Geoportal erzeugt werden, da sie sehr umfangreich sind und ihr Aufbau sehr komplex ist. Es ist jedoch möglich, sie mit der Erweiterung AmeiN aus ArcMap heraus zu exportieren. Sie werden dann separat von den Geodaten auf dem Datenserver abgelegt. AmeiN ermöglicht die Integration mit dem am ZEF eingesetzten ArcMap von ESRI, für das ältere ArcView existiert eine andere Erweiterung (AveiN), die den gleichen Zweck erfüllt. Die Erweiterung übernimmt viele Informationen über die jeweilige Karte direkt aus ArcMap und erleichtert und beschleunigt das Erzeugen der Konfigurationsdateien somit ungemein. Da die Konfigurationsdateien in Textform vorliegen, können sie zudem bei Bedarf leicht abgeändert werden. Mehr zu den Konfigurationsdateien findet man im Abschnitt „Konfigurationsdateien des UMN MapServers“.

Um also Karten im Geoportal visualisieren zu können, müssen ihre Geodaten in einem gemeinsamen Verzeichnis auf dem Datenserver abgelegt werden. Die erzeugten Konfigurationsdateien liegen in einem separaten Verzeichnis auf dem Datenserver. In dem zu der Karte gehörenden Metadateneintrag müssen nun im Element url beide Lageorte angegeben werden. Weitere Informationen zum Element url findet man im Anhang 6.10. Wenn ein Benutzer die Karte nun betrachten möchte, kopiert der MapViewer beide Verzeichnisse in die oben beschriebenen Verzeichnisse visible und hidden. Dort kann der UMN MapServer bei Bedarf auf beides zugreifen. Um die Karte als WMS-Dienst zu erhalten, kann nun der MapServer über eine URL angesprochen werden. In der URL muss die Lage des Mapfiles angegeben werden, um diese bestimmte Karte anzusprechen. Eine solche URL könnte so aussehen: http://servername/cgi-bin/mapserv.exe? MAP=C%3A%5CInetpub%5Cvisible%5CKonfigurationKarte1%5CKarte1.map& SERVICE=WMS&VERSION=1.1.1&REQUEST=GetCapabilities Es wird der MapServer als CGI-Programm angesprochen und ihm werden einige Parameter übergeben. Der Parameter MAP enthält den Pfad zu dem Mapfile der Karte. Die weiteren Parameter geben an, dass das GetCapabilities-Dokument des WMS-Dienstes zurückgegeben werden soll. Ein WMS-Client kann aus diesem XML-Dokument alle benötigten Informationen zur Anzeige der Karte herauslesen. Um anstatt dieses Dokuments eine Grafik der Karte anzuzeigen, muss dem Parameter REQUEST der Wert „GetMap“ übergeben werden. Außerdem müssen dazu mindestens noch die Namen der aktivierten Ebenen und die Koordinaten des Kartenausschnitts („bounding box“) übergeben werden. Da ein Benutzer das jedoch nicht manuell machen möchte, weil es sehr umständlich ist, übernehmen spezielle WMS-Clients diese Aufgabe. Sie bieten eine ansprechende grafische Oberfläche, um den WMS-Server anzusteuern. Im GLOWA Volta Geoportal ist hierfür der, im Abschnitt „Integration von Mapbender in das Portal“ beschriebene, Mapbender zuständig. Der MapViewer muss Mapbender also den WMS-Dienst bekannt machen – oder auch mehrere, wenn mehr als eine Karte gleichzeitig angezeigt werden soll – und dem Benutzer dann einen Link zu Mapbender mit dieser Konfiguration angeben. Dieser gesamte Vorgang geschieht für den Benutzer unsichtbar im Hintergrund. Dass


69

hier ein WMS-Dienst verwendet wird, ist für den Benutzer zunächst ebenfalls unwichtig. Allerdings gibt der MapViewer dem Benutzer die oben beschriebene URL zum GetCapabilities-Dokument zusätzlich mit an, falls der Benutzer die Karte in einem eigenen WMS-Client öffnen möchte.

Was geschieht aber, wenn der Benutzer in seinem WMS-Client nun eine Karte angezeigt bekommt? Der Client fordert beim WMS-Server einen bestimmten Ausschnitt der Karte an. Diese Karte setzt sich aus den aktivierten Ebenen zusammen. Der Server liest nun die Geodaten für alle aktivierten Ebenen aus, stellt anhand der Koordinaten fest, welcher Teil der Karte angezeigt werden soll und berechnet dann eine einfache Grafikdatei des aktuellen Kartenausschnitts. Diese Grafikdatei kann in den Formaten PNG, GIF oder JPEG erzeugt werden und somit direkt im Browser oder in einem anderen WMS-Client dargestellt werden. Der Server übernimmt hier den hauptsächlichen Rechenaufwand, so dass als Grundlage für den Client ein einfacher Browser ausreichend ist. So wird jedem Benutzer die Nutzung des MapViewers auch ohne die Installation zusätzlicher Software ermöglicht. Der UMN MapServer kann Geodaten sogar im laufenden Betrieb umprojizieren. Dies ist notwendig, wenn die Geodaten der einzelnen Ebenen unterschiedliche Koordinatensysteme verwenden, um ihre Lage auf der Erde zu beschreiben. Trotzdem müssen sie gemeinsam angezeigt werden, was das Umprojizieren in ein gemeinsames Koordinatensystem erforderlich macht.

Im Vergleich zu den Geodaten sind die erzeugten Grafikdateien deutlich kleiner, da hier implizit eine verlustbehaftete Reduktion der Daten stattfindet. Dieses Verhalten des WMS-Dienstes verhindert nicht nur das Auslesen der Originaldaten über das Internet, sondern es mindert auch die übertragene Datenmenge. Auch bei einer langsamen Internetverbindung kann so eine Karte betrachtet werden. Wenn große Geodaten angezeigt werden sollen, hat die Übertragung einer kleinen, konstanten Grafik Vorteile für die Netzwerklast. Bei kleineren Geodatenmengen überschreitet jedoch die Größe der, bei jeder Änderung übertragenen, Grafiken irgendwann die Gesamtdatenmenge. Die Geodaten können jedoch sowieso nicht unverändert übertragen werden, da der Client dann die Berechnung der Grafik übernehmen müsste, was bereits ausgeschlossen wurde.

Es verbleibt jedoch ein Problem: Immer, wenn der Benutzer über den MapViewer eine Karte aufruft, werden ihre Geodaten und ihre Konfigurationsdateien vom Datenserver auf den Webserver übertragen. Dort verbrauchen sie jedoch Platz auf der Festplatte. Das Gleiche gilt für die erzeugten Grafikdateien, die der MapServer in einem temporären Verzeichnis ablegt. Ein täglich laufendes Skript kann hier Abhilfe schaffen. Für das Geoportal wurde ein Skript geschrieben, das automatisch den Inhalt der Verzeichnisse visible und hidden und weiterer temporärer Verzeichnisse löscht, wenn der Inhalt älter ist, als ein angegebener Wert in Tagen. So werden beispielsweise alle Daten gelöscht, die älter sind als 2 Tage. Das Skript kann nachts ausgeführt werden, wenn der Server nicht unter Last steht. Es ist jedoch zu beachten, dass die Karte nach dem Löschvorgang nicht mehr über den WMS-Dienst verfügbar ist. Die Anzahl der Tage sollte also so gewählt werden, dass die Benutzer genügend Zeit haben, mit der Karte zu arbeiten. Es ist jedoch jederzeit möglich, die Karte über den MapViewer erneut aufzurufen, so dass die Daten erneut transferiert werden.

Konfigurationsdateien des UMN MapServers Wenn der Datenproduzent mit ArcMap eine Karte erzeugt hat, die im Geoportal angezeigt werden soll, muss er oder eine andere verantwortliche Person anschließend mit der bereits


70

erwähnten Erweiterung AmeiN die Konfigurationsdateien für den UMN MapServer erzeugen. Die wichtigste Konfigurationsdatei ist das Mapfile, das den Aufbau einer Karte bestimmt. Es enthält Angaben über den Namen der Karte, den WMS-Dienst, den Lageort der Geodaten und die einzelnen Ebenen der Karte. Jeder Ebene werden ein Name und Vektor- oder Rasterdaten zugeordnet, die später visualisiert werden sollen. Außerdem wird das Koordinatensystem jeder Ebene angegeben, so dass der MapServer die Daten umprojizieren kann, wenn sich das Koordinatensystem von dem der Gesamtkarte unterscheidet. Da Mapbender nur dann mehrere Karten gleichzeitig anzeigen kann, wenn sie im gleichen Koordinatensystem vorliegen, sollte die Angabe des Koordinatensystems der Gesamtkarte für alle Karten des Geoportals gleich sein. Die Geodaten selbst müssen hierfür nicht geändert werden, was das Einpflegen existierender Karten in das Geoportal erleichtert. Alle Pfadangaben in den Mapfiles beziehen sich auf Lageorte auf dem Webserver, da das Mapfile dort zum Einsatz kommt und nicht etwa auf dem Datenserver.

Neben den erwähnten Angaben, enthält das Mapfile noch weitere, die beispielsweise die Übersichtskarte („reference“), die Legende („legend“), den Maßstabsbalken („scalebar“) und die Lage der Gesamtkarte auf der Erde („extent“) beschreiben. Wichtig sind zudem die Beschreibungen aller Symbole auf der Karte, die nicht in den Geodaten enthalten sind. Sie liegen in einer separaten Datei im Unterverzeichnis symbols, auf das im Mapfile verwiesen wird. Auch die Farbgebung aller Objekte einer Karte wird für jede Ebene angegeben. Gerade diese Informationen werden automatisch aus ArcMap übernommen. Viele Symbole werden aus Fontdateien geladen, wo sie als einzelne Zeichen vorliegen. Die Fontdateien und eine zugehörige Konfigurationsdatei liegen im Unterverzeichnis fonts. Sie werden beim Export mit AmeiN nicht automatisch in dieses Verzeichnis kopiert, so dass dies manuell nachgeholt werden muss. Neben der Verwendung als Symbole werden sie auch benötigt, wenn der UMN MapServer in der Karte Text anzeigen muss. Dies ist bei Objektbeschriftungen oder in der Legende der Fall.

Es ist möglich, über WMS Informationen zu den Attributen aller Objekte einer Karte abzurufen. Dieser Vorgang wird als Querying bezeichnet. Der UMN MapServer kann die Ergebnisse einer solchen Anfrage in Form von HTML-Seiten liefern, die Mapbender dann darstellen kann. Der Aufbau dieser HTML-Seiten wird über Vorlagen vorgegeben („query templates“), die ebenfalls von AmeiN automatisch erzeugt werden. Für jede Ebene einer Karte wird eine separate Vorlage generiert. Diese Vorlagen sollten an die Bedürfnisse des Geoportals angepasst werden. Zunächst betrachten wir jedoch die Funktionsweise dieser Query-Templates. Sie enthalten den HTML-Code, der für die Anzeige als Webseite benötigt wird. Um jedoch die Werte der einzelnen Attribute anzuzeigen, enthalten sie an den passenden Stellen im HTML-Code Platzhalter, die so aufgebaut sind: [Attributname]. Sie werden beim Aufruf der Vorlage von UMN MapServer durch den Wert ersetzt, den das angegebene Attribut für das, vom Benutzer abgefragte, Objekt hat. Dieser Wert wird aus den Geodaten ausgelesen.

Das Aussehen eines automatisch erzeugten Query-Templates kann über das Editieren des HTML-Codes beliebig verändert werden. Die gute Editierbarkeit kann außerdem für eine weitere Funktion genutzt werden, die das Geoportal dann später bereitstellen kann. So wollen Mitarbeiter des ZEF Karten erstellen, die als Übersicht zu einem bestimmten Thema dienen sollen. Hier soll man bestimmte Objekte auf der Karte anklicken können und dann von dort auf verknüpfte Webseiten, Dokumente oder andere Dateien verwiesen werden. Hierfür müssen die Ergebnisse einer Query auch Links enthalten können. Zwar kann man die URLs solcher Links einfach in eines der Attribute der Karte schreiben, so dass man jedem Objekt eine eigene URL zuweisen kann, allerdings wird diese dann nur als Text auf der HTML-Seite angezeigt. Um im Browser


71

einen Link angezeigt zu bekommen, den der Benutzer auch anklicken kann, muss der Platzhalter noch von den passenden HTML-Elementen umschlossen werden. Dies kann beispielsweise so aussehen: <a href=“[URL]“>Wichtiges Dokument</a>

Der Platzhalter [URL] wird durch den Wert des Attributs URL für das angeklickte Objekt ersetzt und man erhält einen HTML-Hyperlink, den der Benutzer jetzt auch anklicken kann. So kann beispielsweise auf externe Webseiten oder auf Metadateneinträge des Portals verwiesen werden. Außerdem können Informationstexte in einem Unterverzeichnis des Mapfile-Verzeichnisses als HTML-Dateien abgelegt werden und über eine relative URL ebenfalls mit Objekten verknüpft werden. So werden sie dem Benutzer über den Link direkt im Browser zugänglich gemacht. Das Gleiche funktioniert auch bei anderen Dateien, beispielsweise Tabellen. Ein Beispiel veranschaulicht dieses Prinzip. Nehmen wir an, es wurde eine Studie für verschiedene Orte durchgeführt, die alle auf einer Karte verzeichnet sind. Nun kann in den Attributen für diese Orte jeweils eine relative URL auf eine Tabelle mit den Ergebnissen für den passenden Ort angegeben werden. Diese Tabellen werden einfach als einzelne Dateien in einem Unterverzeichnis des Mapfile-Verzeichnisses abgelegt. So werden sie beim Kopieren der Konfigurationsdateien automatisch mit auf den Webserver transferiert und können von dort zugegriffen werden, da sie ebenfalls im Verzeichnis visible liegen. Der Benutzer wählt also den Ort aus, der ihn interessiert, und bekommt als Ergebnis einen Link auf die passende Tabelle angezeigt, die er dann gleich herunterladen und betrachten kann.

Integration von Mapbender in das Portal Um die WMS-Dienste, die der UMN MapServer anbietet, auch anzeigen zu können, wird ein WMS-Client benötigt. Das ist eine Benutzeroberfläche, welche die Bedienung des WMS-Servers ermöglicht. Der Benutzer kommt so nicht mit den Interna des WMS-Dienstes in Berührung. Für das GLOWA Volta Geoportal wird ein webbasierter WMS-Client benötigt, der beim Benutzer nur einen Browser voraussetzt. Dies leistet der in PHP und Javascript programmierte Mapbender.

Die Verwendung von Mapbender nach der Installation ist einfach. Über ein webbasiertes Konfigurationsmenü kann eine sogenannte GUI erzeugt werden, die aus vielen verschiedenen Elementen besteht. Die wichtigsten Elemente sind das Kartenfester zur Anzeige des aktuellen Kartenausschnitts, die Schaltflächenleiste, über die verschiedene Funktionen zur aktuellen Karte aufrufen werden können, die Übersichtskarte, die Legende und der Geo Data Explorer (GDE). Der GDE stellt alle Karten mit ihren Ebenen in einer Baumstruktur dar. Einzelne Karten und Ebenen lassen sich hier an- und ausschalten und man kann Informationen zu den einzelnen Einträgen des Baums abrufen. Das Aussehen und die verwendeten Elemente einer GUI kann ein Administrator beliebig festlegen. Dann können der GUI ein oder mehrere WMS-Dienste zugewiesen werden, die in Form von Karten angezeigt werden, wenn die GUI aufgerufen wird. Mapbender kann beliebig viele GUIs und WMS-Dienste verwalten.

Wenn Mapbender im Geoportal eingesetzt werden soll, ergibt sich jedoch ein Problem. Im Geoportal werden die Karten dynamisch geladen und der Benutzer kann beliebige Karten miteinander kombinieren. Fest konfigurierte GUIs helfen hier also nicht weiter. Mapbender muss vom Geoportal dynamisch konfiguriert werden. Der automatische Zugriff auf das webbasierte Konfigurationsmenü ist jedoch nur schwer möglich, da das Menü durch die Benutzerverwaltung des Mapbenders geschützt und der Zugriff somit erst nach einem Login möglich ist. Das Geoportal könnte dieses Login und die Aufrufe der einzelnen Konfigurationsschritte simulieren.


72

Dieses Vorgehen ist jedoch sehr unintuitiv und hat sich in Tests als nicht praktikabel herausgestellt. Es gibt allerdings eine einfachere Möglichkeit, um die Konfiguration von Mapbender zu verändern. Alle Einstellungen speichert Mapbender in einer PostgreSQL-Datenbank, auf die das Geoportal direkt zugreifen kann. Man muss nur die wichtigen Stellen der Datenbank verstehen, um GUIs erzeugen, WMS-Dienste hinzuzufügen und die WMS-Dienste dann einer GUI zuordnen zu können. Das Verfahren wird im Abschnitt „Änderungen an der Mapbender-Datenbank“ genauer beschrieben. Mapbender kann so aufgerufen werden, dass eine bestimmte GUI direkt geladen wird. Der MapViewer zeigt dem Benutzer nun einfach einen Link auf Mapbender, mit der neu erzeugten GUI, an. Der Nachteil dieser Vorgehensweise ist, dass die Datenbank von Mapbender sich von Version zu Version unterscheiden kann und so Anpassungen im Geoportal notwendig werden könnten, wenn eine neue Version von Mapbender verwendet werden soll. Die Mapbender-Versionen, die während der Entwicklungszeit des Geoportal erschienen sind, haben eine solche Modifikation aber nicht notwendig gemacht. Ein direkter Zugriff auf das Konfigurationsmenü würde die gleichen Probleme aufweisen, da auch hier bei neuen Versionen von Mapbender Änderungen vorgenommen werden könnten.

Abbildung 3.12 Interaktive Kartenansicht mit dem Mapbender

Für diese Arbeit wurde noch eine weitere Möglichkeit getestet, um Mapbender dynamische Karten laden zu lassen. Hier sollte die Möglichkeit genutzt werden, dass Mapbender eine Konfiguration von Karten in einem speziellen XML-Dokument speichern kann. Dieses sogenannte WMC-Dokument (Web Map Context) wird in der Datenbank von Mapbender gespeichert und kann beim Aufruf von Mapbender als Parameter übergeben werden, so dass Mapbender mit genau dieser Konfiguration gestartet wird. Auch hier wäre jedoch ein schreibender Zugriff auf die Datenbank notwendig gewesen, um das WMC-Dokument für eine neue Konfiguration zu speichern. Hinzu kommt, dass die verwendeten WMS-Dienste ebenfalls


73

separat in der Datenbank gespeichert werden müssten, ansonsten könnten sie in einem WMC-Dokument nicht verwendet werden. Außerdem müsste auch das WMC-Dokument selbst generiert werden. Der ganze Vorgang ist somit aufwändiger als das oben beschriebene Verfahren und weist die gleichen Probleme auf. Hinzu kommt, dass einige getestete Versionen von Mapbender Probleme beim Laden von WMC-Dokumenten aufgewiesen haben. Auf die Verwendung dieses Verfahrens wurde deshalb verzichtet.

Änderungen an der Mapbender-Datenbank Alle Einstellungen zu GUIs, WMS-Diensten, Benutzern, Gruppen und mehr speichert Mapbender in seiner Datenbank. Als DBMS kann PostgreSQL oder MySQL verwendet werden. Für das GLOWA Volta Geoportal wird PostgreSQL eingesetzt, MySQL ist ungetestet. Die Datenbank von Mapbender 2.5 besteht aus 37 Tabellen, die jedoch nicht alle für die Verwendung im Geoportal relevant sind. Die Datenbank ist leider nur sehr unzureichend dokumentiert, so gibt es keine Übersicht, welche Tabellen welche Funktion haben. Im Rahmen dieser Arbeit wurden jedoch 13 Tabellen identifiziert, die benötigt werden, um eine dynamische Kartenansicht zu erzeugen.

*

*

*

***

**

**

PrimärschlüsselFremdschlüssel

*/+ On Delete CascadeReferenzen

+

+++

++++

+*

++

+*

*

*

*

***

**

**


*/+ On Delete CascadeReferenzen

+

+++

++++

+*

++

+*

Abbildung 3.13 Vereinfachte Übersicht über das Schema der Mapbender-Datenbank (nur relevante Tabellen)

Bevor der MapViewer den Mapbender passend konfigurieren kann, muss zunächst der MapServer vorbereitet werden, so dass er die vom Benutzer ausgewählten Karten als WMS-Dienst anbietet. Dieser Vorgang wird im Abschnitt „Integration und Verwendung des UMN MapServers im Portal“ erläutert. Als nächstes muss der MapViewer die neu entstandenen WMS-Dienste in die Mapbender-Datenbank einfügen. Hierfür werden jedoch viele Angaben über die WMS-Dienste benötigt, die der MapViewer mit Hilfe der Javaklasse GetCapabilitiesJDOM des Datamanagers direkt aus dem GetCapabilities-Dokument der WMS-Dienste herausliest. Zum Verarbeiten des GetCapabilities-Dokuments wird JDOM verwendet, das als Bibliothek eingebunden ist. JDOM stellt ein XML-Dokument in Form von Javaobjekten dar und erleichtert somit die Verarbeitung, da es sich den objektorientierten Ansatz von Java zunutze macht. Die


74

ausgelesenen Werte werden in das Javaobjekt WMS geschrieben und so innerhalb des Geoportals verwendet. Zur Vereinfachung des Vorgangs werden nur die notwendigen Werte ausgelesen, die sich von WMS-Dienst zu WMS-Dienst unterscheiden, alle anderen Werte werden durch Standardwerte ersetzt oder weggelassen. Mapbender funktioniert später trotzdem problemlos. Für jeden WMS-Dienst wird ein eigenes WMS-Objekt erzeugt.

Die Liste der erzeugten WMS-Objekte wird in der Javaklasse MapbenderSetup des MapViewers verwendet, um die Konfiguration von Mapbender anzupassen. Es werden alle Informationen, die die WMS-Dienste betreffen, in die Tabellen wms, wms_format und wms_srs der Datenbank geschrieben. Dies wird nacheinander für jeden WMS-Dienst durchgeführt. Die Ebenen aller WMS-Dienste werden separat behandelt, ihre Informationen werden in die Tabellen layer, layer_epsg und layer_style geschrieben. Die Werte stammen aus den WMS-Objekten, zu deren WMS-Dienst die jeweilige Ebene gehört. Jeder WMS-Dienst und jede Ebene kann im Mapbender über eine eindeutige ID-Nummer identifiziert werden. Beim Einfügen neuer WMS-Dienste und Ebenen in die passenden Tabellen stellt dies jedoch ein Problem dar, weil die IDs der WMS-Dienste und die IDs der Ebenen nicht doppelt vorkommen dürfen. Es kann einfach die höchste bislang vergebene ID um 1 inkrementiert werden, aber dann kann es passieren, dass bei den Nummern der höchstmögliche Wert erreicht wird und keine weiteren WMS-Dienste oder Ebenen hinzugefügt werden könnten. Dies ist der Fall, wenn in der Datenbank nie aufgeräumt wird und sehr viele tote Einträge entstehen, die keine Funktion mehr haben. Zwar bietet der MapViewer die Javaklasse MapbenderCleanup an, welche die Datenbank wieder vollständig von den automatisch erzeugten Einträgen frei räumt, sie muss jedoch manuell aufgerufen werden. Dies ist auch sinnvoll, weil diese Klasse auch die Konfigurationen von Benutzern löscht, die den Mapbender gerade zum Betrachten von Karten verwenden. Ein automatisches Löschen ausschließlich von Einträgen des aktuellen Benutzers ist ebenfalls nicht möglich, da nicht festgestellt werden kann, wann ein Benutzer die Einträge nicht mehr benötigen wird. Das Abmelden des Benutzers vom Portal kann als Signal nicht verwendet werden, da kein Login für das Betrachten von Karten erforderlich ist. Als Lösung wurden der Mapbender-Datenbank zwei Funktionen hinzugefügt, die in SQL programmiert wurden. Dazu gehört noch die neue Tabelle portal_ids. Die beiden Funktionen geben als Resultat eine neue ID für einen WMS-Dienst beziehungsweise für eine Ebene zurück, wenn sie aufgerufen werden. Die aktuellen Werte werden in der Tabelle gespeichert. Zusätzlich werden in der Tabelle auch minimale und maximale Werte für die IDs hinterlegt. So ist es nun möglich, bei der Vergabe neuer IDs beim Erreichen des maximalen Werts wieder beim minimalen Wert anzufangen. Gleichzeitig löschen die Funktionen automatisch alle alten Einträge, die es möglicherweise für die erneut vergebene ID noch geben kann. Liegen der Minimal- und der Maximalwert weit genug auseinander, kann Mapbender so ohne zusätzlichen Wartungsaufwand beliebig oft dynamisch konfiguriert werden, ohne das es zu Problemen kommen kann. Außerdem kann über die Minimal- und Maximalwerte Platz für möglicherweise manuell zu Mapbender hinzugefügte Karten freigehalten werden, die nicht versehentlich gelöscht werden sollen. Sie müssen dann außerhalb des definierten Bereichs liegen. Da Mapbender beim Anlegen neuer WMS-Dienste von unten anfängt, die IDs hoch zu zählen, sollte also der Minimalwert groß genug gewählt werden. Beim Löschen alter Einträge muss die Methode get_layer_id(), welche die neuen IDs für die Ebenen generiert, nur den passenden Eintrag aus der Tabelle layer entfernen. Über eine Fremdschlüsselbeziehung mit „On Delete Cascade“-Anweisungen werden auch alle abhängigen Tabellen gelöscht. Die Methode get_wms_id() muss neben dem Eintrag aus der Tabelle wms zusätzlich noch den Einträg für die GUI löschen. Dessen Name enthält jedoch nur eine fixe Zeichenkette („temp“) und die WMS-ID,


75

so dass er problemlos zuzuordnen ist. Auch hier sorgen Fremdschlüsselbeziehungen mit „On Delete Cascade“-Anweisungen dafür, dass abhängige Einträge in anderen Tabellen automatisch mitgelöscht werden. Die Vergabe neuer IDs und das Löschen alter Einträge geschehen vollständig innerhalb der Datenbank, so dass der Javacode zum Konfigurieren von Mapbender stark vereinfacht wird. Die notwendigen Änderungen an der Datenbank findet man in Anhang 6.5.

Neben dem Hinzufügen der WMS-Dienste und der Ebenen in die Datenbank, muss die Klasse MapbenderSetup auch eine neue GUI erzeugen. Die GUI definiert das Aussehen von Mapbender, so wie der Benutzer das Programm letztendlich zu sehen bekommt. Außerdem können ein oder mehrere WMS-Dienste in eine GUI eingebunden werden, die dann dem Benutzer als Karte angezeigt werden. Es wäre sehr umständlich, jedes mal alle Einträge, die zu einer GUI gehören, einzeln in die entsprechenden Tabellen zu schreiben. Eine GUI ist sehr komplex aufgebaut und verteilt sich zudem über viele Tabellen. Zunächst kann jedoch die Anzahl der beteiligen Tabellen auf die unbedingt benötigten eingeschränkt werden, trotzdem funktioniert Mapbender dann ohne Probleme. Mit einem Trick kann zudem die Anzahl der Operationen beim Erzeugen einer neuen GUI stark reduziert werden. In Mapbender erzeugt man einfach eine GUI, die als Vorlage für alle neu erzeugten GUIs verwendet wird. Diese Vorlage muss „geoportal“ heißen und kann mit dem webbasierten Konfigurationsmenü von Mapbender erstellt werden. Hier kann man Design und Aufbau vorgeben und auch nachträglich verändern. Außerdem muss diese GUI dem Benutzer geoportal zugeordnet werden, dazu jedoch später mehr. Um Vandalismus in der Vorlage zu verhindern, genügt es, das Passwort des Administratorkontos zu setzten, da nur der Administrator GUIs bearbeiten kann. Um nun eine neue GUI zu erzeugen, kopiert MapbenderSetup die Einträge der Vorlage und vergibt einen neuen GUI-Namen. Dieser beginnt immer mit „temp“ und endet mit der ID des ersten WMS-Dienstes der neuen GUI. Auf diese Weise kann eine GUI von der Methode get_wms_id() automatisch zugeordnet und gelöscht werden (s.o.). Kopiert werden die Einträge der Tabellen gui, gui_element, gui_element_vars, gui_mb_user und gui_mb_group. Der Zweck aller betrachteten Mapbender-Tabellen kann der entsprechenden Tabelle im Anhang 6.3 entnommen werden. Nachdem die neue GUI erstellt wurde, muss der MapViewer ihr noch die WMS-Dienste und die zugehörigen Ebenen zuweisen. Dies geschieht durch Einträge in den Tabellen gui_wms und gui_layer. Einer GUI können hier mehrere WMS-Dienste zugeordnet werden, falls der Benutzer mehr als eine Karte ausgewählt hat.

Nachdem die Konfiguration von Mapbender abgeschlossen ist, zeigt der MapViewer dem Benutzer einen Link an, der auf die neu erstellte GUI verweist. Um die Abfrage von Benutzer und Passwort zu verhindert, wird beides als Parameter mit übergeben. Um hier immer die gleichen Angaben verwenden zu können, ist es wichtig, dass die Vorlage bereits einen festgelegten Benutzer und Passwort verwendet, der beim Kopiervorgang übernommen wird. Mit Hilfe von Javascript wird Mapbender in einem neuen Fenster geöffnet, so dass der Benutzer das Geoportal parallel weiterverwenden kann. Wenn er mit dem Betrachten der Karte fertig ist, kann er einfach das Kartenfenster schließen.

DataViewer Neben Karten werden in der Metadatenbank noch andere Daten beschrieben. Dies können beispielsweise Textdokumente oder Tabellen sein, die wissenschaftliche Ergebnisse enthalten. Diese Daten können vom Browser des Benutzers in der Regel nicht direkt angezeigt werden. Wie beim MapViewer werden auch hier zunächst alle verfügbaren Metadatenelemente angezeigt, die verknüpften Daten selbst werden dem Benutzer jedoch nur über den DataDownloader (siehe


76

Kapitel 3.3.7) zum Download angeboten. Mehr Funktionalität bietet der DataViewer nicht. Er ist somit für jede Art von Daten geeignet und kann als Standardviewer verwendet werden.

Aufgrund seiner geringen Komplexität besteht der DataViewer nur aus einer einzigen JSP-Datei. Außerdem nutzt er die Fähigkeiten des Datamanagers, um Metadateneinträge aus der Datenbank zu lesen und darzustellen. Den geladenen Metadateneintrag übergibt er als MetadataEntry-Objekt über die Session des Benutzers an den DataDownloader.

GooglemapsViewer

Abbildung 3.14 Der GooglemapsViewer des Geoportals zeigt eine Karte von Ghana und Burkina Faso

Der dritte und bislang letzte Viewer des GLOWA Volta Geoportals dient der Anzeige von Karten des GoogleMaps-Dienstes [Goog08a] der Firma Google. Der Dienst kann über eine Schnittstelle in beliebige Webseiten eingebunden werden. Dies gelingt am einfachsten über einen Javascript-Aufruf, der einen bestimmten Kartenausschnitt anfordert und an einer festgelegten Stelle auf der Webseite anzeigt. Der Kartenausschnitt wird bei GoogleMaps durch die Angabe des Längen- und Breitengrades des Mittelpunkts definiert. Außerdem muss noch ein Zoomfaktor angeben werden, der ebenfalls Einfluss auf den angezeigten Ausschnitt hat. Diese drei Werte können aus den Metadaten ausgelesen werden und somit für jeden Metadateneintrag eine individuelle Karte angezeigt werden. Die Werte werden in dem Metadatenelement url kodiert und vom GooglemapsViewer verwendet.


77

Der GooglemapsViewer ist ebenfalls einfach aufgebaut. Neben einer JSP-Seite zur Anzeige der Metadaten des Eintrags und der GoogleMaps-Karte gibt es noch die Javaklasse GooglemapsViewer. Diese ist dafür zuständig, aus der zugehörigen Konfigurationsdatei googlemaps.properties die Höhe und Breite des angezeigten Kartenausschnitts und einen Key auszulesen. Der Key wird von Google vergeben und wird benötigt, um Karten auf eigene Webseiten einzubinden. Alle diese Werte müssen nur einmal eingestellt werden. Neben dem Auslesen der Konfiguration ist die Klasse auch für das Extrahieren der Koordinaten und des Zoomfaktors aus der URL verantwortlich. Eine Downloadmöglichkeit für Daten gibt es hier nicht, da die zugrunde liegenden Geodaten bei Google nicht frei verfügbar sind.

3.3.6 Analyse Mit dem Mapbender sind im GLOWA Volta Geoportal grundlegende Onlineanalysen möglich. Die einfachste Möglichkeit ist das Betrachten einer Karte, um daraus Informationen abzuleiten. Man kann beispielsweise einzelne Ebenen der Karte ein- und ausblenden, um deren Inhalte direkt miteinander vergleichen zu können. Außerdem ist es möglich, zu den Objekten auf der Karte zusätzliche Informationen abzurufen („querying“), wenn diese angeboten werden. So kann man zum Beispiel zu einzelnen Städten auf der Karte die Einwohnerzahl abrufen, wenn sie als Attribut in den Geodaten gespeichert wurden. In den Attributen kann man auch Links auf externe Webangebote oder Seiten des Geoportals ablegen, so dass eine Karte ein guter Wegweiser für gewünschte Informationen seien kann. Auch Links auf Daten und Dokumente sind so möglich.

Über die Mapbasket-Funktion des MapViewers kann der Benutzer auch mehrere Karten gleichzeitig im Mapbender darstellen lassen. So kann er die Inhalte beliebiger Karten visuell miteinander vergleichen, so wie dies auch bei den Ebenen einer einzelnen Karte möglich ist.

Zusätzlich zu den genannten Methoden wäre es hilfreich, wenn der Benutzer mit speziellen Anfragen das Aussehen der Karte anhand bestimmter Bedingungen verändern könnte, um bestimmte Objekte der Karte hervorzuheben. So könnte man beispielsweise alle Flüsse ab einer bestimmten Länge hervorheben, wenn diese Information benötigt wird. Mapbender unterstützt diese Funktion mit Hilfe des Standards SLD, der das Setzen von Filtern auf einzelnen Ebenen einer Karte ermöglicht. Mapbender bietet einen Editor zum Erzeugen eines solchen Filters, dieser steht dem normalen Benutzer jedoch nicht zur Verfügung. Der SLD-Editor ist in das Administrationsmenü von Mapbender integriert und kann somit nur von Administratoren verwendet werden. Praktisch wäre jedoch die Möglichkeit, den Editor aus der Kartenansicht heraus für jede einzelne Ebene der Karte aufzurufen.

Die Integration des Editors in die Kartenansicht von Mapbender ist nach Angaben der Entwickler für spätere Versionen von Mapbender geplant. Es ist jedoch möglich, die Funktion bereits in der aktuellen Version 2.5 von Mapbender zu integrieren. Hierbei macht man sich zu Nutze, dass der Quelltext von Mapbender offen liegt und editierbar ist. Der Aufruf des Editors kann in die baumartige Liste der Ebenen (TreeGDE) eingebunden werden, so dass jeder Benutzer den Editor dort für die jeweilige Ebene aufrufen kann. Alle notwenigen Änderungen am Quellcode sind im Anhang 6.6 beschrieben. Diese Lösung funktioniert zwar, jedoch wird die Änderung durch den Filter nicht automatisch in die aktuelle Kartenansicht übernommen. Ein Neuladen der Seite über den Browser schafft hier jedoch Abhilfe. Hinzu kommt, dass die derzeitige Version des SLD-Editors in Mapbender noch nicht sehr benutzerfreundlich ist. Sie ist sehr unübersichtlich und nicht sehr intuitiv zu bedienen. Aus diesem Grund ist für zukünftige Versionen von Mapbender von den Entwicklern eine vereinfachte Version des Editors geplant, die sich auch an die


78

Bedürfnisse der Benutzer anpassen lassen soll. Erst dann lässt sich SLD im Mapbender wirklich sinnvoll einsetzen.

3.3.7 Exportfunktionen

Downloadkomponenten Nicht jeder Benutzer möchte nur den Metadatenkatalog durchsuchen und Karten online betrachten. Wenn er die Daten auf seinem eigenen Rechner zu weiterer wissenschaftlicher Arbeit verwenden möchte, muss er sie in einem Austauschformat herunterladen können. Lokal kann er sie dann mit entsprechender Software weiterverarbeiten. Um die Downloads nicht zu groß werden zu lassen, was bei schmalbandingen, unzuverlässigen und teuren Verbindungen ein Hindernis für die Nutzung wäre, wurden verschiedene Maßnamen getroffen. Hier ist zunächst die verlustfreie Komprimierung der Inhalte zu nennen, die sich vollständig wieder rückgängig machen lässt, um unveränderte Originaldaten zu erhalten. Außerdem kann der Nutzer bei umfangreichen Geodaten selbst eine Vorauswahl der herunter zu ladenden Daten treffen und den Umfang so reduzieren.

Die Datenproduzenten möchten ihre Daten möglicherweise jedoch nicht jedermann zugänglich machen, da die Erhebung oder der Kauf solcher Daten sehr teuer seien kann. Eine Beschränkung des Downloads auf einzelne Benutzer oder Benutzergruppen sollte also möglich sein. Dies geschieht anhand des Metadatenelements accessrights, welches Angaben zu den Benutzerrechten der Daten des jeweiligen Metadateneintrags enthält. Die folgende Tabelle gibt einen Überblick: Wert des Elements accessrights

Bedeutung

all bzw. everybody Jeder Benutzer darf die verknüpften Daten dieses Eintrags herunterladen. u:Benutzername Jeder Benutzer mit dem angegebenen Benutzernamen darf die Daten dieses

Eintrags herunterladen. Da das Element accessrights beliebig oft vorkommen darf, können auch beliebig viele Benutzernamen angegeben werden.

g:Gruppenname Jeder Benutzer, der Mitglied der Gruppe mit dem angegebenen Gruppennamen ist, darf die Daten dieses Eintrags herunterladen. Da accessrights beliebig oft vorkommen darf, können auch beliebig viele Gruppen angegeben werden. Benutzer- und Gruppennamen können beliebig kombiniert werden.

(Element fehlt) Kein Benutzer darf die verknüpften Daten dieses Eintrags herunterladen. Das GLOWA Volta Geoportal enthält bereits zwei Downloadkomponenten, die dem Benutzer unterschiedliche Arten von Daten zum Herunterladen anbieten können. Die Downloader können durch die Benutzer von den passenden Viewern aus aufgerufen werden. Es muss nur bekannt gemacht werden, für die Daten welchen Metadateneintrags sie zuständig seien sollen. Diese Information wird ihnen über die Session des Benutzers übergeben. Es gibt einen Downloader für Karten, der aus dem MapViewer heraus aufgerufen wird, sowie einen Downloader für normale dateibasierte Daten, der aus dem DataViewer heraus aufgerufen wird. Beide Downloader werden in den nachfolgenden Abschnitten in diesem Kapitel näher betrachtet.

Genau wie eine Anzeigekomponente besteht auch ein Downloader mindestens aus einem Verzeichnis und einer JSP-Datei, die dem Benutzer Informationen oder Auswahlmöglichkeiten anzeigt (Präsentation). Hinzu kommt eine Javaklasse als Steuerung, die den Download mit Hilfe des Datamanagers vorbereitet. Alle Klassen liegen der Übersichtlichkeit halber zusammengefasst in einem Package.


79

MapDownloader Nachdem ein Benutzer eine Karte gefunden und eventuell online mit ihr gearbeitet hat, reichen ihm die online angebotenen Funktionen möglicherweise nicht mehr aus. Um offline mit der Karte arbeiten zu können, muss der Benutzer die zugehörigen Geodaten in einem dateibasierten Austauschformat herunterladen. Da der UMN MapServer des MapViewers die Daten bereits in einem solchen Format benötigt und der MapDownloader immer vom MapViewer aus aufgerufen wird, liegen die gewünschten Daten bereits in einem Verzeichnis auf dem Webserver vor. Dieses Verzeichnis ist jedoch nicht für einen Zugriff aus dem Internet freigegeben, um einen unbefugten Download dieser Daten zu verhindern. Als Dateiformate werden im GLOWA Volta Geoportal aufgrund der Anforderungen des ZEF folgende Formate verwendet:

• Vektorbasierte Daten: ESRI Shapefiles, • Rasterdaten: GeoTIFF. Beide Formate werden vom UMN MapServer unterstützt und können aus den ESRI Geodatenbanken exportiert werden. Außerdem sind sie beide stark verbreitet, so dass sie sinnvoll als Dateiformat verwendet werden können. Für jede Ebene einer Karte wird übrigens ein eigener Satz Dateien benötigt, der bei GeoTIFF mindestens aus einer und bei Shapefiles mindestens aus drei Dateien besteht.

Abbildung 3.15 Auswahlmenü des MapDownloaders


80

Dem Benutzer wird zunächst ein Auswahlmenü angezeigt, in dem er für alle Karten im Mapbasket auswählen kann, welche Ebenen heruntergeladen werden sollen. Außerdem kann er entscheiden, ob auch die Konfigurationsdateien des UMN MapServers in den Download mit eingeschlossen werden sollen. Diese Vorauswahl ermöglicht es, den Download in seiner Größe zu reduzieren, wenn der Benutzer nicht die Daten aller Ebenen der Karte benötigt. Gerade bei Karten mit umfangreichen Rasterdaten auf mehreren Ebenen, kann dies sinnvoll sein. Um die einzelnen Ebenen bestimmten Dateien zuordnen zu können, muss der MapDownloader die entsprechenden Informationen aus dem Mapfile der Karte auslesen. Dort ist die Zuordnung der Ebenen zu den zugehörigen Dateien hinterlegt, da der UMN MapServer diese Angaben benötigt, um die Karte darzustellen. Das Auslesen geschieht mit der Javaklasse Mapfile des Datamanagers. Sobald die Dateien bekannt sind und der Benutzer eine Auswahl getroffen hat, komprimiert der Downloader die Dateien in das verlustfreie ZIP-Format, um eine weitere Reduktion der Downloadgröße zu erreichen. Die fertige ZIP-Datei wird in ein öffentlich zugängliches Verzeichnis auf dem Webserver geschrieben (visible). Hier werden alle Dateien, die der Benutzer herunterladen kann, in ein benutzerspezifisches Unterverzeichnis geschrieben, das beim Abmelden des Benutzers automatisch vom Datamanager gelöscht wird. Falls der Benutzer das Abmelden vergisst, werden die Daten, genau wie bei den Daten des UMN MapServers, durch ein Skript regelmäßig gelöscht. Dies alles geschieht, weil sich sonst im Laufe des Betriebs viele nicht mehr benötigte Dateien ansammeln würden und der Speicherplatz in der VM irgendwann zu Neige gehen würde.

Wenn die Geodaten ursprünglich aus einer ESRI Geodatenbank stammen, wird dem Benutzer, alternativ zum oben beschriebenen Download, optional noch der Download als komprimierter XML-Workspace angeboten. Auch dies ist eine Anforderung des ZEF an das Portal. Bei einem XML-Workspace handelt es sich um ein Austauschformat der Firma ESRI, um Datensätze von einer Geodatenbank in eine andere zu übertragen. Diese Option macht also nur für Nutzer von ESRIs Geodatenbanken sinn. Für den Export als XML-Workspace greift der MapDownloader auf eine Methode der Javaklasse Geodatabase aus dem Datamanager zurück (siehe Kapitel 3.3.8).

Der MapDownloader erfährt die Metadateneinträge, deren Kartendaten er anbieten soll, aus dem Mapbasket. Dieses kann über die Session des Benutzers zugegriffen werden und enthält eine Liste aller Metadateneinträge, die der Benutzer im MapViewer ausgewählt hat. Die Lage der Daten auf dem Webserver kann der MapDownloader, genau wie der MapViewer, aus den Werten des Metadatenelements url entnehmen, welches die relativen Pfadangaben enthält. Es gibt unterschiedliche URLs für die Konfigurationsdateien, die Geodaten im Dateisystem und die Geodaten in den Geodatenbanken. Mehr zu den URLs ist im Anhang 6.10 zu finden.

Auch der MapDownloader ist nach dem MVC-Prinzip aufgebaut. Das Benutzermenü wurde als JSP-Datei implementiert, die eine Präsentation darstellt. Eine weitere JSP-Datei nimmt die Benutzereingaben entgegen. Die Steuerung übernimmt die Javaklasse MapDownloader aus dem Package mapdownloader.

MapDownloader aus Mapbender heraus starten Der GUI „geoportal“ in Mapbender, die als Vorlage für alle vom Geoportal erzeugten GUIs dient, kann als GUI-Element eine Schaltfläche hinzugefügt werden, über die direkt aus der Kartenansicht heraus der MapDownloader geöffnet werden kann. Die Schaltfläche kann an beliebiger Stelle in der GUI platziert werden und öffnet beim Betätigen ein neues Fenster mit der Oberfläche des MapDownloaders. Das GUI-Element kann über einen SQL-Befehl der


81

Mapbender-Datenbank hinzugefügt werden, der im Anhang 6.5 angegeben ist. Die Positionsangaben und der Link zum MapDownloader müssen möglicherweise angepasst werden.

Über die Session des Benutzers kann weiterhin der Mapbasket zugegriffen werden, der auch vom MapViewer zur Konfiguration von Mapbender verwendet wurde. Er enthält alle angezeigten Karten, so dass der MapDownloader dem Benutzer die richtigen Karten zum Download anbietet. Dies funktioniert jedoch nur, wenn im Browser des Benutzers Cookies aktiviert wurden, da die Zuordnung der Session zu einem bestimmten Benutzer in Tomcat über Cookies geregelt wird. Falls keine Cookies zur Verfügung stehen, verwendet Tomcat einen speziellen Parameter, der an jede aufgerufene URL angehängt werden kann und der die Session-ID enthält. Das funktioniert allerdings nur innerhalb von Tomcat. Da Mapbender aber ein PHP-Programm ist, und PHP ein eigenes System zur Verwaltung von Sessions verwendet, ist die aktuelle Tomcat-Session des Benutzers dann in dem neu geöffneten Fenster des MapDownloaders nicht mehr bekannt. Es wird für das neue Fenster eine neue Session begonnen und dem Benutzer wird eine Fehlermeldung angezeigt, weil der Mapbasket in der neuen Session leer ist. Bei der Verwendung von Cookies tritt dieses Problem jedoch nicht auf, da diese im Browser des Benutzers für alle Fenster zugreifbar gespeichert werden.

DataDownloader Nicht alle Metadateneinträge sind mit Karten verknüpft. Oft liegen die Daten in Dateiformaten vor, die vom Geoportal nicht in Form einer Karte angezeigt werden können. Dies ist beispielsweise bei einem Textdokument oder einer Tabelle der Fall. Trotzdem soll der Benutzer Zugriff auf diese Daten erhalten. Der DataDownloader wird derzeit immer aus dem DataViewer heraus aufgerufen. Er bietet kein Benutzermenü, sondern beschränkt sich darauf, dem Benutzer den Link für den Download bekannt zu geben. Damit dies geschehen kann, müssen die Daten jedoch zuvor vom Datenserver auf den Webserver transferiert werden. Wie beim MapDownloader, wird auch hier als Ziel das öffentlich zugängliche Verzeichnis auf dem Webserver verwendet, das dem Benutzer zugeordnet werden kann und das beim Abmelden des Benutzers wieder gelöscht wird.

Die Lage der Dateien auf dem Datenserver erfährt der DataDownloader aus dem Metadatenelement url, das die relativen Pfadangaben zu den Daten enthält. Mehr zu den URLs ist in der Tabelle im Anhang 6.10 zu finden. Nun muss noch unterschieden werden, ob die URL auf eine einzelne Datei oder ein komplettes Verzeichnis zeigt. Eine einzelne Datei wird unverändert auf den Webserver kopiert und dem Benutzer schließlich zum Download angeboten. Ein Verzeichnis wird vorher in das verlustfreie ZIP-Format komprimiert und dann als einzelne Datei zum Download bereitgestellt. Der Benutzer muss so nicht alle Dateien des Verzeichnisses einzeln herunterladen und der Download wird aufgrund der Kompression kleiner. Dass einzelne Dateien nicht komprimiert werden, ist ebenfalls ein beabsichtigtes Verhalten, denn so kann der Browser die Datei nach dem Ladevorgang eventuell direkt darstellen, falls er das entsprechende Format (eventuell über ein Plug-in) unterstützt. Wenn die URL einen Verweis auf Datensätze in einer ESRI Geodatenbank enthält, werden diese mit Hilfe einer Methode aus der Javaklasse Geodatabase als komprimierter XML-Workspace (siehe Kapitel 3.3.8) in das oben genannte Verzeichnis exportiert und dann zum Download angeboten.

Der DataDownloader liest den aktuellen Metadateneintrag als MetadataEntry-Objekt aus der Session des Benutzers aus. Dieses Objekt wurde zuvor vom DataViewer in der Session


82

gespeichert. So wird dem DataDownloader bekannt gemacht, für welchen Eintrag er momentan zuständig ist.

Der DataDownloader ist etwas einfacher aufgebaut als der MapDownloader. Downloadlink und Statusmeldungen zeigt er dem Benutzer über eine JSP-Seite an (Präsentation). Das Vorbereiten des Downloads übernimmt die Javaklasse DataDownloader aus dem Package datadownloader (Steuerung), die auch Methoden aus dem Datamanager verwendet.

3.3.8 Integration der ESRI Geodatenbanken Die Geodaten für Karten können nicht nur in Form von Dateien vorliegen. Am ZEF werden bereits Geodatenbanken der Firma ESRI [Esri07b] eingesetzt, auf die auch das Geoportal zurückgreifen soll. Man kann zwei Typen von Geodatenbanken unterscheiden, die zum Einsatz kommen sollen:

• Personal Geodatabases, • File Geodatabases. Die Personal Geodatabase von ESRI ist das ältere Format, es basiert auf einer Access-Datenbank. Eine File Geodatabase ist, nach Angaben von ESRI, die zukunftssicherere Datenbank, die in einem proprietären dateibasierten Format vorliegt. Beide Datenbanktypen können über Samba auf dem Datenserver abgelegt werden und von dort zugegriffen werden. Ohne Samba wäre es nicht möglich, die Datenbanken auf dem Datenserver zu speichern, da die ESRI-Software die Datenbanken nur über einen Dateisystemzugriff ansprechen kann. Beide Datenbanktypen können nur über die entsprechende Software von ESRI verwendet werden. Um Geodaten aus diesen Datenbanken anzeigen oder sie zum Download anbieten zu können, muss das Geoportal beziehungsweise der UMN MapServer die Daten jedoch in einem dateibasierten Austauschformat vorliegen haben.

Diesem Problem kann mittels einer speziellen Programmierschnittstelle (API) von ESRI begegnet werden, welche die einzige bekannte Möglichkeit für externe Programme darstellt, auf die Datenbanken zuzugreifen. Die API heißt ArcObjects und ist ein Bestandteil der ArcGIS Engine Runtime. Diese muss mindestens in der aktuellen Version 9.2 vorliegen, um auch den Zugriff auf die neuen File Geodatabases zu ermöglichen. ArcObjects ist unter anderem für Java verfügbar, so dass das Geoportal die API nutzen kann. Für die Nutzung fallen jedoch Lizenzgebühren an, so dass die Verwendung im Geoportal optional ist und über eine Einstellung in einer Konfigurationsdatei abschaltbar ist. Dann wäre der Zugriff auf ESRI Geodatenbanken jedoch nicht möglich. Zwar muss man bei einigen Funktionen von ArcObjects Personal- und File Geodatabases unterschiedlich behandeln, aber über die Datei- bzw. Verzeichnisendung kann das Geoportal leicht feststellen, welche der beiden Datenbanktypen gerade vorliegt. Eine File Geodatabase liegt als Verzeichnis vor, das auf .gdb endet, eine Personal Geodatabase liegt als Datei vor, die auf .mdb endet.

ESRI bietet für ArcObjects im Internet eine umfangreiche Dokumentation an, jedoch ist die API sehr umfangreich und somit unübersichtlich, so dass selbst die Implementierung einfacher Funktionen nicht trivial zu lösen ist. Die API ermöglicht den Zugriff auf nahezu alle Funktionen, die von den ESRI-Produkten angeboten werden. Für das Geoportal genügen jedoch folgende Funktionen:

• Export von Feature Datasets und Feature Classes (Vektordaten) als Shapefiles,


83

• Export von Raster Datasets und Raster Catalogs (Rasterdaten) als GeoTIFF, • Export beliebiger Datensätze als XML-Workspace. Die Implementierung der Exporte geschah in der Javaklasse Geodatabase, die ein Teil des Datamanagers ist. Sie wird vom MapViewer, MapDownloader und vom DataDownloader verwendet. Die Nutzung von ESRI Geodatenbanken sollte sich der Administrator des Servers gut überlegen, da die ArcGIS Engine Runtime während der Tests oft ohne Grund abgestürzt ist. Diese Probleme traten gelegentlich auf, jedoch unregelmäßig, also nicht immer beim gleichen Datensatz oder bei der gleichen Aktion. Sie treten auch bei anderen Produkten aus ESRIs ArcGIS-Reihe auf und konnten dort von Mitarbeitern des ZEF bestätigt werden. Bei einem Absturz wurde die vollständige Javaumgebung inklusive Tomcat zwangsweise mit beendet und das Portal war nicht mehr erreichbar. Wenn die ArcGIS Engine Runtime dennoch eingesetzt werden soll, sollte ein Skript regelmäßig überprüfen, ob Tomcat noch läuft und es gegebenenfalls automatisch neu starten. Ein weiteres Problem ist, dass der Export aus einer Geodatenbank deutlich länger dauert als das einfache Transferieren von Dateien vom Datenserver auf den Webserver. Dieser Zeitnachteil macht sich beim Benutzer selbst beim Aufrufen kleiner Karten negativ bemerkbar.

Export von Shapefiles und GeoTIFF Vektordaten werden als ESRI Shapefiles gespeichert. Hierbei handelt es sich um ein stark verbreitetes Vektorformat, das sich als Quasistandard durchgesetzt hat. Innerhalb einer ESRI Geodatenbank werden Vektordaten als sogenannte Feature Classes oder Feature Datasets (mehrere Feature Classes kombiniert) gespeichert. Rasterdaten werden im GeoTIFF-Format gespeichert. Dieses Format ist verwandt mit dem bekannten Grafikformat TIFF, wurde jedoch durch Informationen zur Georeferenzierung erweitert. Innerhalb einer ESRI Geodatenbank werden Rasterdaten als Raster Datasets oder Raster Catalogs (mehrere Rasterbilder) verwaltet.

Um Shapefiles oder GeoTIFF zu exportieren, übergibt man einer Methode der Klasse Geodatabase den relativen Pfad zur Geodatenbank, welche die gewünschten Daten enthält, eine durch Semikolon getrennte Liste der Namen der zu exportierenden Datensätze sowie den Identifikator des Metadatensatzes. Letzterer ist für den Export eigentlich nicht notwendig, kann jedoch in einen eindeutigen Namen für das Zielverzeichnis umgewandelt werden. Da alle Dateien in das Verzeichnis hidden auf dem Webserver gespeichert werden (siehe Kapitel 3.3.2), kann so verhindert werden, dass versehentlich Dateien gleichen Namens überschrieben werden, die aus einem anderen Export stammen. Ohne Umwandlung kann der Identifikator jedoch nicht verwendet werden, da Pfadangaben in ArcObjects, die Leerzeichen, Doppelpunkte oder Punkte enthalten, zu Fehlern führen können. Die kritischen Zeichen werden hier durch Unterstriche ersetzt.

Bevor ArcObjects verwendet werden kann, muss zunächst einmal die ArcGIS Engine Runtime initialisiert werden. Hierbei wird unter anderem überprüft, ob eine gültige Lizenz vorliegt. Danach wird ein sogenannter Geoprozessor erzeugt, der in ArcObjects für die Verarbeitung von Geodaten zuständig ist. Mit dem Geoprozessor können spezialisierte Werkzeuge ausgeführt werden, die als Javaobjekte realisiert sind. Bevor der Export durchgeführt werden kann, wird noch für jeden Datensatz der zugehörige Typ aus der Datenbank ausgelesen. Anhand dieses Typs (Feature Class, Feature Dataset, Raster Dataset usw.) wird nun festgestellt, ob der Datensatz als Shapefile oder als GeoTIFF exportiert werden muss. Für Shapefiles kennt der Geoprozessor das Werkzeug FeatureClassToShapefile, dem die Features und das Zielverzeichnis übergeben


84

werden und das dann den Export durchführt. Die erzeugten Shapefiles tragen automatisch die Namen der Datensätze in der Datenbank. Den Export als GeoTIFF kann man mit dem Werkzeug CopyRaster durchführen, welches ebenfalls mit dem Geoprozessor ausgeführt werden kann. Dem Objekt wird der Name des Datensatzes (bei Rasterkatalogen kann man die einzelnen Rasterbilder über eine fortlaufende ID ansprechen), das Zielverzeichnis und der Zielname übergeben. Als Zielname wird der Namen des Datensatzes verwendet (bei Katalogen mit angehängter fortlaufender Nummer). Als Dateiendung muss .tif gewählt werden, dann wählt ArcObjects als Exportformat automatisch GeoTIFF aus.

Export von XML-Workspaces Um beliebige Datensätze aus einer ESRI Geodatenbank in eine andere zu überführen, stellt ESRI ein Austauschformat bereit, das alle Eigenschaften der Datensätze in einem XML-Format enthält. Dieses Austauschformat heißt XML-Workspace und wird nur von ESRI-Software unterstützt. Wenn die Geoportal-Nutzer jedoch mit ESRI-Software arbeiten, können sie über dieses Format viele Datensätze aus den Geodatenbanken des Geoportals in ihr lokales Programm übernehmen. Ein XML-Workspace unterstützt nicht nur Datensätze, die Vektor- oder Rasterdaten repräsentieren, sondern beispielsweise auch solche Datensätze, die Beziehungen zwischen anderen Datensätzen beschreiben. Über den Export eines XML-Workspaces können also mehr Informationen aus der Datenbank exportiert werden, als beim Export als Shapefile oder GeoTIFF.

Um einen XML-Workspace zu exportieren, übergibt man einer anderen Methode der Klasse Geodatabase die gleichen Parameter, wie der zuvor beschriebenen Methode (s.o.). Da hier jedoch nur eine einzelne Datei exportiert wird, dient der Identifikator hier nicht als Verzeichnis- sondern als Dateiname. Als Zielverzeichnis für den Export wird das über den Webserver zugreifbare, benutzerspezifische Verzeichnis verwendet, das bereits von den Downloadern bekannt ist. Dies ist logisch, da ein XML-Workspace ausschließlich für den Download verwendet werden kann, der UMN MapServer kann ihn nicht für die Visualisierung nutzen.

Auch hier wird zunächst die ArcGIS Engine Runtime initialisiert und somit die Lizenz geprüft. Auf das Erzeugen des Geoprozessors oder das Prüfen des Datensatztyps kann jedoch verzichtet werden, weil ersterer beim XML-Workspace-Export nicht verwendet wird und letzteres unnötig ist, da jeder Typ exportiert wird. Vereinfacht dargestellt, läuft der Export als XML-Workspace wie folgt ab: Zunächst wird die Datenbank geöffnet und alle Datensätze, die den übergebenen Datensatznamen entsprechen, werden einer speziellen Liste hinzugefügt. Dem Objekt GdbExporter von ArcObjects wird diese Liste übergeben. Außerdem werden der Zielpfad und der Dateiname angegeben. Mit zusätzlichen Parametern kann nun beispielsweise noch festgelegt werden, ob der XML-Workspace bereits beim Export komprimiert werden soll. Dies hat den Vorteil, dass so auch Rasterdaten gemeinsam mit den XML-Daten in einer ZIP-Datei zusammengefasst werden. Die Rasterdaten würden sonst in einem separaten Verzeichnis abgelegt. Außerdem reduziert sich so die Größe des Downloads.

3.3.9 Benutzerkommunikation Ein Geoportal dient als zentraler Anlaufpunkt, um Geodaten und andere Ressourcen zu finden. Es kann – wie im Fall des GLOWA Volta Geoportals – eine bestimmte Kernzielgruppe haben, für die es hauptsächlich gedacht ist. Dies sind beispielsweise Projektmitglieder oder Personen, die an Projektergebnissen interessiert sind. Diesem Personenkreis kann ein Geoportal die Möglichkeit


85

bieten, sich untereinander auszutauschen oder gemeinsame Projektereignisse zu planen. In diesem Kapitel werden zudem zusätzliche Informationsseiten beschrieben, die dem Benutzer nur Informationen zukommen lassen, die aber keine Rückantwortmöglichkeit bieten.

Terminplaner Der Terminplaner („Meeting Planner“) des GLOWA Volta Geoportals dient als Beispiel für das Planen von Projektereignissen. Weitere Funktionen dieser Art bietet das Geoportal nicht, da diese Funktionalität später, wenn das Portal in Afrika zum Einsatz kommt, voraussichtlich nicht mehr benötigt wird. Es ist jedoch denkbar, den Terminplaner in seinem Funktionsumfang noch zu erweitern oder dem Portal andere Komponenten mit neuer Funktionalität hinzuzufügen, falls dies erforderlich werden sollte.

Um den Terminplaner zu nutzen, muss sich der Benutzer am Portal angemeldet haben. Benutzer die der Gruppe meetingadmins angehören, können neue Treffen („meetings“) erzeugen oder bestehende bearbeiten. Zu einem Treffen gehören ein Name, eine Beschreibung, ein Ort sowie ein oder mehrere Start- und Endzeiten. Außerdem kann ausgewählt werden, welche Benutzer zu diesem Treffen eingeladen werden sollen. Auf Wunsch des Administrators kann das Geoportal an alle eingeladenen Benutzer eine Benachrichtigung per E-Mail schicken. Hierfür wird die Java-Bibliothek JavaMail verwendet. Die Benutzer können sich dann beim Geoportal anmelden und bei mehreren Start- und Endzeiten für eine abstimmen, die für sie am Besten geeignet ist. Dies ist solange möglich, bis der Administrator den Status des Treffens auf „final“ setzt. Dann ist keine Stimmabgabe mehr möglich. Nun kann der Administrator sich für einen der angegebenen Termine entscheiden, wobei er nicht an den Termin mit der höchsten Stimmenanzahl gebunden ist, und per E-Mail eine automatisch generierte Einladung an alle eingeladenen Benutzer verschicken.

*

*

*

**

**+


* On Delete Cascade Referenz

+ On Delete Cascade Referenz mit Benutzertabelle

** On Delete No Action Referenz

*

*

*

**

**+









Abbildung 3.16 Übersicht über das Datenbankschema des Terminplaners

Auch der Terminplaner ist als MVC-Komponente aufgebaut. Er besteht aus mehreren JSP-Dateien, die in einem Verzeichnis zusammengefasst wurden, sowie aus zwei Javaklassen, die in einem Package zusammengefasst wurden. Die meisten JSP-Seiten sind Präsentationen und bieten dem Benutzer die verschiedenen Informationen und Eingabemöglichkeiten des Terminplaners an (Übersicht über alle Treffen des aktuellen Benutzers, Administration der Treffen, Abstimmen für eine konkrete Zeit, Editieren eines Treffens). Eine JSP-Seite nimmt die Benutzereingaben entgegen, sie gehört also zur Steuerung. Die Benutzereingaben werden an die Klasse


86

MeetingPlanner weitergegeben, welche die eigentliche Anwendungslogik des Terminplaners enthält. Außerdem ist sie für den Zugriff auf die Datenbanktabellen des Terminplaners zuständig. Innerhalb von Java wird ein Termin in dem Objekt Meeting verwaltet, das alle Informationen enthält, die es zu einem Treffen gibt. Den Abgleich mit der Datenbank übernimmt die MeetingPlanner-Klasse. Die Datenbanktabellen und das Meeting-Objekt stellen das Datenmodell dar.

Die Datenbanktabellen des Terminplaners sind wie folgt aufgebaut: In der Tabelle portal_meetings werden alle Treffen verwaltet. Hier werden Name, Beschreibung, Ort und der Finalstatus für jedes einzelne Treffen abgelegt. Die Start- und Endzeiten werden separat in der Tabelle portal_meetingdates verwaltet. Über eine Fremdschlüsselbeziehung werden diese einzelnen Termine dem zugehörigen Treffen aus der Tabelle portal_meetings zugeordnet. Die eingeladenen Benutzer werden ebenfalls in einer separaten Tabelle verwaltet (portal_userinmeeting), die über Fremdschlüsselbeziehungen mit den jeweiligen Treffen und den Benutzern aus der Benutzerverwaltung des Geoportals verknüpft ist. Letzteres verhindert, dass nicht existierende Benutzer zu einem Termin eingeladen werden können. In der Tabelle portal_userinmeeting wird zudem noch abgelegt, ob ein Benutzer für einen bestimmten Termin abgestimmt hat. Sobald er abgestimmt hat, wird eine Fremdschlüsselbeziehung zum ausgewählten Termin in der Tabelle portal_meetingdates eingetragen. So wird sowohl verhindert, dass ein Benutzer für nichtexistente Termine abstimmen kann, als auch dass ein Benutzer für mehr als einen Termin abstimmen kann.

Informationsseiten In vielen Geoportalen ist es üblich, dem Benutzer neben einer Suchmöglichkeit im Metadatenkatalog und einer Visualisierung von Karten auch zusätzliche informative Texte beliebigen Inhalts zur Verfügung zu stellen. Diese Texte können beispielsweise Informationen zu ausgewählten Themen enthalten, die einem neuen Benutzer einen leichten Einstieg in dieses Thema ermöglichen. Hierüber können zudem die, bereits in Kapitel 2.4.2 erwähnten, Kanäle realisiert werden. Es ist außerdem möglich, die Texte mit Einträgen aus der Metadatenbank zu verknüpfen.

Die Informationsseiten des GLOWA Volta Geoportals sind sehr einfach gehalten und bieten nur einen geringen Funktionsumfang. Sie werden über einen Eintrag in der Menüleiste aufgerufen und zeigen zunächst ein Inhaltsverzeichnis an, in dem sich ein bestimmtes Thema auswählen lässt. Der Inhalt der dort ausgewählten Seite wird dem Benutzer dann angezeigt, jedoch kann man auch Seiten anlegen, die nicht im Inhaltsverzeichnis gelistet werden, um Unterseiten zu ermöglichen. Auf einer Administrationsseite kann ein Benutzer mit Administratorrechten neue Informationsseiten anlegen oder existierende löschen. Der Inhalt einer neuen Seite muss in Form von HTML-Code eingegeben werden, da das Geoportal nicht über einen integrierten HTML-Editor verfügt. Verknüpfungen zu Metadateneinträgen erstellt man, in dem man einen Link auf den passenden Viewer setzt und dabei den gewünschten Identifikator als Parameter übergibt. Dieser benötigte Link wird in jedem Viewer als „Permanent Link“ angezeigt.

Auch der Informationsviewer ist nach dem MVC-Prinzip aufgebaut. Die JSP-Seiten liegen in einem eigenen Verzeichnis. Die Seiten zur Anzeige der Informationsseiten und zur Anzeige des Administrationsmenüs stellen die Präsentationen dar. In einem eigenen Java-Package liegen zwei Javaklassen, von denen die eine für den Zugriff auf die Datenbanktabelle zuständig ist (InformationMgmt). Sie stellt, gemeinsam mit der JSP-Seite, die Benutzereingaben für die


87

Administration entgegennimmt, die Steuerung dar. Die Datenbanktabelle selbst und die Javaklasse Information, welche die Informationsseiten unter Java repräsentiert, entsprechen dem Datenmodell.

PrimärschlüsselPrimärschlüsselPrimärschlüssel

Abbildung 3.17 Übersicht über das Datenbankschema der Informationsseiten

Die Datenbanktabelle und ein Information-Objekt enthalten zunächst eine eindeutige ID, über die eine bestimmte Seite angesprochen werden kann. Außerdem gibt es für jede Seite einen Titel, der als Überschrift und als Eintrag im Inhaltsverzeichnis dient. Ob der Titel überhaupt im Inhaltsverzeichnis angezeigt werden soll, wird mit einem boolschen Wert für jede Seite individuell angegeben. Im Inhaltsverzeichnis kann zusätzlich zum Titel noch eine kurze Beschreibung angezeigt werden, die ebenfalls gespeichert wird. Die Reihenfolge im Inhaltsverzeichnis kann optional über einen Zahlenwert festgelegt werden. Der eigentliche Inhalt der Seite wird in Form von HTML-Code gespeichert.

Wenn der Funktionsumfang der Informationsseiten des Geoportals nicht ausreicht, zum Beispiel wenn der fehlende HTML-Editor stört, kann der Informationsviewer durch einen anderen ersetzt werden. Am einfachsten ist hier die Installation eines separaten Content Management Systems (CMS), das die gleichen Aufgaben wie der Informationsviewer erfüllt. In der Konfigurationsdatei des Geoportals kann nun die URL des CMS angegeben werden, um den integrierten Informationsviewer zu ersetzten. Dies funktioniert auch mit beliebigen anderen Webseiten, die Informationen bereitstellen können. Es ist natürlich alternativ möglich, den Funktionsumfang des existierenden Viewers zu erweitern.

Wiki, Chat und Forum In diesem Abschnitt werden weitere Möglichkeiten der Benutzerkommunikation kurz vorgestellt, die man dem Geoportal hinzufügen könnte. Dies wurde jedoch bislang nicht getan, es handelt sich somit nur um Gedankenspiele, die realisiert werden könnten, falls die Benutzer entsprechende Bedürfnisse äußern sollten.

Ein Wiki ist eine Möglichkeit der Benutzerkommunikation, die man dem Geoportal hinzufügen könnte. Hierbei schreiben mehrere Benutzer gemeinsam am Inhalt von Webseiten, mit der Möglichkeit, sie auch untereinander zu verknüpfen. Wikis kann man beispielsweise nutzen, um gemeinsam eine Dokumentation oder inhaltliche Texte zu bestimmten Themen zu schreiben, die auch Links auf Seiten des Geoportals enthalten könnten. Hierfür müssen die Benutzer sich jedoch selbst organisieren, da ein Wiki hier nur sehr wenig vorgibt; die inhaltliche und strukturelle Ausprägung des Wikis wird durch die teilnehmenden Benutzer bestimmt. Dass dies funktionieren und zu einem guten Ergebnis führen kann, sieht man beispielsweise an der Wikipedia, dem wohl bekanntesten Wiki. Man könnte ein Wiki auf dem Webserver installieren und dann vom Geoportal aus einen Link dorthin setzen, um es einzubinden.


88

Eine weitere Form der Benutzerkommunikation könnte über Diskussionsforen stattfinden. Hier könnten die Benutzer Beträge schreiben, auf die andere Benutzer wiederum antworten könnten. Die Beiträge könnten nach Themen zusammengefasst werden, um einen leichteren Überblick zu erhalten. So könnten umfangreiche Diskussionen von interessierten Benutzern zu bestimmten Themen entstehen. Eine passende Software könnte ebenfalls auf dem Webserver installiert und im Geoportal verlinkt werden.

Eine Echtzeitkommunikation der Benutzer untereinander könnte ein webbasierter Chat ermöglichen, der im Geoportal verlinkt werden könnte. Hier könnten die Benutzer sich mit Textnachrichten über beliebige Themen des Geoportals austauschen. Wikis, Foren und Chats erfordern jedoch eine Moderation durch verantwortliche Personen, um einen Missbrauch der Funktionen zu vermeiden.

3.4 Zusammenfassung

Finales Implementierungskonzept der Architektur

Datenserver (+RAID)

Dateisystem(Samba)

ESRI-Geodata-

base

PostgreSQL:Meta-DB

Portal-DBMapbender-DB

WMS ClientWMS Client

BrowserBrowser

:80

:80

JDBC:5432

SMB

SMB

ESRI ArcGISClient

SMB

Netzwerkkarte 2

DMZ

Intranet

Internet

:80

Netzw

erkkarte 1

SSH ClientSSH Client

Webserver (VM)Apache

Tomcat

ArcGIS Engine RuntimeArcGIS Engine Runtime

SSH

:22

Mapbender

MapServer

PHP(CGI)

CGIWMS

MapViewer (vgl. u.)

JSP/JavaPortal

Downloader

Terminplaner, …Dat

aman

ager

(Met

adat

en, B

enut

zer,

Dat

enve

rarb

eitu

ng, …

)

Viewer(z.B. MapViewer, s.o.)

Abbildung 3.18 Architektur des Geoportals

Die Abbildung 3.18 zeigt das finale Implementierungskonzept der Architektur, die dem Geoportal zu Grunde liegt. Die Architektur besteht aus zwei separaten Servern, von denen einer virtualisiert werden kann. Der Datenserver hält die Daten im Dateisystem und in ESRI Geodatenbanken bereit. Ein RAID liefert hier den notwendigen Platz für große Datenmengen und die erforderliche Fehlersicherheit. Beides wird über Samba, sowohl im lokalen Intranet, als auch dem Webserver zugänglich gemacht (SMB-Protokoll). Im Gegensatz zu den üblichen relationalen Datenbanken gibt es für den Zugriff auf eine ESRI Geodatenbank kein spezielles

3.4 Zusammenfassung

89

Protokoll. Sie muss den ESRI Programmen (im Portal der ArcGIS Engine Runtime) über das Dateisystem zugänglich sein. Für die Metadaten, die Konfiguration von Mapbender und weitere Daten des Portals stellt der Datenserver ein PostgreSQL-Datenbankmanagementsystem bereit, das für jede der genannten Aufgaben eine eigene Datenbank verwalten kann.

Der Webserver läuft in einer Virtuellen Maschine auf dem Datenserver. Über eine virtuelle Netzwerkkarte kommunizieren die Server miteinander. An das Intranet ist der Datenserver über eine eigene Netzwerkkarte angeschlossen, die dem Webserver nicht zur Verfügung steht. Den Zugang zum Internet teilen sich der Datenserver und der Webserver über eine gemeinsame Netzwerkkarte. Der Datenserver ist aus dem Internet jedoch aus Sicherheitsgründen nur über SSH erreichbar.

In dem virtualisierten Webserver sieht man zunächst die beiden Serverdienste Apache und Tomcat, sowie die ArcGIS Engine Runtime. Letztere bietet dem Geoportal über eine Programmierschnittstelle Zugriff auf ESRIs Geodatenbanken, der sonst nicht möglich wäre. Tomcat bietet die Möglichkeit, JSP-Seiten und Java auszuführen und über das Internet zugänglich zu machen. In Tomcat läuft die eigentliche Portalsoftware mit dem Webinterface, dem Datamanager und allen mitgelieferten Komponenten. Der Datamanager kümmert sich um Aufgaben, wie die Verwaltung und Suche der Metadaten und die Benutzeridentifikation, außerdem stellt er den Komponenten Funktionen, wie das Verarbeiten der Daten, bereit.

Das Geoportal beinhaltet verschiedene Komponenten, die unterschiedliche Aufgaben für das Portal erfüllen. Sie bieten erweiterbare und austauschbare Funktionen zur Visualisierung von Daten, zum Download von Daten, zur Terminplanung und zur Anzeige von zusätzlichen Informationsseiten. Da das Geoportal webbasiert ist, kann es über Verknüpfungen zudem durch beliebige Webangebote erweitert werden. Die wichtigsten Komponenten sind die Visualisierungskomponenten, die dem Benutzer Metadaten und verschiedenen Arten von Daten anzeigen können. Hier ist die Komponente zur Kartenvisualisierung besonders hervorzuheben, die den größten Funktionsumfang bietet. Um Karten anzeigen zu können, greift sie auf zwei externe Programme zurück, die auf dem Apache-Webserver laufen. Der UMN MapServer bereitet Geodaten so auf, dass sie in einem normalen Webbrowser dargestellt werden können. Die Daten werden hier über den WMS-Standard bereitgestellt. Neben externen Clients für WMS kann dieser Dienst auch von speziellen webbasierten Oberflächen direkt im Browser des Benutzers verwendet werden. Eine solche Oberfläche stellt das PHP-Programm Mapbender bereit, mit dem der Benutzer die WMS-Dienste des UMN MapServers nutzen kann.

Insgesamt ergibt sich so ein Geoportal mit umfangreichen Funktionen, die zudem an spätere Bedürfnisse angepasst werden können. Durch die Verwendung von Open Source Software und anderer kostenloser Software kann das System zudem kostengünstig realisiert werden. Es wurde außerdem auf eine einfache Benutzbarkeit der Oberfläche geachtet.

Diverse Bibliotheken sind in der Grafik nicht aufgeführt, aber ebenfalls Bestandteil des Geoportals. Diese sind im Anhang 6.1 in der Liste der verwendeten Software mit aufgeführt. In den folgenden Abschnitten soll nun ein Überblick über die wichtigsten Funktionsweisen des Portals gegeben werden.

Ablaufschema zu Metadaten, Visualisierung und Download Die Funktionen des Geoportals sind recht umfangreich, weshalb in der Abbildung 3.19 noch einmal die wichtigsten Funktionen zur Verwendung von Metadaten, der Visualisierung mit Hilfe


90

von Viewern und den Downloadmöglichkeiten in Form eines Ablaufschemas zusammengefasst werden. Zur besseren Übersicht wurden in der Abbildung einige Funktionen weggelassen.

Parsing

XML-Datei

Gültigerneuer

Eintrag?

pro Eintrag

nein ja

In DBeinfügen

Über-springen

MetadatenHochladen

MetadatenEing./Bearb.

Neu?

Metadaten-formular

In DBeinfügen/überschr.

URN-Generator

ja

nein

URN

Daten

Layerauswahloder XML-Workspaces*

MetadatenBrowsing

MetadatenSuche

MetadatenErgebnisliste

DataViewer MapViewerGooglemaps

Viewer

Bearbeiten

Andere

Typ?

GoogleMaps Karten/Layer

Datenvorhan-

den?

AusführlicheMetadatenanzeigen,

externe Linksanzeigen,

Permanent-link anzeigen

Datenkopieren

ja

Data-Downloader

Evtl. kompr. u.bereitstellen

Übersicht

WMS ClientAnstoßen

Map Basketnein

GoogleMapanzeigen

Map-Downloader

Komprimierenu. bereitstellen N

ur n

ach

Ben

utze

raut

hent

ifika

tion

* Nur

für E

SRI G

DB

Nur

nac

hB

enut

zera

uthe

ntifi

katio

n

* Nur

für E

SRI G

DBWMS-Links

anzeigen Benutzen

Auswahl

Weitere Funktionen:z.B. Administration, Information, Meeting Planner, Hilfe, …

SucheAuswahl

Mapfile u.Daten kopieren,

Mapbenderkonfigurieren

Kartenhinzufügen

Abbildung 3.19 Ablaufschema zu Metadaten, Visualisierung und Download

Verarbeitung von Geodaten im und für das Portal In diesem Abschnitt wird beschrieben, welche Schritte notwendig sind, um Geodaten im Portal, in Form von Karten, anzeigen zu können. Zunächst müssen die Karten von den Datenproduzenten und den, für das Datenmanagement zuständigen, Personen erzeugt und auf ihre Korrektheit überprüft werden. Dies geschieht mit Hilfe des Programms ArcMap von ESRI. Von dort müssen nun alle Konfigurationsdateien für den UMN MapServer exportiert und in einem eigenen Verzeichnis auf dem Datenserver abgelegt werden. Der Export geschieht mit der Erweiterung AmeiN, so dass man die Dateien nicht selbst schreiben muss. Die Geodaten kann man dabei ebenfalls in ein Austauschformat exportieren und in einem separaten Verzeichnis auf dem Datenserver ablegen. Alternativ kann man die Daten in einer Geodatenbank auf dem Datenserver ablegen, von wo das Geoportal sie selbständig exportieren kann, sobald der MapServer sie für die Visualisierung benötigt. Auch der Download ist hier möglich. Die Lage der Daten auf dem Datenserver muss in den zugehörigen Metadaten vermerkt werden.

3.4 Zusammenfassung

91

Wenn der Benutzer über das Portal nun einen Metadatensatz ausgewählt hat, der mit einer Karte verknüpft ist, werden alle benötigten Dateien auf den Webserver transferiert (falls nötig: exportiert). Nun kann der MapServer sie als WMS-Dienst zur Verfügung stellen. Mapbender wird so konfiguriert, dass er diesen WMS-Dienst anzeigt und steuern kann. Es ist auch möglich, mehrere WMS-Dienste gleichzeitig anzuzeigen.

ArcGISSoftware

Erzeugen,Bearbeiten,Verifizieren

Erweiterung:Konvertierung Speicherung

WMS-Dienstbereitstellen Anzeigen

AmeiN Daten-server

Data-manager

Meta-DB-Zugriff,Transfer/ Export

Map-Server

Map-bender

Abbildung 3.20 Überblick über den Weg der Geodaten

4 Zusammenfassung und Ausblick

92


4.1 Erzielte Ergebnisse Das Ziel dieser Diplomarbeit war, wie bereits in Kapitel 1.2 beschrieben, die Entwicklung eines Geoportals für das GLOWA Volta Projekt. Hierbei sollten neben rein wissenschaftlichen Fragen zusätzlich auch die praktischen Anforderungen des ZEF berücksichtigt werden. In Anhang 6.12 werden einige Workflows aufgelistet, die von einem ZEF-Mitarbeiter aufgestellt wurden und die das Geoportal erfüllen sollte. Mit den implementierten Funktionen des Geoportals lassen sich alle genannten Workflows realisieren.

Im Rahmen dieser Diplomarbeit wurde eine lauffähige Implementierung des Geoportals entwickelt. Sie besteht aus der eigentlichen Portalsoftware, die aus einer webbasierten Benutzeroberfläche und dem Datamanager besteht. Hinzu kommen verschiedene Arten von Komponenten, um die Funktionalität der Portalsoftware zu erweitern. Insgesamt bietet das Geoportal die folgenden Funktionen an: Ausfallsichere Speicherung der Daten (Kapitel 3.3.1), Datenverarbeitung und –transfer mit dem Datamanager (Kapitel 3.3.2), Verwaltung von Metadaten zu diesen Daten (Kapitel 3.3.3), verschiedene Suchfunktionen zum Auffinden von Daten (Kapitel 3.3.4), Visualisierung der Daten (Kapitel 3.3.5), Download der Daten (Kapitel 3.3.7), grundlegende Möglichkeiten der Onlineanalyse (Kapitel 3.3.6), eine Benutzerverwaltung (Kapitel 3.3.2), ein Terminplaner, Verwaltung von Informationsseiten (beide Kapitel 3.3.9) und konfigurierbare Links für Verknüpfungen auf externe Webseiten und Seiten des Geoportals (Kapitel 3.3.2). Das Portal speichert seine Daten (Metadaten, Benutzerinformationen und andere) in Datenbanken ab, die von dem Open Source Datenbankmanagementsystem PostgreSQL verwaltet werden. Alle verwendeten Datenbanken werden als SQL-Schema in den Anhängen 6.4 und 6.7 detailliert dargestellt.

Für die Entwicklung des Geoportals wurden Java und JSP als Programmiersprachen eingesetzt. Die selbst entwickelte Software des Geoportal besteht insgesamt aus 5360 Zeilen JSP-Code (inklusive Kommentare und im Internet gezeigter Hilfetexte), sowie 12488 Zeilen Java-Code (inklusive Kommentare). Die Open Source Software Apache Tomcat wurde als Anwendungsserver zum Ausführen des JSP-Codes eingesetzt. Funktionen, die nicht die Benutzerinteraktion betreffen, wurden in Java programmiert. Sie werden ebenfalls von Tomcat ausgeführt. Die zur Kartenvisualisierung in das Portal integrierten Programme UMN MapServer und Mapbender benötigen zudem den Apache Webserver, um im Web verfügbar zu sein. Mapbender setzt zudem eine PHP-Laufzeitumgebung voraus. Mehr zur Integration von MapServer und Mapbender in das Portal findet man im Kapitel 3.3.5. Die genaue Struktur aller Dateien des Geoportals und ihre Bedeutung findet man in der Tabelle im Anhang 6.2. Die Funktionalität von Java wurde durch einige externe Bibliotheken erweitert, die gemeinsam mit allen verwendeten externen Programmen in der Tabelle im Anhang 6.1 aufgelistet sind.

Das entwickelte System wird bereits am ZEF für das GLOWA Volta Projekt eingesetzt. Es ist geplant, dass es zukünftig direkt in die Homepage des Projekts [Glow07] eingebunden werden soll. Bis dies geschehen ist, ist es noch unter der vorläufigen Webadresse http://131.220.109.6/Geoportal/index.jsp zu erreichen.

4.2 Bewertung der Ergebnisse

93

4.2 Bewertung der Ergebnisse In Kapitel 1.2 wurden die Ziele dieser Arbeit aufgestellt, die in diesem Kapitel noch einmal kurz zusammengefasst werden sollen. Zur besseren Übersichtlichkeit werden die Ziele in die drei Abschnitte „Architektur“, „Exploration, Navigation und Analyse“ sowie „Kommunikation und Austausch“ unterteilt.

• Architektur. Es sollte eine komponentenbasierte Architektur geschaffen werden, welche die Verwendung eigener und externer Programme ermöglicht. So soll eine Erweiterbarkeit geboten werden, um das Portal an zukünftige Anforderungen anpassen zu können. Auch die Sicherheit der Daten sollte in Bezug auf externe Angriffe gewährleistet werden. Außerdem sollte eine Benutzerverwaltung den Zugriff auf bestimmte Daten beschränken. Zudem sollten aus Kostengründen möglichst niedrige Lizenzkosten erreicht werden.

• Exploration, Navigation und Analyse. Es sollten Exploration und Navigation von Geodaten ermöglicht werden, die dem Benutzer durch das Portal angeboten werden. Außerdem sollten dem Benutzer grundlegende Funktionen zur Onlineanalyse zur Verfügung stehen. All dies soll es ermöglichen, gewünschte Informationen leicht finden und erfassen zu können.

• Kommunikation und Austausch. Es sollte die Distribution und der Austausch von Daten des Projekts über das Portal ermöglicht werden. Außerdem sollte die Kommunikation der Projektpartner und die Planung von Projektereignissen realisiert werden. Abschließend soll im Portal noch der Umgang mit unzuverlässigen und langsamen Internetanbindungen berücksichtigt werden.

In den folgenden Unterkapiteln werden die realisierten Funktionen des Geoportals noch einmal kurz zusammengefasst und anhand der zur Diplomarbeit gestellten Anforderungen bewertet. Unter den Mitarbeitern des ZEF wurde eine Umfrage zum GLOWA Volta Geoportal durchgeführt, deren Fragen und Ergebnisse im Anhang 6.11 zufinden sind. Auch diese Ergebnisse werden in diesen Kapiteln verwendet, wenn auf die Umfrage verwiesen wird. Im Anschluss an dieses Kapitel werden in Kapitel 4.3 mögliche Erweiterungen und Verbesserungen des Geoportals vorgeschlagen, die zukünftig realisiert werden könnten.

4.2.1 Architektur

Komponentenbasierter Ansatz Die gesamte Architektur des Geoportals ist komponentenbasiert. Unter einer Komponente versteht man hier Software, die dem eigentlichen Hauptprogramm modular hinzugefügt wurde, um dessen Funktionsumfang zu erweitern. Die Komponenten des Geoportals sind vollständig voneinander getrennt und nur über den Datamanager mit der eigentlichen Portalsoftware verbunden. Aufgerufen werden sie an geeigneter Stelle durch entsprechende Links. Diese Autonomie erlaubt es, die Komponenten auf einfache Weise gegen kompatible andere Komponenten auszutauschen oder neue Komponenten zu ergänzen.

Der Datamanager enthält die eigentliche Funktionalität der Portalsoftware, er übernimmt beispielsweise die Aufgaben der Benutzerverwaltung, der Verwaltung der Metadaten, des Datentransfers und andere. Dies wird in Kapitel 3.3.2 näher beschrieben. Die wichtigsten Komponenten sind die Viewer, mit denen man verschiedene Arten von Daten sowie die Metadaten im Browser des Benutzers darstellen kann. So gibt es einen Viewer für die Anzeige von Karten des Portals, einen für die Anzeige von Karten des GoogleMaps-Dienstes und einen


94

für beliebige Daten. Der Viewer für Karten verwendet zum Realisieren seiner komplexen Funktionen externe Programme, die in den Viewer eingebunden wurden. Hier werden der UMN MapServer zum internetkompatiblen Aufbereiten der Geodaten und Mapbender als Benutzeroberfläche zur Interaktion mit den als Geodienst angebotenen Geodaten verwendet. Mehr zu allen Viewern findet man in Kapitel 3.3.5. Der Viewer für Karten bietet zudem grundlegende Funktionen zur Onlineanalyse, die in Kapitel 3.3.6 näher betrachtet werden. Aus den Viewern heraus kann der Benutzer die sogenannten Downloader aufrufen, die dem Benutzer die entsprechenden Daten zum Herunterladen anbieten können. Sie werden in Kapitel 3.3.7 genauer betrachtet. Weitere Komponenten sind der Terminplaner, der die Verwaltung von Terminen im Projekt vereinfachen kann, sowie der Informationsviewer, der dem Benutzer Informationsseiten über projektspezifische Themen anzeigen kann. Beide werden in Kapitel 3.3.9 beschrieben.

Mit den Komponenten kann die Funktionalität der Portalsoftware flexibel erweitert werden, wie bereits beschrieben wurde (siehe Kapitel 3.2.4). Wenn neue Daten hinzukommen, kann ein neuer Viewer programmiert werden und über eine Konfigurationsdatei in das Geoportal eingebunden werden. Alternativ kann ein bestehender Viewer erweitert werden. Der Informationsviewer kann durch eine Einstellung in einer Konfigurationsdatei durch bessere Software zur Verwaltung von Informationen ersetzt werden. Auch der Terminplaner lässt sich durch eine Weiterentwicklung ersetzen. Die Verwendung von Komponenten ermöglicht somit eine vereinfachte Erweiterbarkeit des Portals, um es an spätere Anforderungen anzupassen. Die Komponenten – und hier im Besonderen die Viewer – stellen die wichtigste Erweiterungsmöglichkeit des Geoportals dar und wurden speziell für diesen Zweck in die Architektur integriert.

Die Portalsoftware und alle Komponenten des GLOWA Volta Geoportals sind nach dem Model-View-Controller-Prinzip aufgebaut. Die Funktionen sind logisch unterteilt nach Steuerungen und Datenmodellen (im Programm in der Regel Javaklassen) und Präsentationen (in der Regel JSP-Seiten), die man einzeln gegen andere austauschen kann. Deshalb ist es für einen Programmierer einfacher möglich, die vorhandene Funktionalität zu erweitern oder neue hinzuzufügen. Außerdem ist es durch die Trennung möglich, gleiche Funktionalität an verschiedenen Stellen des Programms wieder zu verwenden. Mehr zum Model-View-Controller-Ansatz findet man in Kapitel 3.2.4. Die Aufteilung nach dem MVC-Ansatz ermöglicht bereits eine vereinfachte Anpassung des Portals an zukünftige Anforderungen. Außerdem wird durch die logische Struktur auch die Fehlersuche und Wartbarkeit des Codes erleichtert. Während der Entwicklungsarbeit zeigte sich bereits, dass eine Erweiterung der bestehenden Funktionalität durch diesen Ansatz deutlich vereinfacht wird. Dies verdeutlicht am Besten der alternative Viewer für Karten, der dem bestehenden Viewer für Karten beigefügt wurde. Er verwendet die gleiche Steuerung und die gleichen Datenmodelle wie der bestehende Viewer, jedoch wurde eine neue Präsentation erzeugt, die keine Funktion zum gemeinsamen Betrachten mehrerer Karten anbietet. Dies vereinfacht beispielsweise den Aufruf von Übersichtskarten, die nicht mit zusätzlichen Karten kombiniert werden sollen. Die restlichen Funktionen konnten übernommen werden, wodurch ein großer Programmieraufwand eingespart wurde.

Da das Geoportal ein Webangebot ist, lassen sich zukünftig zudem beliebige andere Webseiten in das Geoportal einbinden, um somit dessen Funktionalität zu erhöhen. Beispiele hierfür könnten Einrichtungen zur Kommunikation von Benutzern untereinander sein. Das Portal bietet hierfür konfigurierbare Links an, andere Schnittstellen für weitere Komponenten gibt es jedoch nicht. Insgesamt ergibt sich eine flexible Architektur, die auf die vorgestellten vielfältigen Arten an


95

zukünftige Erweiterungen angepasst werden kann und die Wartung und Fehlersuche im Code erleichtert.

Erweiterbare Metadatenbank Speziell für das Geoportal wurde eine eigene Metadatenbank entwickelt. Sie ermöglicht alle Suchanfragen an das Portal, wie in Kapitel 4.2.2 noch weiter betrachtet wird. Die Datenbank wurde so entwickelt, dass sie sich optimal in das Geoportal einfügt. Bei einer externen Lösung (M³Cat, siehe Kapitel 3.3.3) stellte sich heraus, dass es Probleme beim Zugriff des Geoportals auf deren Metadaten gibt. Die verfügbare Funktionalität der Metadatenbank entspricht den Vorgaben der verantwortlichen Personen am ZEF. Details zur Verwaltung der Metadaten im Portal findet man in Kapitel 3.3.3. Das entworfene SQL-Schema für die Metadatenbank ist in Anhang 6.7 aufgelistet. Es basiert auf dem Dublin Core Standard und bietet die Möglichkeit an, nachträglich zusätzliche Elemente zum Metadatenschema hinzuzufügen oder vorhandene Elemente zu entfernen. So kann die Metadatenbank leicht an spätere Anforderungen angepasst werden, jedoch gibt es für diesen Vorgang keine ins Portal integrierte Benutzeroberfläche, sondern es ist ein direkter Zugriff auf die Datenbank notwendig. Während der Entwicklung des Geoportals wurden bereits des Öfteren neue Elemente zur Datenbank hinzugefügt. Der Vorgang ist somit erprobt und funktionstüchtig. Dies führt ebenfalls dazu, dass das Geoportal gut an zukünftige Anforderungen anpassbar ist.

Sicherheit und Zugriffsrechte Das GLOWA Volta Geoportal soll die Daten vor externen Angriffen schützen. Außerdem soll der Zugriff auf einige Daten beschränkt werden. In das Geoportal wurde hierfür eine Benutzerverwaltung integriert, die das Herunterladen von Daten auf ausgewählte Benutzer und Gruppen beschränkt, die in den zugehörigen Metadaten angegeben werden können. Auch die Administration des Geoportals, das Verwalten von Metadaten und der Terminplaner werden über die Benutzerverwaltung beschränkt (Kapitel 3.3.2). Das Hochladen von Daten auf den Datenserver ist auf Benutzer beschränkt, die entsprechende Konten auf dem Server besitzen. Die restliche Funktionalität steht allen Benutzern offen. Alle realisierten Beschränkungen über Zugriffsrechte entsprechen den Anforderungen des ZEF, so dass mit der eingesetzten Benutzerverwaltung das vorgegebene Ziel der geeigneten Zugriffsbeschränkung auf die Daten erreicht wird. Die Verwendung der Benutzerverwaltung zur Beschränkung der genannten weiteren Funktionen geht sogar über das vorrangige Ziel zum reinen Schützen von Daten hinaus.

Neben der Benutzerverwaltung wurden im Geoportal weitere Sicherheitsaspekte beachtet. So wurde der Server, auf dem die Daten gespeichert werden (Datenserver), von dem Server getrennt, auf dem das Geoportal läuft (Webserver). Der Datenserver ist nicht direkt aus dem Internet erreichbar (außer per SSH, falls eine Fernwartung erforderlich ist), so dass er keinen direkten Angriffen ausgesetzt sein kann. Die benötigten Daten müssen so jedoch vor der Nutzung auf den Webserver transferiert werden. Die hierfür benötigten Transferfunktionen wurden in das Geoportal integriert. Der Ansatz, mit getrennten Servern zu agieren, ist jedoch nicht absolut sicher, weil dennoch eine Verbindung zwischen dem Datenserver und dem Webserver besteht, die bei einer Kompromittierung des Webservers aus dem Internet zum Entwenden von Daten genutzt werden könnte. Verbesserungsmöglichkeiten zeigt Kapitel 4.3 auf, jedoch kann es bei Angeboten, die im Internet bereitstehen, keine absolute Sicherheit geben. Die über Virtualisierung realisierte Trennung in einen Datenserver und einen Webserver bietet jedoch einen möglichst guten Schutz vor dem Diebstahl der Daten, wie es in den Zielen gefordert wurde.


96

Im Intranet kann der separate Datenserver zudem auch zum Speichern weiterer Daten genutzt werden, die nicht über das Geoportal zugänglich sein sollen. Diese Möglichkeit wäre bei einer Lösung mit nur einem Webserver aus Gründen der Datensicherheit nicht empfehlenswert. Der Datenserver erfüllt somit noch einen weiteren Zweck, der über die gesetzten Ziele hinausgeht.

Geringe Lizenzkosten Wenn das Geoportal später in Afrika zum Einsatz kommt, dann sollen möglichst geringe Lizenzkosten anfallen. Auch für den Betrieb am ZEF ist dies sinnvoll, um sparsam mit Projektmitteln umzugehen. So kam im Geoportal nur selbst entwickelte oder kostenlose (in der Regel Open Source) Software zum Einsatz, wie der Tabelle im Anhang 6.1 zu entnehmen ist. Die aktuelle Version der Geoportal-Software wurde für ein Windows-Betriebssystem entwickelt, ist aber betriebssystemunabhängig und kann somit auch unter anderen kostenlos verfügbaren Betriebsystemen, wie Linux, verwendet werden. Die einzige im Geoportal verwendete nicht kostenlose Software ist die ArcGIS Engine Runtime. Auf diese Software kann jedoch nicht verzichtet werden, da sie die einzige Möglichkeit für den Zugriff auf ESRIs Geodatenbanken darstellt, die vom ZEF gefordert wurde. Über eine Konfigurationsdatei kann die Verwendung von ESRI Geodatenbanken im Geoportal abgeschaltet werden, falls die Lizenzkosten für ArcGIS Engine Runtime später eingespart werden müssen. Das Ziel wird somit erreicht, dass durch das Portal möglichst geringe Lizenzkosten entstehen sollen.

Stabilität und Erreichbarkeit Ob das Geoportal später gut erreichbar sein wird, hängt stark von der späteren Wartung und Anbindung an das Internet ab. Das Geoportal selbst hat keine bekannten Stabilitätsprobleme, die zu einem Ausfall des Systems führen könnten. Eine Ausnahme stellt jedoch die eingebundene ArcGIS Engine Runtime dar, die in Tests wiederholt durch instabiles Verhalten aufgefallen ist. Bei einem Absturz dieser Bibliothek wird nicht nur der aufrufende Thread, sondern Tomcat und somit das gesamte Geoportal beendet. Da es sich bei ArcGIS Engine Runtime um proprietäre Software handelt, kann die Instabilität nur vom Hersteller beseitigt werden. Für das Geoportal wird ein Skript vorgeschlagen, das ein unerwünscht beendetes Geoportal automatisch neu startet. So kann die Ausfallzeit nach einem Absturz minimiert werden. Alternativ kann von der Verwendung der ArcGIS Engine Runtime abgesehen werden, was jedoch den Zugriff auf ESRI Geodatenbanken aus dem Portal heraus unmöglich machen würde. Dies ist von den Verantwortlichen im ZEF aber nicht gewünscht. Das Geoportal bietet somit unter den gegebenen Umständen eine möglichst gute Stabilität und Erreichbarkeit.

4.2.2 Exploration, Navigation und Analyse

Suchfunktionen Das Geoportal vereinfacht die Suche nach Daten, da das bislang notwendige Nachfragen bei Mitarbeitern, die im Besitz der Daten sind, somit wegfallen kann (vgl. Kapitel 1.1). Das Geoportal enthält alle Daten und bietet verschiedene Suchfunktionen an, um diese auffinden zu können (Kapitel 3.3.4). Die Daten werden jedoch nicht direkt durchsucht, die Suchfunktionen wurden stattdessen mithilfe einer Metadatenbank implementiert. Die Daten werden mit zusätzlichen Informationen beschrieben, die in Form von Metadaten in dieser speziellen Datenbank abgelegt werden. Für die Suche in der Metadatenbank stellt das Portal verschiedene Möglichkeiten bereit. So sind eine Standardsuche, eine erweiterte Suche in allen geeigneten


97

Metadatenelementen und eine Koordinatensuche vorhanden. Hinzu kommt die Möglichkeit, durch eine Liste aller Metadateneinträge zu blättern. Diese Liste kann zudem auf einzelne Themen beschränkt werden, um die Anzahl der Ergebnisse zu reduzieren.

Die Verwendung der Metadatenbank für die Suche hat den Nachteil, dass nicht die eigentlichen Daten durchsucht werden, sondern nur die Informationen, die in den Metadaten beschrieben wurden. Bei räumlichen Anfragen werden so beispielsweise keine Objekte innerhalb einer Karte gefunden, da nur vollständige Datensätze als Ganzes erfasst werden. Der Vorteil dieser Lösung ist jedoch, dass neben georeferenzierten Daten auch nicht georeferenzierte Daten von der Suche erfasst werden, wie beispielsweise Textdokumente oder Tabellen. Auch externe Ressourcen können so durch Metadaten beschrieben und über die angegebenen Suchfunktionen gefunden werden. Diese Möglichkeiten waren eine Anforderung, die vom ZEF an das Geoportal gestellt wurde und die somit erfüllt wird.

Als mögliche Erweiterung zu der Metadatenbank könnte eine richtige Geodatenbank, wie PostGIS, in das Portal eingebunden werden. Die Suche würde so nicht nur vollständige Datensätze erfassen, sondern es wäre auch eine Suche innerhalb der Datensätze möglich. So könnte man beispielsweise einzelne Objekte in aufgerufenen Vektorkarten finden, deren Koordinaten in der Geodatenbank separat von denen der Gesamtkarte verfügbar wären. Nicht georeferenzierte Daten würden jedoch von einer Geodatenbank nicht erfasst, so dass die Suche hier separat über eine zusätzliche Metadatenbank realisiert werden müsste. Die Implementierung der Suchfunktionen würde somit deutlich erschwert. Die Vorteile einer speziellen Geodatenbank beschränken sich zudem nur auf die Verwendung von Vektordaten, die in einzelne Objekte unterteilt werden können; bei Rasterdaten ist dies nicht der Fall, da diese wie eine Grafik nur aus einzelnen Pixeln aufgebaut sind.

Wie man in der Umfrage unter ZEF-Mitarbeitern deutlich erkennen kann, wird vor allem die einfache Standardsuche bevorzugt. Am wenigsten wichtig wird die Möglichkeit angesehen, durch eine Liste aller Metadateneinträge blättern zu können, was bei einem großen Datenbestand auch den größten Aufwand bedeuten würde und nur eine Zusatzfunktion für Ausnahmefälle darstellt. Auch die Möglichkeit, diese Gesamtliste auf einzelne Themen einzuschränken, wird als weniger wichtig erachtet. Mit den genannten Suchfunktionen bietet das Geoportal umfangreiche Möglichkeiten an, damit der Benutzer gesuchte Geodaten durch die Eingabe von Stichwörtern oder Koordinaten finden kann. Laut der Umfrage würden die Mitarbeiter bei der Koordinatensuche, anstatt der Eingabe der Koordinaten, eine grafische Auswahl anhand einer Karte bevorzugen. Das bietet das Geoportal jedoch nicht an, stattdessen müssen die Koordinaten in Form von Zahlenwerten eingegeben werden. Dies stellt jedoch nur eine Komforteinbuße dar, die Suche selbst ist trotzdem möglich. Tests mit Beispieleinträgen haben gezeigt, dass die angebotenen Suchfunktionen das Auffinden von bestimmten Datensätzen wie gewünscht ermöglichen. Zusammengenommen bietet das Geoportal, mit den genannten Einschränkungen, alle von den ZEF-Mitarbeitern gewünschten Suchfunktionen an, so dass das Auffinden von Daten über das Geoportal gut möglich ist.

Präsentation der Suchergebnisse und visuelle Darstellung Zu einer brauchbaren Suche gehört auch eine Präsentation der Suchergebnisse, die dem Benutzer eine gute Auswertung der Ergebnisse ermöglicht. Hierfür bietet das Geoportal zunächst die Auflistung aller Ergebnisse einer Suchanfrage in Form einer textbasierten Liste an. Diese Liste besteht aus einer Auswahl von Metadatenelementen. Sie dient dem Benutzer als erstes


98

Entscheidungskriterium über den Erfolg der Suche. Für einzelne Ergebnisse, die aus der Liste ausgewählt werden können, werden dann die vollständigen Metadaten angezeigt. Außerdem ist für Karten des Portals und des GoogleMaps-Dienstes eine visuelle Darstellung direkt im Browser des Benutzers möglich. Nicht georeferenzierte Dateien können dargestellt werden, wenn der Browser des Benutzers das entsprechende Format unterstützt.

In der Liste aller Suchergebnisse werden pro Eintrag Titel, zeitliche und räumliche Abdeckung der Daten, verantwortliche Personen, Qualität der Daten und Beschreibungen angezeigt. Außerdem kann von jedem Eintrag aus der passende Viewer aufgerufen werden, der die vollständigen Metadaten und eventuell verknüpfte Daten anzeigt. Als mögliche Alternative zu dieser Präsentation könnten die Suchergebnisse auch in Form von Vorschaugrafiken angezeigt werden. Je nach Umfang der Ergebnismenge müssten hier aber sehr viele Daten übertragen werden, da Grafiken größer sind als reine Textinformationen, was dem in Kapitel 4.2.3 näher betrachteten Ziel der geringen Netzwerklast widersprechen würde. Grafiken könnten dem Benutzer jedoch einen guten visuellen Überblick über die gefundenen Daten bieten, solange diese eine grafische Repräsentation erlauben. Letztes wäre bei Textdokumenten beispielsweise nicht der Fall. Bei einer reinen grafischen Darstellung würden zudem Informationen fehlen, die dem Benutzer nur in Form von Text dargestellt werden könnten. Als Beispiel kann hier die zeitliche Abdeckung der Daten genannt werden. Eine Kombination aus textbasierten und grafischen Ergebnislisten könnte das Problem teilweise beheben, jedoch würde hier mehr Platz pro Ergebnis benötigt, was die Übersichtlichkeit wieder einschränken würde. In beiden Lösungen mit Grafiken bestünde zudem das Problem, dass die Vorschaubilder aus den eigentlichen Daten generiert werden müssten.

Die Umfrage bestätigt, dass die verwendete visuelle Darstellung fast allen ZEF-Mitarbeitern als Suchergebnis ausreicht. Die Präsentation der Suchergebnisse im Geoportal ist somit gut geeignet, um dem Benutzter die Auswertung der Ergebnisse anhand der angezeigten Informationen zu ermöglichen. Dies trägt gemeinsam mit den entwickelten Suchmöglichkeiten dazu bei, dass das Auffinden von Daten über das Geoportal gut möglich ist.

Der Benutzer soll mit dem Geoportal die gefundenen Geodaten direkt visuell erkunden können. Für räumliche Daten ist eine visuelle Darstellung besser geeignet, als zum Beispiel eine Textliste. Hierzu ist es erforderlich, dass die Geodaten des Portals direkt visuell im Browser des Benutzers in Form einer Karte betrachtet und ausgewertet werden können. Das Geoportal bietet hierfür den Viewer zur Anzeige von Karten (MapViewer) an. Der MapViewer ermöglicht es, eine oder mehrere Karten in der Benutzeroberfläche Mapbender darzustellen und sie dort interaktiv zu nutzen (Kapitel 3.3.5). Der DataViewer zeigt nur die Metadaten an und ermöglicht den Aufruf des DataDownloaders, um verknüpfte Daten herunter zu laden oder bei kompatiblen Formaten direkt im Browser anzuzeigen. Der GooglemapsViewer zeigt Karten des GoogleMaps-Dienstes an. Diese Viewer ermöglichen somit zusätzliche Funktionen, die über die Darstellung der vom Portal selbst angebotenen Geodaten in Form von interaktiven Karten hinausgehen.

Der Umfrage zufolge sind den ZEF-Mitarbeitern die folgenden Funktionen der Kartenoberfläche am wichtigsten: Verschieben des Kartenausschnitts, Zoomen, Ebenen aktivieren / deaktivieren, Links von ausgewählten Kartenobjekten folgen (realisiert über Querying) und Anzeige der Legende. Alle diese Funktionen bietet der MapViewer an. Ebenfalls wichtig ist den Mitarbeitern die Funktion, die zu der aktuellen Karte gehörenden Geodaten herunterladen zu können. Dies wurde im Rahmen dieser Diplomarbeit in die Oberfläche von Mapbender integriert. Weitere Funktionen wurden von weniger Mitarbeitern als wichtig erachtet. Nicht in Mapbender und somit


99

im MapViewer vorhandene Funktionen, wie beispielsweise das Hochladen eigener Daten in die Karte oder das Markieren von Kartenobjekten, wurden von weniger Benutzern gewünscht. Am wichtigsten wurde hier noch das Speichern der aktuellen Kartenkonfiguration angesehen, was aber vom Geoportal ebenfalls nicht unterstützt wird. Alle von den Wissenschaftlern als wichtig erachteten Funktionen werden somit durch den MapViewer online angeboten, so dass es gut möglich ist, die Geodaten zu erkunden und Informationen in ihnen zu finden. Das Ziel des Geoportals wurde somit erfüllt. Es werden sogar zusätzliche Funktionen angeboten, die in der Umfrage als weniger wichtig erachtet wurden.

Onlineanalyse Der Benutzer soll die gefundenen Geodaten nicht nur direkt online betrachten, sondern auch durch grundlegende Funktionen der Onlineanalyse auswerten können. Hierfür bietet das Geoportal an, mehrere Karten auf einmal anzuzeigen (Mapbasket), um sie zu vergleichen, sowie das Abfragen von Attributen zu Kartenobjekten (Querying) oder das Setzten von Filtern für die Ebenen der Karte (realisiert über den OGC-Standard SLD). Für die zuletzt genannte Funktionalität musste Mapbender speziell für das Geoportal angepasst werden. Diese Lösung funktioniert zwar, jedoch noch nicht optimal, was aber voraussichtlich in einer späteren Version von Mapbender behoben wird. Mehr hierzu findet man in Kapitel 3.3.6 und im Anhang 6.6.

Mapbender bietet noch weitere Analysefunktionen an, wie etwa das Messen von Abständen auf einer Karte. In der Umfrage stellte sich jedoch heraus, dass viele Mitarbeiter des ZEF die meisten angebotenen Analysefunktionen gar nicht nutzen würden. Nur das Querying rief ein größeres Interesse hervor, vor allem jedoch, um Links von ausgewählten Kartenobjekten folgen zu können. Somit bietet das Geoportal zahlreiche Funktionen zur Onlineanalyse an, sogar mehr, als von den meisten Mitarbeitern für notwendig erachtet werden. Das gesetzte Ziel wurde hier somit erfüllt und sogar übertroffen.

4.2.3 Kommunikation und Austausch

Unzuverlässige und langsame Internetanbindungen Aus Rücksichtnahme auf die instabilen und langsamen Internetanbindungen im späteren Einsatzgebiet des Geoportals in Afrika, sollte die durch das Geoportal verursachte Netzwerklast möglichst gering gehalten werden. Die Webseiten des Geoportals enthalten nur sehr wenige Grafiken, die ein erhöhtes Datenaufkommen bedeuten würden. Bei der Anzeige von Karten sorgt die internetkompatible Aufbereitung der Geodaten durch den Mapserver dafür, dass hierbei möglichst wenige Daten übertragen werden.

Der zur visuellen Darstellung von Karten verwendete und stark verbreitete WMS-Standard wurde vom Open Geospatial Consortium (OGC) speziell für die Nutzung im Internet entwickelt. In diesem Verfahren berechnet der Server eine Grafik für den aktuell gezeigten Ausschnitt der Karte und überträgt diese an den Client. Dies muss bei jeder Änderung erneut geschehen. Da die aufwändigen Berechnungen auf der Serverseite durchgeführt werden, müssen an den webbasierten Client nur geringe Anforderungen gestellt werden. Als Grundlage ist hier ein Browser zur Darstellung der Grafik vollkommen ausreichend. Der Server kann der Last entsprechend ausreichend dimensioniert werden. Da immer nur eine Grafik konstanter Größe übertragen wird, hat das Verfahren zudem Vorteile bei besonders großen Geodatenmengen, die nicht vollständig an den Client übertragen werden müssen. Bei kleineren Datenmengen überschreitet das übertragene Datenvolumen der Grafiken bei vielen Änderungen des angezeigten


100

Ausschnitts jedoch irgendwann die Größe der zugrunde liegenden Geodaten. Das Verfahren arbeitet hier ineffizient, eine vollständige Übertragung der Geodaten auf die Clientseite wäre sinnvoller gewesen. Dies ist jedoch nur möglich, wenn der Client auch die Verarbeitung der Daten leisten kann. Dem leichten Client stehen hier aber nur die Möglichkeiten eines Browsers zur Verfügung, weshalb dies ohne zusätzliche Software nicht möglich ist. Die Installation zusätzlicher Software für das Geoportal ist jedoch nicht erwünscht, um beliebigen Nutzern die Funktionalität der Kartenvisualisierung ermöglichen zu können.

Eine Alternative zu WMS beschreibt exemplarisch das in [STCK02] vorgestellte Verfahren für 3D-Modelle, in dem der Client und nicht der Server jede neue Ansicht des jeweils angeforderten Ausschnitts berechnet. Er fordert vom Server immer nur die Teile der Daten an, die für die Darstellung der aktuellen Ansicht erforderlich sind. Der Detailgrad ist einstellbar. Bereits erhaltene Daten werden zur späteren Verwendung zwischengespeichert und werden somit nicht mehrfach übertragen. Dieses Verfahren ist jedoch nur für fette Clients geeignet, weil der Client hier das Rendern der Grafiken übernehmen muss. Der Server hingegen liefert nur die benötigten Daten aus und wird somit weniger belastet als im WMS-Verfahren. Die Möglichkeiten des Client limitieren hier nicht die Möglichkeiten der Nutzung, aber es muss hier spezielle Software auf dem Rechner des Benutzers installiert werden, wie dies beispielsweise bei Google Earth [Goog08b] der Fall ist. Eine solche Installation kann jedoch gerade Benutzern nicht zugemutet werden, die das Geoportal nicht regelmäßig besuchen. Da in diesem Verfahren keine Daten mehrfach übertragen werden, lohnt es sich besonders bei kleinen Datenmengen. Bei größeren Datenmengen müssen möglicherweise viel mehr Daten an den Client übertragen werden, als dies bei WMS der Fall wäre, damit dieser genug Daten zur Berechnung des aktuell angezeigten Ausschnitts zur Verfügung stehen hat.

Das Geoportal bietet noch weitere Möglichkeiten für den Umgang mit langsamen und instabilen Internetverbindungen. Wenn das Portal dem Benutzer Daten zum Herunterladen anbietet, dann werden diese verlustfrei komprimiert, außerdem kann der Benutzer eine Auswahl über die herunter zu ladenden Geodaten anhand der Ebenen der zugehörigen Karte treffen (Kapitel 3.3.7). Diese Maßnahmen ermöglichen eine möglichst geringe Netzwerklast beim Zugriff auf das Geoportal, eine weitere Reduktion ist nicht sinnvoll. Bei häufigen Verbindungsabbrüchen, die bei instabilen Internetanbindungen auftreten können, bietet der verwendete Webserver des Geoportals für Downloads die sogenannte ReGet-Funktion an. Hierbei kann ein unterbrochener Download nach der Wiederherstellung der Verbindung an der unterbrochenen Stelle wieder aufgenommen werden. So müssen keine Teile des Downloads unnötigerweise mehrfach übertragen werden, wenn der Download noch nicht abgeschlossen war. Die Funktion muss jedoch auch von der Clientsoftware unterstützt werden, die für den Download verwendet wird. Auch die im Geoportal verwendeten Sitzungen (Sessions) ermöglichen den besseren Umgang mit instabilen Verbindungen, da der Benutzer nach einem Verbindungsabbruch seine Arbeit wieder an der alten Stelle in der Weboberfläche aufnehmen kann, wenn ein einstellbarer Timeout noch nicht abgelaufen ist. Alle getroffenen und in diesem Abschnitt beschriebenen Maßnahmen ermöglichen den guten Umgang mit langsamen und instabilen Internetanbindungen.

Downloadmöglichkeiten Über die angebotene Downloadfunktion in verbreiteten Formaten realisiert das Geoportal das Ziel der Distribution von Projektdaten. Die Distribution ist gut möglich und geht sogar über die Möglichkeiten vieler anderer Geoportale hinaus. Das Geoportal kann alle dateibasierten Daten, die ihm über die Metadatenbank bekannt gemacht wurden, zum Download anbieten (Kapitel


101

3.3.7). Das stellt einen großen Vorteil im Vergleich zu Geoportalen dar, die nur wenige vorbereitete oder gar keine Daten zum Herunterladen anbieten.

Das Geoportal verwendet als Austauschformate für Geodaten ESRI Shapefiles und GeoTIFF, die beide weit verbreitet sind und somit von einer Vielzahl von externer Software unterstützt werden. Zusätzlich bietet das Geoportal einen Export von Daten aus ESRI Geodatenbanken an (Kapitel 3.3.8). Der angebotene Export und Download als XML-Workspace ist jedoch nur für Nutzer von ESRI Software sinnvoll, weil dieses Format von anderen Programmen nicht unterstützt wird. Die verantwortlichen Mitarbeiter am ZEF hielten diese Funktion dennoch für wichtig, da ESRI Software im Projekt stark verbreitet ist. In der Umfrage kann man erkennen, dass die Mitarbeiter des ZEF die Downloadmöglichkeit als wichtigste Funktion des Geoportals ansehen.

Für den Austausch von Daten wird zusätzlich zum Download noch eine Möglichkeit zum Hochladen benötigt. Über SSH/SCP, oder im Intranet auch über Samba, können Benutzer eigene Daten auf den Datenserver hochladen, die nach einer Kontrolle durch die verantwortlichen Personen in das Geoportal eingepflegt werden können. Die benötigten Metadaten können dem Geoportal über einen Onlineeditor oder über den Upload in einem speziell entwickelten XML-Format hinzugefügt werden. Auch die Metadaten werden vor der endgültigen Veröffentlichung noch kontrolliert. Der Austausch von Daten unter den Benutzern des Portals ist somit möglich, jedoch ist das Hochladen neuer Daten außerhalb des Intranets nur über Software möglich, deren Anwendung für viele Mitarbeiter ungewohnt ist (SCP-Client). Die Kontrollen der Daten und Metadaten verzögern zudem die Veröffentlichung, sind aber aus Gründen der Qualitätssicherung von den verantwortlichen Personen am ZEF gefordert worden und stellen somit keinen Mangel dar. Metadaten lassen sich zudem leicht offline erstellen und dem Geoportal online hinzufügen (Kapitel 3.3.3). Für den Upload neuer Daten werden in Kapitel 4.3 Verbesserungsvorschläge gemacht, um den Vorgang zu vereinfachen. Laut der Umfrage wird die Uploadfunktion für eigene Daten jedoch von vielen Mitarbeitern als weniger wichtig angesehen, so dass die genannten Komforteinbußen vertretbar sind. Aus diesen Gründen erfüllt das Geoportal, trotz der wenigen genannten Schwierigkeiten, das Ziel des ermöglichten Datenaustauschs gut.

Benutzer-Benutzer-Kommunikation In den Zielen war vorgesehen, dass das Geoportal die Kommunikation der Projektpartner und die Planung von Projektereignissen ermöglicht. Es bietet derzeit jedoch nur den Terminplaner an, mit dem Benutzer Projektereignisse planen können. Die Einbindung weiterer webbasierter Angebote zur Kommunikation der Benutzer untereinander wäre jedoch möglich. Die Umfrage zeigt aber, dass diese Funktionen von den Mitarbeitern des ZEF mehrheitlich als unwichtig angesehen werden. Sie gehen offenbar über den offensichtlichen Rahmen von Funktionen hinaus, die von den Wissenschaftlern als Hauptfunktionen eines Geoportals angesehen werden. Ihre Implementierung hatte somit nicht die höchste Priorität, sollten solche Funktionen jedoch zukünftig nachgefragt werden, wenn das Portal regelmäßig benutzt wird, dann können sie nachgerüstet werden (vgl. Kapitel 3.3.9).

Interoperabilität und Integration mit anderen Systemen Das Geoportal ermöglicht die Interoperabilität und Integration mit anderen Systemen. Hier muss jedoch zwischen der Server- und der Clientseite unterschieden werden. Auf der Serverseite ist zunächst die komponentenbasierte Architektur zu nennen, die definierte Möglichkeiten bietet, um Komponenten in das Geoportal einzubinden (Weblinks und Interface des Datamanagers). Das Portal kann so durch kompatible Komponenten erweitert werden. Auch innerhalb der


102

Komponenten werden standardisierte Kommunikationsprotokolle verwendet, falls dies erforderlich ist. Dies wird im MapViewer deutlich, der die externen Programme UMN MapServer und Mapbender zur visuellen Darstellung von Karten verwendet. Die Kommunikation zwischen den beiden Programmen wird über den OGC-Standard WMS realisiert. Ein Ersatz eines der beiden Programme durch ein anderes, welches ebenfalls WMS unterstützt, wird so vereinfacht. Des Weiteren ermöglicht die Geoportalsoftware auf der Serverseite das Einbinden von ESRI Geodatenbanken, deren Daten exportiert und visuell dargestellt werden können. Wie bereits erwähnt wurde, ist auch der Download der exportierten Dateien für den Benutzer möglich. Diese Daten kann der Benutzer dann clientseitig mit geeigneter Software weiterverarbeiten.

Auf der Clientseite macht die Verwendung weit verbreiteter Dateiformate nach einem Download die Weiterverarbeitung der Daten auch mit externer Software möglich, die im Vergleich zum Geoportal zusätzliche Funktionen anbieten kann. Der zur Kartendarstellung verwendete WMS-Standard ermöglicht es dem Benutzer zusätzlich, die vom Geoportal angebotenen Geodaten auch mit externer Software darzustellen, ohne sie herunterladen zu müssen (Kapitel 3.3.5), falls dies notwendig sein sollte. Das entworfene XML-Format für die Metadaten erlaubt das Erstellen von Metadaten ohne Internetverbindung zum Geoportal mit einem externen Programm, die dann später in das Geoportal importiert werden können (Kapitel 3.3.3). Wie gezeigt wurde, ist die Interoperabilität und Integration mit anderen Systemen somit möglich.

4.3 Ausblick Die derzeitigen Fähigkeiten des Geoportals sind bereits sehr umfangreich. Viele Aufgaben kann das Portal bereits jetzt erfüllen. Dennoch kann es in Zukunft notwendig werden, den Funktionsumfang des Portals zu erhöhen oder zu verändern, um es an zukünftige Anforderungen des Projekts oder der Nutzer in Ghana und Burkina Faso anzupassen.

Den Mitgliedern des GLOWA Volta Projekts und den zukünftigen Verantwortlichen in Ghana oder Burkina Faso wird das Geoportal in Form einer lauffähigen virtuellen Maschine zur Verfügung gestellt. Der Installations- und Wartungsaufwand wird so minimiert. Soll dennoch eine Weiterentwicklung des Portals stattfinden, dann liegt zu diesem Zweck auch der vollständige Quelltext bei. Da außerdem hauptsächlich quelloffene Programme verwendet wurden, steht einer Weiterentwicklung des Portals somit nichts im Weg. In diesem Fall müssen jedoch Programmierer zur Verfügung stehen, die die Entwicklungsarbeit übernehmen. Einfache Änderungen, wie das Anpassen der Metadatenbank oder das Schreiben neuer Hilfeseiten, können jedoch auch ohne Programmierkenntnisse vorgenommen werden. Es ist außerdem sinnvoll, von den verwendeten externen Programmen neuere Versionen einzusetzen, wenn diese erscheinen. Dies kann nicht nur Sicherheitslücken schließen, sondern auch neue Funktionen bringen, die dann dem Geoportal zur Verfügung stehen. So ist für zukünftige Versionen von Mapbender beispielsweise ein leichter zu bedienender und besser integrierter SLD-Editor geplant, von dem die Analysefähigkeiten des Geoportals profitieren könnten.

In den folgenden Abschnitten werden einige mögliche Erweiterungen oder Veränderungen des Geoportals vorgeschlagen, um dessen Funktionsumfang zu erhöhen oder zu verbessern.

Komponenten Die offensichtlichste Möglichkeit, das Geoportal weiterzuentwickeln, ist das Hinzufügen neuer Viewer, um weitere Arten von Daten anzeigen zu können. Der komponentenbasierte Aufbau des

4.3 Ausblick

103

Geoportals macht dies besonders einfach, da diese Erweiterung bereits im Konzept des Portals vorgesehen ist. Auch neue Downloader für die neuen Daten wären denkbar, falls die bestehenden nicht verwendet werden können. Der Aufbau nach dem MVC-Prinzip erleichtert zudem die Erweiterung der bestehenden Viewer und Downloader und auch der anderen Komponenten des Geoportals, die in Kapitel 3 beschrieben wurden.

Metadatenbank Die Metadatenbank des Geoportals ist zwar bereits an zukünftige Bedürfnisse anpassbar, dies beschränkt sich jedoch auf die Konfiguration der zu verwendenden Elemente. Ansonsten ist die Datenbank jedoch in ihrem Funktionsumfang sehr stark vorgegeben. So ist es beispielsweise nicht möglich, für einzelne Elemente eigene Datentypen vorzugeben oder Elemente zu Gruppen oder Hierarchien zusammenzufassen. Wenn die Anzahl der verwendeten Elemente jedoch ansteigen sollte, dann wäre dies aus Gründen der Übersichtlichkeit für den Benutzer sicherlich wünschenswert. Diese Änderungen würden jedoch eine umfangreiche Überarbeitung des Schemas der Metadatenbank und der für die Metadaten zuständigen Bestandteile des Datamanagers bedeuten.

Ein weiterer Nachteil der Metadatenbank ist die enge Verknüpfung mit dem Geoportal. Ein Austausch der Datenbank gegen eine andere ist somit nicht einfach möglich. Dieser Aspekt erschwert auch die bereits vorgeschlagenen Änderungen am Funktionsumfang der Datenbank. Es kann somit sinnvoll sein, die Metadatenbank modularer in das Geoportal zu integrieren. So kann es vereinfacht werden, die Datenbank durch eine andere zu ersetzten oder den Funktionsumfang der bestehenden Datenbank zu verändern. Außerdem würde dies besser dem Komponentenkonzept des Geoportals entsprechen, das eine einfache Erweiterbarkeit vorsieht.

Es ist zudem denkbar, dass das Geoportal zukünftig nicht die einzige Metadatenbank des Projekts darstellen wird. Es wäre somit hilfreich, wenn auch auf externe Metadatenkataloge zugegriffen werden könnte. Ein solcher Schritt würde eine Modularisierung automatisch enthalten, da die interne Datenbank wie eine externe angesprochen werden könnte. Um mehrere Metadatenbanken über eine standardisierte Schnittstelle anzusprechen, steht beispielsweise der Catalogue Service Standard (CAT, [Ogc08]) des OGC zur Verfügung. So würde auch die Interoperabilität des Geoportals erhöht. Da eine solche Änderung jedoch sehr umfangreich wäre und den Rahmen einer Diplomarbeit sprengen würde und außerdem bislang nicht als notwendig erachtet wurde, wurde auf ihre Umsetzung bisher verzichtet.

Export Der Benutzer kann derzeit Metadaten über ein XML-Format in die Metadatenbank des Geoportals hochladen, wenn diese offline erstellt wurden. Diese Funktion ist vorteilhaft, wenn beim Erstellen der Metadaten keine Onlineverbindung zur Verfügung steht. Wenn die Metadaten jedoch bereits in der Metadatenbank vorliegen, dann kann es zusätzlich sinnvoll sein, diese Daten dem Benutzer wieder in Dateiform zur Verfügung zu stellen. Hier ist ein Export eines Metadatensatzes in dem entworfenen XML-Format denkbar. Mit dieser exportierten Datei könnte der Benutzer seine lokal vorliegenden Geodaten eindeutig beschreiben, die er sich möglicherweise vom Portal aus heruntergeladen hat. Die Metadaten gingen dann nicht verloren. Auch ein nachträgliches Bearbeiten oder Auswerten der Metadaten mit einem Programm, das nur offline zur Verfügung steht, wäre dann denkbar.


104

Dateien lassen sich bereits jetzt über die Downloader aus dem Geoportal herunterladen. Bei Kartendaten ist sogar die Auswahl bestimmter Ebenen möglich, so dass hier nicht alle Daten heruntergeladen werden müssen. Man könnte dies zusätzlich auch bei anderen dateibasierten Daten ermöglichen, um auch hier eine zusätzliche Datenreduktion zu ermöglichen. Hierbei wäre allerdings unklar, ob der Benutzer zum Beispiel anhand des Dateinamen auch entscheiden könnte, ob er die Datei wirklich benötigt.

Externes Javaprogramm Laut der Umfrage unter den Mitarbeitern des ZEF wird die Möglichkeit zum Austausch von Daten unter den Benutzern als wichtig angesehen. Das vom Geoportal angebotene Herunterladen von Daten wird jedoch als wichtiger angesehen als das Hochladen der Daten. Letzteres ist im Geoportal via SSH/SCP zwar möglich, es ist aber nicht sehr komfortabel zu nutzen. Das in Kapitel 3.3.3 bereits eingeführte Javaprogramm, das am ZEF entwickelt wird, um Metadaten auch ohne Internetverbindung erzeugen zu können, könnte entsprechend erweitert werden. Die Fähigkeit, Metadaten in Form von XML-Dateien zu erzeugen, ist derzeit die einzige Funktion, die das Programm bietet. Man könnte es jedoch erweitern, so dass das Programm auch das Hochladen neuer Daten auf den Datenserver des Portals übernimmt und somit stark vereinfacht. Die Metadaten könnten in Form einer XML-Datei gleich mit übertragen werden, so dass sie nicht von den zugehörigen Daten getrennt werden. Selbst unerfahrenen Nutzern wäre es somit möglich, selbst Daten für das Geoportal bereitzustellen, die dann später den anderen Nutzern des Portals zur Verfügung stehen. Das Ausfüllen der Metadaten und die Auswahl eines Verzeichnisses auf dem lokalen Computer, das die Daten enthält, könnten zum Publizieren ausreichen. Eine vollständig automatisierte Veröffentlichung der Daten im Geoportal ist jedoch von den verantwortlichen Personen für das Datenmanagement am ZEF nicht gewünscht, da die Daten zunächst auf Qualität überprüft werden sollen. Theoretisch wäre aber auch das vollständig automatisierte Veröffentlichen von Daten denkbar.

Man kann mit dem Programm zudem sicherstellen, dass bei einem Verbindungsabbruch während des Transfers nicht alle Daten erneut übertragen werden müssen, sondern nur die noch fehlenden. Dies wäre vor allem bei der Netzinfrastruktur in Afrika sinnvoll, weil es dort zu regelmäßigen Ausfällen kommen kann.

Wenn mehrere Datenproduzenten sich einen Computer teilen, auf dem das Programm installiert ist, dann wäre eine einfache Benutzerverwaltung denkbar, die sich auf die Benutzerdaten des Geoportals stützt. Eine Liste aller Nutzer stellt das Geoportal bereits jetzt als abrufbare Liste zur Verfügung.

Suchfunktionen Die Suchfunktionen des Geoportals sind bereits jetzt sehr umfangreich. Dennoch gibt es einige Möglichkeiten, um diese noch zu erweitern oder für den Benutzer einfacher benutzbar zu machen. Gerade die einfache Benutzbarkeit ist für die Akzeptanz des Geoportals von Bedeutung.

Die derzeitigen Suchfunktionen ermöglichen es nur, mehrere Suchanfragen beziehungsweise Schlüsselwörter mit UND zu verknüpfen. Damit werden zwar die meisten zu erwartenden Anfragen abgedeckt, jedoch kann es zusätzlich sinnvoll sein, auch mit ODER- beziehungsweise NICHT-Verknüpfungen suchen zu können. Dies würde es ermöglichen, feinere Suchbedingungen zu definieren.

4.3 Ausblick

105

In der Standardsuche wird das Element description separat von den anderen Metadatenelementen durchsucht, weil sie in unterschiedlichen Tabellen abgelegt sind. Das ist auch der Grund, warum das Element description nicht wie die anderen Elemente konfigurierbar ist. Eine Lösung für beide Probleme wäre es, wenn man description in die Liste der normalen Elemente aufnimmt, die über die Tabelle md_elements konfiguriert werden und deren Werte in md_dc_values gespeichert werden. Die zusätzliche Tabelle md_dc_description wäre dann nicht mehr notwendig. Dies wurde nicht von Anfang an so geplant und realisiert, weil das Element description länger als die üblichen 255 Zeichen (maximale Länge des Datentyps VARCHAR) sein muss und deshalb einen anderen Datentyp bekommen hat. Die Tabelle md_dc_values könnte man jedoch so anpassen, dass alle Elemente den unbeschränkten Datentyp TEXT erhalten. Das würde auch besser der Vorgabe aus dem Dublin Core Standard entsprechen, die eine beliebige Länge für alle Elemente vorsieht. Die Beschränkung auf die 255 Zeichen würde wegfallen. Der zunehmende Speicherplatzbedarf für den Datentyp TEXT fällt bei einer kleinen Metadatenbank, wie der des GLOWA Volta Projekts, nicht so stark ins Gewicht, vor allen da auf dem RAID des Datenservers genügend Speicherplatz zur Verfügung steht. Diese Änderung würde sich jedoch nicht nur auf das Datenbankschema auswirken, sondern es würde auch Änderungen an verschiedenen Programmteilen des Geoportals – beispielsweise aller Suchfunktionen – nach sich ziehen.

Derzeit kann nur nach Zeichenfolgen gesucht werden. Gerade bei Zeitangaben kann es aber sinnvoll sein, nach Bereichen zu suchen. So könnte man eine Anfrage stellen, die alle Metadateneinträge zurückliefert, die in einem angegebenen Zeitfenster erstellt wurden. Um dies zu erreichen, müsste jedoch das Datenbankschema geändert werden, da man nach Bereichen am Besten in Zahlen und nicht in Zeichenketten suchen kann. Das Metadatenelement date müsste als Zahlenwert und nicht als Datentyp VARCHAR implementiert werden.

Um die Bedienung der Suchfunktionen für den Benutzer zu vereinfachen, hat man mehrere Möglichkeiten. Bei der Koordinatensuche kann man eine Vereinfachung erreichen, in dem man es ermöglicht, die Auswahl der Koordinaten grafisch zu treffen. Derzeit muss der Benutzer die Nord-, Süd-, Ost- und Westkoordinaten als Zahlenwerte eingeben, um die Suchanfrage zu stellen. Diese Werte müssen dem Benutzer somit jedoch zumindest näherungsweise bekannt sein. Einfacher wäre es, wenn der Benutzer den gewünschten Bereich in einer kleinen Karte als Rechteck „aufziehen“ könnte, um so die Koordinaten einzugeben.

Derzeit werden dem Benutzer in der erweiterten Suche nahezu alle Metadatenelemente als Eingabemöglichkeit angeboten. Dies hat zwar den Vorteil, dass der Benutzer so alle Felder der Metadateneinträge durchsuchen kann, es verringert jedoch die Übersichtlichkeit und somit die Bedienbarkeit der Suche. Wie in [TaSe05] dargelegt, kann es bei vielen durchsuchbaren Feldern sogar sein, dass sich die Suchergebnisse verschlechtern. Dieses Problem tritt auf, wenn der Benutzer voraussetzt, dass alle Metadatenfelder vollständig ausgefüllt sind und das aber nicht der Fall ist. Es könnten so Suchanfragen in Feldern gestellt werden, die oft keine Werte enthalten und somit bei einer Anfrage auch keine oder unvollständige Suchergebnisse liefern würden. Wenn man die erweiterte Suche auf wichtige Felder beschränken würde, könnte man hier Abhilfe schaffen. Bei vollständig ausgefüllten Metadaten ist dies jedoch nicht unbedingt notwendig.

Datenserver und Transfer Derzeit steht dem Geoportal nur ein einziger Datenserver für alle angebotenen Daten zur Verfügung. Es wäre jedoch denkbar, dass einige Datenproduzenten ihre eigenen Daten lieber auf eigenen Datenservern verwalten möchten. Man könnte das Geoportal so erweitern, dass es in der


106

Lage ist, mehr als einen Datenserver zu verwenden. Die zusätzlichen Datenserver müssten nicht im gleichen Netzwerk wie der Webserver des Geoportals liegen, sondern könnten nur über das Internet zugreifbar sein. Der Transfer der Daten könnte über ein sicheres Protokoll wie SSH/SCP abgewickelt werden, um die Daten zu schützen. Ein solcher Transfer würde jedoch eine schnelle Internetverbindung zwischen dem Geoportal und den externen Datenservern erfordern, um Wartezeiten für die Benutzer zu minimieren. Auch Zwischenspeicher wären hier sinnvoll.

Alternativ oder zusätzlich könnte das Geoportal externe WMS-Dienste wie eigene Karten in seinen eigenen MapViewer einbinden. Derzeit wird für externe WMS-Dienste vorausgesetzt, dass diese einen eigenen Viewer mitbringen, auf den verwiesen wird. Ein Download der Geodaten direkt über das Geoportal wäre bei diesem Ansatz jedoch nicht möglich, da der WMS-Standard dies nicht vorsieht.

Derzeit greift das Geoportal über das ungeschützte SMB-Protokoll auf seinen eigenen Datenserver zu. Wenn es einem Angreifer gelingen sollte, vollständige Kontrolle über den Webserver des Geoportals zu erlangen, dann könnte er auf diesem Wege auch an alle für das Geoportal freigegebenen Geodaten gelangen. Der zusätzliche Schutz der Daten durch den separaten Datenserver wäre hier wirkungslos, weil das Betriebssystem des Webservers dem Angreifer den Zugriff auf die Daten ermöglichen würde. Die Verwendung eines sichereren Protokolls für den Transfer der Daten zwischen dem Datenserver auf den Webserver würde die Missbrauchsgefahr verringern. Als Protokoll könnte im Datamanager anstatt der Dateisystemzugriffe über SMB das sicherere SSH/SCP verwendet werden. Ein vollständiger Schutz der Daten kann aber auch so nicht garantiert werden, weil auch in diesem Fall Angriffsmöglichkeiten denkbar wären. Dies ist jedoch bei allen im Internet verfügbaren Diensten der Fall.

Kosten Bei der Entwicklung des Geoportals wurde hauptsächlich auf selbst entwickelte oder kostenlos verfügbare Software gesetzt. Für das Windows Betriebssystem und ArcGIS Engine Runtime, für die es an der Universität Bonn bereits Lizenzen gibt, müssen die Kosten im späteren Projektgebiet jedoch entweder aufgebracht werden oder man kann auf die Nutzung der ESRI Geodatenbanken im Portal verzichten, womit man die Lizenzgebühren sparen würde. Das Windows-Betriebssystem könnte durch GNU/Linux ersetzt werden, da die verwendete Software auch für dieses Betriebssystem zur Verfügung steht. Ob das Zusammenspiel jedoch auch unter Linux funktioniert, wurde nur mit einer alten Version des Geoportals getestet. Möglicherweise sind hier Anpassungen an der Software notwendig.

Benutzerkommunikation Nicht nur über das externe Javaprogramm könnte dem Benutzer die Interaktion mit dem Geoportal erleichtert werden. Auch die Weboberfläche des Portals könnte dem Benutzer zusätzlichen Nutzen bieten. So ist es beispielsweise denkbar, dass der Benutzer Daten sucht, die nicht im Geoportal verfügbar sind. Bei erfolglosen Suchanfragen könnte das Portal ein Formular anbieten, das gezielt alle notwenigen Informationen für eine Anfrage nach den gesuchten Daten abfragt. Diese Anfrage würde dann an eine geeignete verantwortliche Person weitergeleitet, die die Daten dann – falls möglich – über das Geoportal zur Verfügung stellt. Auch wäre es denkbar, dass ein Benutzer eine Suchanfrage stellen kann und dann per E-Mail benachrichtigt würde, wenn es für die Anfrage neue Ergebnisse gibt. So würde der Benutzer über Themen, die ihn interessieren, regelmäßig auf dem Laufenden gehalten.

4.3 Ausblick

107

Auch die Kommunikation der Benutzer untereinander kann erweitert werden. Mit einem an das Geoportal angeschlossenen Wiki wurde bereits experimentiert, es ist jedoch in der finalen Version des Portals nicht mehr enthalten, weil es voraussichtlich von den späteren Benutzern nicht verwendet werden würde. Außerdem würde eine verantwortliche Person benötigt, die das Wiki regelmäßig auf unzulässige Einträge überprüft. Im Abschnitt „Wiki, Chat und Forum“ des Kapitels 3.3.9 werden einige weitere mögliche Kommunikationsmöglichkeiten zwischen Benutzern vorgestellt, mit denen man das Geoportal erweitern könnte. Auch Mailinglisten oder Vergleichbares wären denkbar, wenn dies in Zukunft erforderlich werden sollte. Alle diese Angebote müssten im Geoportal nur durch Links eingebunden werden und würden im einfachsten Fall keine Änderung am Geoportal selbst nach sich ziehen.

5 Literatur

108

5 Literatur [ACI+97] Giovanni Aloisio, Massimo Cafaro: A distributed Web-based Metacomputing

Environment. Università degli Studi di Lecce, Italy, 1997. [AdKr05] Trias Aditya and Menno-Jan Kraak: Reengineering the Geoportal. Applying HCI and

Geovisualization Disciplines. International Institute for Geoinformation Science and Earth Observation (ITC), 2005.

[AdKr06] Trias Aditya and Menno-Jan Kraak: Geoportals. Envisioning the National Atlas as a Metaphor. Kapitel 2, basiert auf Geospatial Data Infrastructure Portals. Using National Atlases as a Metaphor. Cartographica, 41(2), 115-134, 2006.

[AnAn01] N. Andrienko and G. Andrienko: Intelligent Support for Geographic Data Analysis and Decision Making in the Web. Journal of Geographic Information and Decision Analysis 2001, Vol. 5, No. 2, pp.115-128.

http://www.geodec.org/Andrienko.pdf [Apac07] Apache Tomcat, http://tomcat.apache.org/ [Asam03] Hubert Asamer: Die Möglichkeiten von open-source software in der

Geodatenverarbeitung. Seminararbeit. University of Vienna, 2003. http://homepage.univie.ac.at/wolfgang.kainz/ Lehrveranstaltungen/Seminar/SS%202003/Asamer.pdf [BBB+99] Oleg Balovnev, Andreas Bergmann, Martin Breunig, Armin B. Cremers, Serge

Shumilov: Remote Access to Active Spatial Data Repositories. University of Bonn, Department of Computer Science III, 1999.

[BeSm04] Lars Bernard, Paul Smits: Requirements on (Semantic) Interoperability in the European SDI. Joint Research Centre, European Commission, 2004.

[BKAS04] Lars Bernard, Ioannis Kanellopoulos, Alessandro Annoni, Paul Smits: The European geoportal––one step towards the establishment of a European Spatial Data Infrastructure. Joint Research Centre, European Commission, 2004.

[Bnb08] Besucherinformationssystem Nationalpark Berchtesgaden, http://maps.la.fh-weihenstephan.de:8080/php/webgis.phtml [Bsi07] Bundesamt für Sicherheit in der Informationstechnik. Thema Internet-Sicherheit, http://www.bsi.bund.de/fachthem/sinet/index.htm [Cons08] Conservation GeoPortal, http://www.conservationmaps.org/index.jsp [Cros05] Peter Crosswell: Oregon GIS Utility Project. Requirements Assessment And Business

Case. GIS Utility Case Study Summary. PlanGraphics Inc. for the State of Oregon, December 2005.

http://www.oregon.gov/DAS/EISPD/GEO/docs/gisutility/ 1339.4GISUtilityCaseStudies-Deliv4EFINAL123005.pdf [Dcmi03] Dublin Core Metadata Initiative: Guidelines for implementing Dublin Core in XML.

Ausgabedatum: 2003-04-02. http://dublincore.org/documents/dc-xml-guidelines/ [Dcmi08] Dublin Core Metadata Initiative (DCMI), http://dublincore.org/ [Esa07] European Space Agency (ESA), Group On Earth Observations: GEO Portal. The

Gateway to Global Earth Observation data, information and services. 2007.

5 Literatur

109

[Esri03a] ESRI: Spatial Data Standards and GIS Interoperability. ESRI White Paper, 2003. [Esri03b] ESRI: Building GIS Catalog Portals. ArcNews Spring 2003 Issue. http://www.esri.com/news/arcnews/spring03articles/ building-gis.html [Esri06a] ESRI: GIS Portal Toolkit Application. GIS Portal Toolkit Workshop, 2006. [Esri06b] ESRI Libraries & GIS News, Number 18, Herbst 2006, http://www.esri.com/common/education/ libraries_gisnews_archives/lib_enews18.html [Esri07a] ESRI (ArcGIS), http://www.esri.com/ [Esri07b] ESRI Geodatabase, http://www.esri.com/software/arcgis/geodatabase/ [FOJ04] Dr. Martin Fornefeld, Peter Oefinger, Kathrin Jaenicke: Nutzen von

Geodateninfrastrukturen. Studie, MICUS Management Consulting, 2004. [Food05] Food and Agriculture Organization of the UN: Analysis of Existing Spatial Networks.

August 2005. [Fgdc07] The Federal Geographic Data Committee (FGDC), http://www.fgdc.gov/ [FTS05] Jeanne Foust, Winnie S.M. Tang, Jan Selwood: Evolving Infrastructure: Growth and

Evolution of Spatial Portals. FIG Working Week 2005 and GSDI-8 Cairo, Egypt, 2005.

http://www.fig.net/pub/cairo/papers/ts_02/ ts02_01_foust_etal.pdf [Gbun08] GeoPortal.Bund, http://geoportal.bkg.bund.de/DE/Home/homepage__node.html [Gdi07] Lenkungsgremium GDI-DE in Zusammenarbeit mit con terra GmbH: Architektur der

Geodateninfrastruktur Deutschland. Konzept zur fach- und ebenenübergreifenden Bereitstellung von Geodaten im Rahmen des E-Government in Deutschland. August 2007.

[Geop08a] Le Géoportail – le portail des territoires & des citoyens, http://www.geoportail.fr/ [Geop08b] GEOPortal von ESA und FAO, http://www.geoportal.org/ [Ghes07] Geoportal Hessen, http://www.geoportal.hessen.de/ [Giga08] Gigateway, http://www.gigateway.org.uk/ [Gisw06] GISWiki Artikel zum Thema Geodaten (vom 24.2.2006), http://de.giswiki.net/index.php?title=Geodaten&oldid=9193 [Gisw08] GISWiki Artikel zum Thema Geodatenintrastruktur (vom 10.3.2008) http://www.giswiki.org/index.php?title=Geodateninfrastruk

tur&oldid=15990 [Gisw07] GISWiki Artikel zum Thema Koordinatensystem (vom 14.3.2007), http://de.giswiki.net/index.php?title=Koordinatensystem&o

ldid=15198

5 Literatur

110

[GLCZ08] G. Giff, B. van Loenen, J. Crompvoets, J. Zevenbergen: Geoportals in Selected European States. A Non-Technical Comparative Analysis. Delft University of Technology, Katholieke Universiteit Leuven, 2008.

[Glow07] GLOWA Volta Projekt, http://www.glowa-volta.de/ [Goog08a] Google Maps Deutschland, http://maps.google.de/ [Goog08b] Google Earth, http://earth.google.de/ [Gos08] Geospatial One Stop (GOS2), http://www.geodata.gov/ [Grlp08] GeoPortal Rheinland-Pfalz, http://www.geoportal.rlp.de/ [Guim04] Jordi Guimet: Spatial Data Infrastructures. A new paradigm within the domain of

geospatial information. The example of the Catalan Spatial Data Infrastructure Project (IDEC). Report, 2004.

[Hmdk07] Hamburger MetaDatenKatalog der Freien und Hansestadt Hamburg, http://www.hmdk.de/ [Idec08] IDEC Geoportal, http://www.geoportal-idec.net/ [Insp08] INSPIRE European Geo-Portal, http:// www.inspire-geoportal.eu/ [Inte07] Intelec Geomatics Inc. (M³Cat), http://www.intelec.ca/anglais.html [Kurp07] Dr.-Ing. Jörg Kurpjuhn: Geodateninfrastruktur Rheinland-Pfalz und das

GeoPortal.rlp. Geodaten finden und nutzen. Where2B Conference, 2007. http://www.where2b-conference.com/sites/where2b-

conference.com/files_where2b/Geoportal.rlp_.pdf [KVKL07] Martin Klenke, Thomas Vögele, Fred Kruse, Hanno Lehmann: PortalU® und

InGrid® – Werkzeuge zur Erstellung, Recherche und Verteilung von Metadaten. 2007.

[LSS+06] Jennifer Larson, Maria Antonia Olmos Siliceo, Marcelino Pereira dos Santos Silva, Eva Klien, Sven Schade: Are Geospatial Catalogues Reaching their Goals? University of Münster, San Diego State University, Instituto Tecnológico de Toluca, National Institute for Space Research, Rio Grande do Norte State University, 2006.

[Mao05] Liman Mao: Web-based Information System for Land Management. University of Calgary, Department of Geomatics Engineering, June 2005.

http://www.geomatics.ucalgary.ca/Papers/Thesis/MR/ 05.20223.LimanMao.pdf [Mapb08] Mapbender Wiki, http://www.mapbender.org/index.php/Main_Page [Mitt04] Cdr. Sudhir Kumar Mittal: Chained-Services Based Marine SDI Geoportal. A

Reference Architecture using RM-ODP and UML. International Institute for Geo-Information Science and Earth Observation, Netherlands, December 2004.

http://www.itc.nl/library/Papers_2004/msc/gfm/mittal.pdf [Natu06] The Nature Conservancy: The Conservation Base Map and Atlas of Conservation.

Concept Paper, 2006.

5 Literatur

111

[NKNM05] Athanasis Nikolaos, Kalabokidis Kostas, Vaitis Michail and Soulakellis Nikolaos: The Emerge of Semantic Geoportals. OTM Workshops 2005, LNCS 3762, S. 1127 – 1136, 2005.

[Ogc07a] Open Geospatial Consortium (OGC), Web Map Service (WMS), http://www.opengeospatial.org/standards/wms [Ogc07b] Open Geospatial Consortium (OGC), Styled Layer Descriptor (SLD), http://www.opengeospatial.org/standards/sld [Ogc08] Open Geospatial Consortium (OGC), Catalogue Service (CAT), http://www.opengeospatial.org/standards/cat [Osd06] The Open Source Definition (OSD) der Open Source Initiative (vom 7.7.2006), http://www.opensource.org/docs/osd [Port08] PortalU, http://www.portalu.de/ [Rie05] Dr.-Ing. Jens Riecken: INSPIRE - und nationale Infrastrukturen aus deutscher und

NRW-Sicht. Landesvermessungsamt NRW, für Intergeo, 2005. [SADM04] Forschungsgruppe GeoPortal: Univ.-Prof. Dr.-Ing. M. Schilcher, Dr.-Ing. G.

Aumann, Dipl.-Ing. A. Donaubauer, Dipl.-Ing. A. Matheus: Abschlussbericht Forschungsprojekt GeoPortal im Auftrag des Bayerischen Staatsministeriums der Finanzen. Technische Universität München, Institut für Geodäsie, GIS und Landmanagement, Fachgebiet Geoinformationssysteme, München im April 2004.

http://www.rtg.bv.tum.de/index.php/filemanager/download/ 255/GeoPortal%20-%20Abschlussbericht.pdf/ [Samb08] Samba Homepage, http://de.samba.org/samba/ [Schm01] Robert Schmitz-Hübsch: Präsentation und Analyse von Geodaten im Internet –

Technische Grundlagen und ausgesuchte Implementierungsbeispiele. Universität Hannover, Institut für Photogrammetrie und Geoinformation, September 2001.

http://www.ipi.uni-hannover.de/html/lehre/diplomarbeiten/2001/schmitz-huebsch/Diplomarbeit_rsh.pdf

[Schu03] Grit Schuster: Entwicklung von Komponenten eines Geoportal-Frameworks. Integration von Internet-Mapserver-Funktionalität in ein Content Management System. Hochschule Vechta, Institut für Umweltwissenschaften, Freiburg im Juni 2003.

http://www.geographie.uni-freiburg.de/ipg/personen/ schuster_grit/dipl/diplomarbeit_schuster.pdf [Schu07] Emanuel Schütze: Stand der Technik und Potenziale von Smart Map Browsing im

Webbrowser - am Beispiel der Freien WebMapping-Anwendung OpenLayers. Diplomarbeit, Hochschule Bremen, 2007.

http://www.smartmapbrowsing.org/html/index_de.html [Seda07] Sedag Web-GIS der Universität Bonn, http://www.giub.uni-bonn.de/sedag/webgis.htm [StBa05] Hans Gerd Stoffel, Dietmar Barth: Aufbau der Geodateninfrastruktur Rheinland-

Pfalz. Ressortforum „Geobasisinformation und Geodateninfrastruktur für Rheinland-Pfalz“, 2005.

http://www.gutachterausschuesse.rlp.de/lv/pdf/ stoffel_barth.pdf

5 Literatur

112

[STCK02] S. Shumilov, A. Thomsen, A.B. Cremers, B. Koos: Management and Visualization of large, complex and time-dependent 3D Objects in Distributed GIS. University of Bonn, 2002.

[Sun08] Sun Microsystems JavaServer Pages Technology Produktseite, http://java.sun.com/products/jsp/index.jsp [TaSe05] W. Tang, J. Selwood: Spatial Portals - Adding value to spatial data infrastructures.

ESRI China, ISPRS Workshop on Service and Application of Spatial Data Infrastructure, XXXVI(4/W6), 2005.

[Teeg01a] Gunnar Teege: Geodaten im Internet. Ein Überblick. Informatik Spektrum 24/2001, Heft 4, August 2001, S.193-206.

http://inf3-www.informatik.unibw-muenchen.de/institut/ personen/teege/extension/publications/Teege2001.pdf [Teeg01b] Gunnar Teege: Ein interoperables GeoPortal zur Nutzung von Geodaten im Internet.

Zeitschrift für Vermessungswesen (ZfV) 4/2001. http://www.gis1.bv.tum.de/Publikationen/ Veroeffentlichungen/Dokumente/ZfV_2001_Teege.pdf [Terr08] terrestris GbR (AmeiN! und AveiN!), http://www.terrestris.de/cms/index.php?option=com_content

&task=view&id=54&Itemid=86 [Tran08] Transport Direct, http://www.transportdirect.info/TransportDirect/en/ [Umn07] UMN MapServer Homepage, http://mapserver.gis.umn.edu/ [UnSc05] Johanna Unterpaintner & Ruth Schönbuchner: WebGIS Anwendung für den

Nationalpark Berchtesgaden – Prototyp eines Besucherinformationssystems mit dem UMN MapServer. Fachhochschule Weihenstephan, Fachbereich Landschaftsarchitektur, März 2005.

http://www.selbstverwaltung-bundesweit.de/mapserver/ Diplomarbeit_PHPMapScript.pdf [VKK06] T. Vögele, M. Klenke, F. Kruse: PortalU – A New Nationwide Portal to

Environmental Information in Germany. Coordination Center PortalU, 2006. [Vmwa07] VMware Server, http://www.vmware.com/de/products/server/ [Wiki07a] Wikipedia Artikel über Georeferenzierung (vom 2.10.2007), http://de.wikipedia.org/w/index.php?title=Georeferenzieru

ng&oldid=37384994 [Wiki07b] Wikipedia Artikel über Geodaten (vom 1.6.2007), http://de.wikipedia.org/w/index.php?title=Geodaten&oldid=

32611880 [Wiki07c] Wikipedia Artikel über Technische Kompromittierung (vom 17.6.2007), http://de.wikipedia.org/w/index.php?title=Technische_Komp

romittierung&oldid=33289650 [Wiki07d] Wikipedia Artikel über Virtualisierung (vom 14.7.2007), http://de.wikipedia.org/w/index.php?title=Virtualisierung

_%28Informatik%29&oldid=34381109 [Wiki07e] Wikipedia Artikel über Intranetportale (vom 17.12.2007),

5 Literatur

113

http://de.wikipedia.org/w/index.php?title=Intranetportal&oldid=40170214

[Wiki08a] Wikipedia Artikel über Komponenten (vom 25.3.2008), http://de.wikipedia.org/w/index.php?title=Komponente_%28S

oftware%29&oldid=42036871 [Wiki08b] Wikipedia Artikel über Model View Controller (vom 31.3.2008), http://de.wikipedia.org/w/index.php?title=Model_View_Cont

roller&oldid=44374337 [Wiki08c] Wikipedia Artikel über Freie Softwarte (vom 11.4.2008), http://de.wikipedia.org/w/index.php?title=Freie_Software&

oldid=44771832 [Wiki08d] Wikipedia Artikel über Proprietäre Software (vom 22.3.2008), http://de.wikipedia.org/w/index.php?title=Propriet%C3%A4r

&oldid=43991910 [Wiki08e] Wikipedia Artikel über SQL-Injecton (vom 23.4.2008), http://de.wikipedia.org/w/index.php?title=SQL-

Injection&oldid=45213580 [Wiki08f] Wikipedia Artikel über Secure Shell (vom 28.5.2008), http://de.wikipedia.org/w/index.php?title=Secure_Shell&st

ableid=46490728 [WSS00] Steven H. Wong, Dilip Sarkar, Steven L. Swartz: A CORBA-based Middleware

Architecture for Building Open and Interoperable GISs. University of Miami, 2000. http://www.math.miami.edu/~sarkar/publications/wss-

middleware.ps [Zef08] Zentrum für Entwicklungsforschung der Universität Bonn, http://www.zef.de/

6 Anhänge

114

6 Anhänge

6.1 Verwendete Software im Geoportal Software oder Bibliothek Version Beschreibung Programme: Apache* (oder IIS) Apache: 2.2

(IIS: 6.0) Webserver

Java Runtime Environment 6**

1.6.0 Laufzeitumgebung für Java

Apache Tomcat* 6.0 Servlet-Container für JSP (Anwendungsserver) PHP* 5.2 Skriptsprache (für Mapbender) PostgreSQL* 8.1-8.3 Datenbankmanagementsystem UMN MapServer* aus FWTools

2.1.0 Mapserver, der Karten als WMS bereitstellen kann

Mapbender* 2.5 RC2 Oberfläche, die die interaktive Nutzung von Karten im Browser ermöglicht, die als WMS angeboten werden

Bibliotheken: Apache Commons IO* 1.3.2 Java-Bibliothek, die für Commons Lang benötigt wird Apache Commons Lang* 2.3 Java-Bibliothek, die u.a. die Möglichkeit bietet, HTML-

Output auf Webseiten zu escapen Apache Commons FileUpload*

1.2 Java-Bibliothek, um das Hochladen von Dateien über ein Webformular zu ermöglichen

JavaMail API** 1.4 Java-Bibliothek, um E-Mail-Funktionen in Java nachzurüsten. Siehe http://java.sun.com/products/javamail/

JDOM* 1.0 Java-Bibliothek, um XML einfach zu parsen. Siehe http://www.jdom.org

ESRI ArcGIS Engine Runtime (optional)

9.2 Bietet ArcObjects Bibliothek für Java, um u.a. auf ESRI ArcGIS Geodatenbanken zugreifen zu können

JDBC3 Treiber für PostgreSQL*

8.1 Java-Bibliothek, die einen Zugriff auf PostgreSQL-Datenbanken über JDBC bietet. Siehe http://jdbc.postgresql.org

Betriebssysteme: OpenSuSE Linux* 10.2 Betriebssystem des Datenservers Windows XP Professional XP Betriebssystem des Webservers (* Open Source Software, ** kostenlose Software)

6.2 Programmaufbau des Geoportals Package oder Verzeichnis

Javaklasse oder JSP-Seite Beschreibung Model / view / controller

Hauptprogramm/Datamanager: / index.jsp Geoportal Startseite view / browse.jsp Anzeige aller oder einzelner

Metadateneinträge bzw. aller Einträge eines bestimmten Themas; Auswahl des Viewers anhand des Typs

view

/ login.jsp Login Dialog view / logincheck.jsp Logindaten überprüfen controller / logout.jsp Ausloggen controller

6.2 Programmaufbau des Geoportals

115

/ search.jsp Metadatensuche view / searchdo.jsp Metadatensuche controller

(teilw. view) / metadataadmin.jsp Metadatenverwaltung Übersicht view / urngenerator.jsp URN Generator (entwickelt am ZEF) view /

controller / metadataedit.jsp Metadateneditor view / metadatado.jsp Metadatenverwaltung controller / help.jsp/imprint.jsp Hilfe/Impressum view datamanager Cleanup.java System aufräumen (temp. Verzeich.) controller datamanager ConfigFile.java Zugriff auf mitgelieferte

Konfigurationsdateien controller

datamanager Database.java Verbindung zu Standarddatenbanken controller datamanager Geodatabase.java Zugriff auf ESRI Geodatenbanken controller datamanager GetCapabilitiesJDOM.java Parser für GetCapabilities controller datamanager Links.java Container für statische Links model datamanager Mapfile.java Parser für Mapfiles (Zuordnung von

Dateinamen zu Layernamen) controller

datamanager Out.java / Messages.java Vorgefertigte Ausgaben für JSP-Seiten (wieder verwendbar)

view

datamanager Metadata.java Metadatenverwaltung (Zugriff auf Metadatenbank)

controller

datamanager MetadataEntry.java / MetadataEntries.java

Container für einen/mehrere Metadateneinträge

model

datamanager MetadataJDOM.java Parser für Metadaten-XML-Dateien controller datamanager Portal.java Zugriff auf Links und Beschriftungen

des Geoportals controller / teilw. model

datamanager PrepareData.java Daten vom Datenserver für den Webserver vorbereiten

controller

datamanager PrepareMap.java Karten vom Datenserver für den Webserver vorbereiten

controller

datamanager Tools.java Toolbox mit wieder verwendbaren, nützlichen Funktionen

controller

datamanager UserGroupMgmt.java Benutzer- und Gruppenverwaltung (Zugriff auf Benutzerdatenbank)

controller

datamanager User.java Container für einen Benutzerdaten model datamanager WMS.java Container für die Daten eines WMS model Informationsseiten: information index.jsp Betrachter für Informationsseiten view information admin.jsp Verwaltung von Informationsseiten view information admindo.jsp Verwaltung von Informationsseiten controller information InformationMgmt.java Verwaltung von Informationsseiten

(Zugriff auf Datenbank) controller

information Information.java Container für eine Informationsseite und den Index

model

Meeting Planner: meetingplanner index.jsp Terminplaner Übersicht view meetingplanner admin.jsp Verwaltung von Terminen view meetingplanner meetingedit.jsp Editor für Termine view meetingplanner meetingvoter.jsp Für Zeiten eines Treffens abstimmen view meetingplanner meetingdo.jsp Verwaltung von Terminen controller meetingplanner MeetingPlanner.java Verwaltung von Terminen (Zugriff auf

Datenbank) controller

meetingplanner Meeting.java Container für einen Termin model

6 Anhänge

116

MapViewer: mapviewer index.jsp Anzeige von Metadaten zu Karten und

Hinzufügen der Karten zur aktuellen Auswahl

view

mapviewer mapbasket.jsp Aufrufen der Oberfläche (Mapbender) und Starten des Downloaders für die aktuelle Auswahl

view

mapviewer showonemap.jsp Starten der Oberfläche für nur eine ausgewählte Karte

view

mapviewer MapViewer.java Vorbereiten von Mapserver und Oberfläche

controller

mapviewer MapbenderSetup.java / MapbenderCleanup.java

Mapbender konfigurieren / aufräumen controller

MapDownloader: mapdownloader index.jsp Auswahlmöglichkeit zum Einschränken

des Downloads für die aktuelle Auswahl von Karten

view

mapdownloader downloadmapdo.jsp Wenn verfügbar Download-Links anzeigen

view

mapdownloader MapDownloader.java Downloads vorbereiten controller Data viewer: dataviewer index.jsp Anzeige von Metadaten zu den Daten

und Starten des Downloaders für diese Daten

view

Data downloader: datadownloader index.jsp Wenn verfügbar Download-Links

anzeigen view

datadownloader DataDownloader.java Download vorbereiten controller GoogleMaps viewer: googlemapsviewer

index.jsp Anzeige von Metadaten zu den GoogleMaps Karten und Anzeigen der GoogleMaps Karte

view

googlemapsviewer

GooglemapsViewer.java Anzeige vorbereiten und Konfiguration auslesen

controller

Sonstige Verzeichnisse: administration *.jsp Administrationsseiten des Geoportals view /

controller css *.css Cascading Style Sheets für alle JSP-

Seiten -

explanation *.html Hilfetexte für (fast) alle JSP-Seiten (werden durch include eingebunden)

-

include *.txt Wieder verwendbarer JSP-Code, der in (fast) allen JSP-Seiten eingebunden wird

-

lists *.jsp Schnittstellen für externe Programme zum Abrufen von Informationen aus den Geoportaldatenbanken

-

WEB-INF *.* Verzeichnis, das nicht aus dem Internet zugreifbar ist. Hier liegen die Javaklassen, die Konfigurationsdateien, zusätzliche Javabibliotheken und die Dokumentation.

-

6.3 Aufbau aller verwendeter Datenbanken

117

6.3 Aufbau aller verwendeter Datenbanken

Aufbau der Mapbender Datenbank Es wird nur der vom Geoportal benötigte Teil betrachtet. Tabelle Hängt ab von

(references) Beschreibung

Eingebundene WMS-Kartendienste: wms - Enthält Informationen über alle eingebundenen WMS-Dienste

(z.B. zu Version, Name, URL, Kontaktdaten und unterstützten Funktionen des WMS-Dienstes).

wms_format wms Enthält Informationen über unterstützte Formate von Karten, Fehlermeldungen und Abfrageergebnissen des jeweiligen WMS-Dienstes.

wms_srs wms Enthält Informationen über die unterstützten Projektionen (EPSG-Codes) des jeweiligen WMS-Dienstes.

Enthaltene Ebenen (Layer): layer wms Enthält Zugehörigkeit einer Ebene (Layer) zum jeweiligen

WMS-Dienst und Informationen über den Layer (z.B. Name, Position und unterstütze Funktionen).

layer_epsg layer Enthält Angaben zum Koordinatensystem und die Koordinaten der jeweiligen Layer. Das Koordinatensystem wird als standardisierter EPSG-Code angegeben.

layer_style layer Enthält Angaben zum Aufruf der Legende des jeweiligen Layers.

Oberflächen (GUIs): gui - Enthält die Liste der GUIs. gui_element gui Enthält alle Elemente, die zu den GUIs gehören (z.B. Buttons,

das Kartenfenster etc.). gui_element_vars gui_element Enthält Variablen für einige GUI-Elemente. gui_mb_user gui, mb_user Enthält die Zugehörigkeit einer GUI zu einem bestimmten

Benutzer aus Mapbenders Benutzerverwaltung. gui_mb_group gui, mb_group Enthält die Zugehörigkeit einer GUI zu einer bestimmten

Gruppe. gui_wms gui, wms Enthält die Zugehörigkeit eines WMS-Dienstes zu einer GUI

und zusätzliche Informationen, die zur Anzeige benötigt werden.

gui_layer gui, layer Enthält die Zugehörigkeit eines Layers zu einer GUI und zusätzliche Informationen, die zur Anzeige benötigt werden.

(Alle verwendeten Tabellen hängen von gui oder wms ab.)

Aufbau der Geoportal Datenbank Tabelle Hängt ab von


Benutzerverwaltung: portal_users - Enthält Informationen über alle Benutzer des Portals (z.B.

User-ID, Name und E-Mail-Adresse). portal_groups - Enthält Informationen über alle Gruppen des Portals (z.B.

Name). portal_useringroup portal_users,

portal_groups Enthält die Zuordnung eines Benutzers zu einer Gruppe.

6 Anhänge

118

Meeting Planner: portal_meetings - Enthält Informationen über alle Meetings des Meeting

Planners (z.B. Name, Ort und Status). portal_meetingdates portal_meetings Enthält Start- und Endzeiten zu den Meetings. portal_userinmeeting portal_users,

portal_meetings, portal_meetingdates

Enthält die Zuordnung eines Benutzers zu einem Meeting, sowie für welche Zeit des Meetings der Benutzer abgestimmt hat.

Sonstige: portal_links - Enthält alle Daten, die für die statischen Links des Portals

benötigt werden (z.B. URLs, Titel und Typ des Links). portal_information - Enthält alle Daten, die für die Informationsseiten des

Portals benötigt werden (z.B. Titel und HTML Code des Inhalts).

Aufbau der Metadatenbank Tabelle Hängt ab von


Daten: md_datasets - Enthält Informationen über alle Datensätze in der

Metadatenbank (Identifier, Zeitstempel, Status). md_dc_values md_datasets Enthält Werte zu fast allen Elementen der Datensätze

(außer zu Bounding Boxen und Beschreibungen) und die Zuordnung zum jeweiligen Datensatz.

md_dc_box md_datasets Enthält die Werte einer Bounding Box (N, S, E, W und die Einheit) und die Zuordnung der Box zu einem Datensatz.

md_dc_description md_datasets Enthält die Werte zu den Beschreibungselementen der Datensätze (anderer Datentyp als die Werte der anderen Elemente) und die Zuordnung zum jeweiligen Datensatz.

Aufbau: md_elements - Enthält Informationen über alle verwendeten

Metadatenelemente (außer Bounding Boxen und Beschreibungen). Diese Angaben verwendet das Portal, um die erweiterte Suche, den Metadateneditor und die Anzeige von Metadaten an die tatsächlich vorhandenen Elemente anzupassen. Enthaltene Angaben: Interner Name, Beschriftung, Reihenfolge, ob das Element allen Benutzern angezeigt werden soll und ob das Element pro Datensatz mehrfach oder einfach vorkommen darf. Außerdem gibt es eine nicht ausgewertete Angabe, ob das Element eine Verfeinerung darstellt und wenn ja, von welchem Element es abstammt (siehe Dublin Core Standard).

md_preset_values - Enthält optionale Vorgabewerte für die verwendeten Metadatenelemente (außer für Bounding Boxen und Beschreibungen).

6.4 Vollständiges Datenbankschema des Portals -- Table for links CREATE TABLE portal_links ( linkid INTEGER PRIMARY KEY NOT NULL, url VARCHAR(2000) NOT NULL, img VARCHAR(2000) NOT NULL DEFAULT '',

6.4 Vollständiges Datenbankschema des Portals

119

title VARCHAR(100) NOT NULL, displayname VARCHAR(100) NOT NULL, type VARCHAR(8) NOT NULL, l_order SMALLINT NOT NULL, CONSTRAINT valid_type CHECK (type='menubar' OR type='overview') ); -- Views for links CREATE OR REPLACE VIEW portal_menubarlinks_in_order AS SELECT url,title,displayname FROM portal_links WHERE type='menubar' ORDER BY l_order ASC; CREATE OR REPLACE VIEW portal_overviewlinks_in_order AS SELECT url,img,title,displayname FROM portal_links WHERE type='overview' ORDER BY l_order ASC; -- Sequence for links CREATE SEQUENCE portal_links_seq MINVALUE 1 MAXVALUE 2147483647 START WITH 1 INCREMENT BY 1 CYCLE CACHE 1; -- More tables for Geoportal CREATE TABLE PORTAL_USERS ( USERNAME VARCHAR(30) PRIMARY KEY NOT NULL, PASSWORD VARCHAR(24) NOT NULL, UID INTEGER UNIQUE NOT NULL, FORENAME VARCHAR(100), LASTNAME VARCHAR(100), DESCRIPTION VARCHAR(100), EMAIL VARCHAR(100), LOCATION VARCHAR(100) ); INSERT INTO PORTAL_USERS VALUES ('admin','ISMvKXpXpadDiUoOSoAfww==',0,null,null, 'Geoportal default administrator - do not delete!',null,null); CREATE TABLE PORTAL_GROUPS ( GROUPNAME VARCHAR(30) PRIMARY KEY NOT NULL, DESCRIPTION VARCHAR(100) ); INSERT INTO PORTAL_GROUPS VALUES ('admins','Geoportal administrators - do not delete!'); INSERT INTO PORTAL_GROUPS VALUES ('meetingadmins','Meeting planner administrators.'); INSERT INTO PORTAL_GROUPS VALUES ('metadataadmins','Metadata administrators.'); INSERT INTO PORTAL_GROUPS VALUES ('metadatauploader','Metadata uploader.');

6 Anhänge

120

CREATE TABLE PORTAL_USERINGROUP ( USERNAME_FK VARCHAR(30) NOT NULL REFERENCES PORTAL_USERS(USERNAME) ON DELETE CASCADE, GROUPNAME_FK VARCHAR(30) NOT NULL REFERENCES PORTAL_GROUPS(GROUPNAME) ON DELETE CASCADE, UNIQUE(USERNAME_FK,GROUPNAME_FK) ); INSERT INTO PORTAL_USERINGROUP(USERNAME_FK,GROUPNAME_FK) VALUES ('admin','admins'); CREATE TABLE portal_information ( infoid INTEGER PRIMARY KEY NOT NULL, title VARCHAR(100) NOT NULL, show_in_index BOOLEAN DEFAULT 'f', index_desc VARCHAR(150) NOT NULL DEFAULT '', i_order SMALLINT NOT NULL DEFAULT 0, htmlcode TEXT NOT NULL ); -- View for Geoportal CREATE OR REPLACE VIEW portal_information_no_html_in_order AS SELECT infoid,title,show_in_index,index_desc FROM portal_information ORDER BY i_order ASC; -- Sequences for Geoportal CREATE SEQUENCE PORTAL_UID_SEQ MINVALUE 1 MAXVALUE 2147483647 START WITH 10 INCREMENT BY 1 NO CYCLE CACHE 1; CREATE SEQUENCE portal_information_seq MINVALUE 1 MAXVALUE 2147483647 START WITH 1 INCREMENT BY 1 NO CYCLE CACHE 1; -- Tables for meeting planner CREATE TABLE PORTAL_MEETINGS ( MEETING_ID INTEGER PRIMARY KEY NOT NULL, MEETINGNAME VARCHAR(100) NOT NULL, DESCRIPTION VARCHAR(200) NOT NULL, LOCATION VARCHAR(100) NOT NULL, FINAL CHAR(1) DEFAULT 'n' ); CREATE TABLE PORTAL_MEETINGDATES ( MD_ID INTEGER PRIMARY KEY NOT NULL, PARENT_MEETING INTEGER NOT NULL REFERENCES PORTAL_MEETINGS(MEETING_ID) ON DELETE CASCADE,

6.5 Änderungen an der Mapbender-Datenbank

121

STARTTIME VARCHAR(20) NOT NULL, ENDTIME VARCHAR(20) NOT NULL ); CREATE TABLE PORTAL_USERINMEETING( MEETING_ID INTEGER NOT NULL REFERENCES PORTAL_MEETINGS(MEETING_ID) ON DELETE CASCADE, USERNAME VARCHAR(30) NOT NULL REFERENCES PORTAL_USERS(USERNAME) ON DELETE CASCADE, VOTE_FOR_DATE INTEGER REFERENCES PORTAL_MEETINGDATES(MD_ID), UNIQUE(MEETING_ID,USERNAME) ); -- Sequences for meeting planner CREATE SEQUENCE PORTAL_MEETINGS_SEQ MINVALUE 1 MAXVALUE 2147483647 START WITH 1 INCREMENT BY 1 CYCLE CACHE 1; CREATE SEQUENCE PORTAL_MEETINGDATES_SEQ MINVALUE 1 MAXVALUE 2147483647 START WITH 1 INCREMENT BY 1 CYCLE CACHE 1;

6.5 Änderungen an der Mapbender-Datenbank -- Table for functions (see below) CREATE TABLE portal_ids ( type VARCHAR(12) NOT NULL, value INTEGER NOT NULL, PRIMARY KEY(type) ); -- Values for table INSERT INTO portal_ids (type, value) VALUES('wmsmin',10000); INSERT INTO portal_ids (type, value) VALUES('wmsmax',2147483647); INSERT INTO portal_ids (type, value) VALUES('wmscurrent',10000); INSERT INTO portal_ids (type, value) VALUES('layermin',200000); INSERT INTO portal_ids (type, value) VALUES('layermax',2147483647); INSERT INTO portal_ids (type, value) VALUES('layercurrent',200001); -- Before inserting functions you have to install the used language to the -- database (only once) CREATE LANGUAGE plpgsql; -- Function to get the next wms_id (and delete, if it was already used) CREATE OR REPLACE FUNCTION get_wms_id() RETURNS integer AS $$ DECLARE my_wms_id integer;

6 Anhänge

122

my_gui_id varchar(50); current_wms_id integer; min_wms_id integer; max_wms_id integer; BEGIN /* Get current WMS ID from table */ SELECT INTO current_wms_id value FROM portal_ids WHERE type='wmscurrent'; /* Get minimal WMS ID from table */ SELECT INTO min_wms_id value FROM portal_ids WHERE type='wmsmin'; /* Get maximal WMS ID from table */ SELECT INTO max_wms_id value FROM portal_ids WHERE type='wmsmax'; /* Generate a new WMS ID */ IF current_wms_id = max_wms_id THEN /* If maximum integer value is reached start with minimum WMD ID value given */ my_wms_id := min_wms_id; ELSE /* Else just increase WMS ID by 1 */ my_wms_id := current_wms_id + 1; END IF; /* Generate the GUI ID from the WMS ID */ my_gui_id := 'temp'||my_wms_id; /* Delete WMS ID from Mapbender tables (cleanup) */ DELETE FROM wms WHERE wms_id = my_wms_id; DELETE FROM gui WHERE gui_id = my_gui_id; /* Store new current WMS ID to table */ UPDATE portal_ids SET value=my_wms_id WHERE type='wmscurrent'; RETURN my_wms_id; END; $$ LANGUAGE plpgsql; -- Function to get the next layer_id (and delete, if it was already used) CREATE OR REPLACE FUNCTION get_layer_id() RETURNS integer AS $$ DECLARE my_layer_id integer; current_layer_id integer; min_layer_id integer; max_layer_id integer; BEGIN /* Get current layer ID from table */ SELECT INTO current_layer_id value FROM portal_ids WHERE type='layercurrent'; /* Get minimal layer ID from table */ SELECT INTO min_layer_id value FROM portal_ids WHERE type='layermin'; /* Get maximal layer ID from table */ SELECT INTO max_layer_id value FROM portal_ids WHERE type='layermax'; /* Generate a new layer ID */

6.6 Änderungen am Quellcode von Mapbender

123

IF current_layer_id = max_layer_id THEN /* If maximum integer value is reached start with minimum layer ID value given */ my_layer_id := min_layer_id; ELSE /* Else just increase layer ID by 1 */ my_layer_id := current_layer_id + 1; END IF; /* Delete layer ID from Mapbender tables (cleanup) */ DELETE FROM layer WHERE layer_id = my_layer_id; /* Store new current layer ID to table */ UPDATE portal_ids SET value=my_layer_id WHERE type='layercurrent'; RETURN my_layer_id; END; $$ LANGUAGE plpgsql; -- Insert element for download icon in GUI geoportal -- GUI geoportal must already exitst before you execute this INSERT INTO gui_element(fkey_gui_id, e_id, e_pos, e_public, e_comment, e_element, e_src, e_attributes, e_left, e_top, e_width, e_height, e_z_index, e_more_styles, e_content, e_closetag, e_js_file, e_mb_mod, e_target, e_requires, e_url) VALUES('geoportal','geoportalDownload',2,1, 'Download data with geoportal','img', '../img/button_blink_red/download_off.png', 'onclick=''window.open("http://server/Geoportal/mapdownloader/", "printWin","width=520, height=300, left=300, resizable=yes, scrollbars=yes")'' onmouseover=''this.src = this.src.replace(/_off/,"_over");'' onmouseout=''this.src = this.src.replace(/_over/, "_off");'' title="Download Data"',600,60,24,24,1,'','','','','','','', 'http://www.iai.uni-bonn.de/'); -- Make sure you checked the URL in the SQL command -- (...'window.open("URL",...). This URL must be set to the same server name -- that Geoportal uses, because Geoportal will be called and used for -- downloading.

6.6 Änderungen am Quellcode von Mapbender Um den SLD-Editor von Mapbender 2.5 in die baumartige Ebenenansicht (TreeGDE) zu integrieren, müssen einige Änderungen am Quellcode von Mapbender durchgeführt werden. Da die finale Version von Mapbender 2.5 nicht rechtzeitig fertig wurde, werden hier die Änderungen anhand des Release Candidate 2 (RC2) von Mapbender 2.5 beschrieben:

• Alle Änderungen werden in der Datei <Mapbender-Installationsverzeichnis>\http\html\ mod_treefolder2.php durchgeführt, die für die Darstellung des TreeGDE zuständig ist.

• Eine PNG-Datei, die später das Icon zum Aufrufen des Editors darstellen soll, muss unter dem Namen sld.png im Verzeichnis <Mapbender-Installationsverzeichnis>\http\img\ tree_new abgelegt werden.

6 Anhänge

124

• In Funktion initArray() vor Zeile 535 wird eine neue Zeile hinzugefügt, die den Aufruf des SLD-Editors aus der Ebenenansicht für jede Ebene ermöglicht:

if(showsldeditor == 'true')controls+= '<a href="'+' javascript:openwindow(\'../sld/sld_main.php?sld_gui_id= <?php echo $gui_id; ?> &sld_wms_id='+parent.mb_mapObj[i].wms[ii].wms_id+' &sld_layer_name='+temp.layer_name+'\');'+'"> <img src="'+imagedir+'/sld.png" /></a>';

• Die einleitende if-Abfrage verhindert die Anzeige des SLD-Editors solange, bis für das GUI-Elements treeGDE in der Mapbender-GUI geoportal die Variable showsldeditor mit dem Wert true hinzugefügt wurde. Damit es nicht zu einer Fehlermeldung kommt, falls diese Variable fehlt, muss in Zeile 80 noch ein Standardwert für diese Variable gesetzt werden:

try{if (showsldeditor){}}catch(e){showsldeditor = 'false';}

6.7 Vollständiges Schema der Metadatenbank -- Tables for metadata CREATE TABLE md_datasets ( identifier VARCHAR(255) PRIMARY KEY, t_stamp TIMESTAMP WITH TIME ZONE NOT NULL, checked BOOLEAN DEFAULT 'f' ); CREATE TABLE md_elements ( element VARCHAR(20) PRIMARY KEY, refines VARCHAR(20), e_label VARCHAR(30) NOT NULL, show_element CHAR(1) NOT NULL, is_multiple BOOLEAN DEFAULT 't', e_order SMALLINT NOT NULL ); INSERT INTO md_elements(element,refines,e_label,show_element,is_multiple,e_order) VALUES('title',null,'Title','y','t',10); INSERT INTO md_elements VALUES('creator',null,'Creators','y','t',20); INSERT INTO md_elements VALUES('publisher',null,'Publishers','y','t',30); INSERT INTO md_elements VALUES('contributor',null,'Contributors','y','t',40); INSERT INTO md_elements VALUES('subject',null,'Subjects','y','t',50); INSERT INTO md_elements VALUES('subject_variable','subject','Subjects (user defined)','y','t',50); INSERT INTO md_elements VALUES('date',null,'Date','y','f',60); INSERT INTO md_elements VALUES('accessinformation','notdc','Access informations','y','t',70); INSERT INTO md_elements VALUES('type',null,'Resource type','y','f',80); INSERT INTO md_elements VALUES('format',null,'Formats','y','t',90); INSERT INTO md_elements VALUES('qualitycontrol','notdc','Quality control','y','t',100); INSERT INTO md_elements VALUES('temporalcoverage','coverage','Temporal coverages','y','t',110); INSERT INTO md_elements

6.7 Vollständiges Schema der Metadatenbank

125

VALUES('spatialcoverage','coverage','Spatial coverages','y','t',120); INSERT INTO md_elements VALUES('language',null,'Languages','y','t',130); INSERT INTO md_elements VALUES('source',null,'Sources','y','t',140); INSERT INTO md_elements VALUES('relation',null,'Relations','y','t',150); INSERT INTO md_elements VALUES('coordinatesystem','notdc','Coordinate system','y','f',160); INSERT INTO md_elements VALUES('url','notdc','URLs','n','t',170); INSERT INTO md_elements VALUES('accessrights','rights','Access rights','n','t',180); INSERT INTO md_elements VALUES('attribute','notdc','Attributes','y','t',190); INSERT INTO md_elements VALUES('si_type','notdc','Sat image type','y','f',200); INSERT INTO md_elements VALUES('si_acquisitiondate','notdc','Sat image acquisition date','y','f',210); CREATE TABLE md_dc_description ( identifier VARCHAR(255) NOT NULL REFERENCES md_datasets(identifier) ON DELETE CASCADE, description TEXT NOT NULL, UNIQUE(identifier,description) ); CREATE TABLE md_dc_box ( identifier VARCHAR(255) NOT NULL REFERENCES md_datasets(identifier) ON DELETE CASCADE, northlimit NUMERIC(15,7) NOT NULL, southlimit NUMERIC(15,7) NOT NULL, eastlimit NUMERIC(14,7) NOT NULL, westlimit NUMERIC(14,7) NOT NULL, unit VARCHAR(15) NOT NULL, CONSTRAINT valid_northlimit CHECK ((unit = 'decimal degrees' AND northlimit <= 90 AND northlimit >= -90) OR (unit = 'meters' AND northlimit <= 99999999.999 AND northlimit >= 0)), CONSTRAINT valid_southlimit CHECK ((unit = 'decimal degrees' AND southlimit >= -90 AND southlimit <= 90) OR (unit = 'meters' AND southlimit <= 99999999.999 AND southlimit >= 0)), CONSTRAINT valid_eastlimit CHECK ((unit = 'decimal degrees' AND eastlimit <= 180 AND eastlimit >= -180) OR (unit = 'meters' AND eastlimit <= 9999999.999 AND eastlimit >= 0)), CONSTRAINT valid_westlimit CHECK ((unit = 'decimal degrees' AND westlimit >= -180 AND westlimit <= 180) OR (unit = 'meters' AND westlimit <= 9999999.999 AND westlimit >= 0)), UNIQUE(identifier) ); CREATE TABLE md_dc_values ( identifier VARCHAR(255) NOT NULL REFERENCES md_datasets(identifier) ON DELETE CASCADE, element VARCHAR(20) NOT NULL, e_value VARCHAR(255) NOT NULL, UNIQUE(identifier,element,e_value) ); CREATE TABLE md_preset_values ( element VARCHAR(20) NOT NULL REFERENCES md_elements(element) ON DELETE CASCADE,

6 Anhänge

126

preset VARCHAR(255) NOT NULL, UNIQUE(element,preset) ); -- Preset values (please adjust to your preferences) INSERT INTO md_preset_values(element,preset) VALUES('subject','Agriculture > Agricultural Aquatic Sciences > Aquaculture'); INSERT INTO md_preset_values VALUES('subject','Agriculture > Agricultural Aquatic Sciences > Fisheries'); INSERT INTO md_preset_values VALUES('subject','Agriculture > Agricultural Chemicals > Fertilizers'); INSERT INTO md_preset_values VALUES('subject','Agriculture > Agricultural Chemicals > Pesticides'); INSERT INTO md_preset_values VALUES('subject','Agriculture > Agricultural Engineering > Agricultural Equipment'); INSERT INTO md_preset_values VALUES('subject','Agriculture > Agricultural Engineering > Farm Structures'); INSERT INTO md_preset_values VALUES('subject','Agriculture > Agricultural Plant Science > Crop/Plant Yields'); INSERT INTO md_preset_values VALUES('subject','Agriculture > Agricultural Plant Science > Cropping Systems'); INSERT INTO md_preset_values VALUES('subject','Agriculture > Agricultural Plant Science > Irrigation'); INSERT INTO md_preset_values VALUES('subject','Agriculture > Agricultural Plant Science > Plant Breeding and Genetics'); INSERT INTO md_preset_values VALUES('subject','Agriculture > Agricultural Plant Science > Plant Diseases/Disorders/Pests'); -- Für eine bessere Übersichtlichkeit wurden die restlichen Vorgabewerte -- für das Element subject hier nicht aufgelistet. Die vollständige Liste -- liegt dem Geoportal bei. INSERT INTO md_preset_values VALUES('language','en'); INSERT INTO md_preset_values VALUES('language','en-US'); INSERT INTO md_preset_values VALUES('language','fr'); INSERT INTO md_preset_values VALUES('language','de'); INSERT INTO md_preset_values VALUES('language','de-DE'); INSERT INTO md_preset_values VALUES('language','de-AT'); INSERT INTO md_preset_values VALUES('language','de-CH'); INSERT INTO md_preset_values(element,preset) VALUES('type','Dataset'); INSERT INTO md_preset_values(element,preset) VALUES('type','DatasetCollection'); INSERT INTO md_preset_values(element,preset) VALUES('type','Text-Document'); INSERT INTO md_preset_values(element,preset) VALUES('type','Image'); INSERT INTO md_preset_values(element,preset) VALUES('type','MapProject'); INSERT INTO md_preset_values(element,preset) VALUES('type','WebMapService'); INSERT INTO md_preset_values(element,preset) VALUES('type','ExternalWebGISService'); INSERT INTO md_preset_values(element,preset) VALUES('type','Googlemap'); INSERT INTO md_preset_values(element,preset) VALUES('type','Software'); INSERT INTO md_preset_values(element,preset) VALUES('type','Other');

6.7 Vollständiges Schema der Metadatenbank

127

INSERT INTO md_preset_values VALUES('format','ASCII Text'); INSERT INTO md_preset_values VALUES('format','Portable Document Format (PDF)'); INSERT INTO md_preset_values VALUES('format','XML'); INSERT INTO md_preset_values VALUES('format','HTML'); INSERT INTO md_preset_values VALUES('format','MS Word'); INSERT INTO md_preset_values VALUES('format','MS Excel'); INSERT INTO md_preset_values VALUES('format','MS Access'); INSERT INTO md_preset_values VALUES('format','IMAGE22 UNF'); INSERT INTO md_preset_values VALUES('format','ArcView Grid'); INSERT INTO md_preset_values VALUES('format','ArcView Shape'); INSERT INTO md_preset_values VALUES('format','ArcGIS Geodatabase'); INSERT INTO md_preset_values VALUES('format','Executable Program - Linux'); INSERT INTO md_preset_values VALUES('format','Executable Program - MS Windows'); INSERT INTO md_preset_values VALUES('format','Executable Program - Sun Solaris'); INSERT INTO md_preset_values VALUES('format','Proprietary Binary Format'); INSERT INTO md_preset_values VALUES('format','Other'); INSERT INTO md_preset_values(element,preset) VALUES('coordinatesystem',''); INSERT INTO md_preset_values VALUES('coordinatesystem','4326 WGS 84 geographic 2D'); INSERT INTO md_preset_values VALUES('coordinatesystem','32630 WGS 84 / UTM zone 30N projected'); INSERT INTO md_preset_values VALUES('coordinatesystem','32631 WGS 84 / UTM zone 31N projected'); INSERT INTO md_preset_values VALUES('si_type',''); INSERT INTO md_preset_values VALUES('si_type','Landsat ETM+'); INSERT INTO md_preset_values VALUES('si_type','Landsat TM'); INSERT INTO md_preset_values VALUES('si_type','Landsat MSS'); INSERT INTO md_preset_values VALUES('si_type','Aster L1B'); INSERT INTO md_preset_values VALUES('si_type','Quickbird'); INSERT INTO md_preset_values VALUES('si_type','MODIS'); -- Views for metadata access CREATE OR REPLACE VIEW md_elements_in_order AS SELECT element,e_label,show_element FROM md_elements ORDER BY e_order ASC; CREATE OR REPLACE VIEW md_single_elements AS SELECT element FROM md_elements WHERE is_multiple='f' ORDER BY e_order ASC; CREATE OR REPLACE VIEW md_checked_datasets AS SELECT * FROM md_datasets WHERE checked=TRUE; CREATE OR REPLACE VIEW md_checked_dc_values AS SELECT v.* FROM md_dc_values v, md_datasets d WHERE d.identifier=v.identifier AND d.checked=TRUE; CREATE OR REPLACE VIEW md_checked_dc_description AS SELECT d2.* FROM md_datasets d1, md_dc_description d2 WHERE d1.identifier=d2.identifier AND d1.checked=TRUE; CREATE OR REPLACE VIEW md_checked_dc_box AS SELECT b.* FROM md_datasets d, md_dc_box b WHERE d.identifier=b.identifier AND d.checked=TRUE;

6 Anhänge

128

6.8 Beispiel einer XML-Datei für Metadaten <?xml version="1.0" encoding="UTF-8" standalone="no"?> <zef:metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dc="http://md.zef.de/dc/elements/1.1/" xmlns:dcterms="http://md.zef.de/dcterms/elements/1.1/" xmlns:zef="http://md.zef.de/notdc/elements/1.0/" xsi:schemaLocation="http://md.zef.de/dc/elements/1.1/ http://server/gvp-dc.xsd http://md.zef.de/dcterms/elements/1.1/ http://server/gvp-dcterms.xsd http://md.zef.de/notdc/elements/1.0/ http://server/gvp-zef.xsd" version="1.0"> <zef:record t_stamp="1234567891"> <dc:identifier>urn:x-gvp:10:ds-pri.test.ghana.v1.shp.dl</dc:identifier> <dcterms:box unit="decimal degrees"> <dcterms:northlimit>12.0000000</dcterms:northlimit> <dcterms:southlimit>4.0000000</dcterms:southlimit> <dcterms:eastlimit>1.5000000</dcterms:eastlimit> <dcterms:westlimit>-4.0000000</dcterms:westlimit> </dcterms:box> <dc:description>Dies ist eine Beschreibung.</dc:description> <dc:title>Beispielkarte von Ghana</dc:title> <dc:creator>Joscha Laubach</dc:creator> <dc:publisher>Joscha Laubach</dc:publisher> <dc:subject>Land Surface > Landscape > Landscape Management</dc:subject> <dc:date>2008-05-26</dc:date> <dc:type>MAP</dc:type> <dc:format>ArcView Shape</dc:format> <dc:language>de</dc:language> <dcterms:temporalcoverage>2008</dcterms:temporalcoverage> <dcterms:spatialcoverage>Ghana</dcterms:spatialcoverage> <dcterms:accessrights>all</dcterms:accessrights> <zef:url>relmapfile://beispielkarte/ghana.map</zef:url> <zef:url>relmapdata://beispielkarte/</zef:url> <zef:accessinformation>Download</zef:accessinformation> <zef:qualitycontrol>Nichtexistetes Beispiel</zef:qualitycontrol> <zef:coordinatesystem>4326 WGS 84 geographic 2D</zef:coordinatesystem> </zef:record>  </zef:metadata>

6.9 Schema für die Metadaten in XML Das XMLSchema für die XML-Metadatendateien des Geoportals setzt sich aufgrund der drei verwendeten Namespaces aus drei verschiedenen Dateien zusammen.

• gvp-zef.xsd für ZEF-eigene Dublin Core Metadatenelemente (NotDC-Namespace): <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:dc="http://md.zef.de/dc/elements/1.1/" xmlns:dcterms="http://md.zef.de/dcterms/elements/1.1/" xmlns:zef="http://md.zef.de/notdc/elements/1.0/"

6.9 Schema für die Metadaten in XML

129

targetNamespace="http://md.zef.de/notdc/elements/1.0/" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:annotation> <xsd:documentation xml:lang="en"> Base Schema (NotDC Namespace) for GLOWA Volta Dublin Core XML files. Copyright 2008 Joscha Laubach. All rights reserved. Version 1.0 </xsd:documentation> </xsd:annotation> <xsd:import namespace="http://md.zef.de/dc/elements/1.1/" schemaLocation="http://server/gvp-dc.xsd"/> <xsd:import namespace="http://md.zef.de/dcterms/elements/1.1/" schemaLocation="http://server/gvp-dcterms.xsd"/> <xsd:element name="metadata" type="zef:MetadataType"/> <xsd:complexType name="MetadataType"> <xsd:all minOccurs="0"> <xsd:element name="record" type="zef:RecordType"/> </xsd:all> <xsd:attribute name="version" type="zef:VersionNo"/> </xsd:complexType> <xsd:complexType name="RecordType"> <xsd:sequence> <xsd:element ref="dc:identifier"/> <xsd:element ref="dcterms:box" minOccurs="0" maxOccurs="1"/> <xsd:choice minOccurs="0" maxOccurs="unbounded"> <xsd:element ref="dc:description"/> <xsd:element ref="dc:title"/> <xsd:element ref="dc:creator"/> <xsd:element ref="dc:publisher"/> <xsd:element ref="dc:contributor"/> <xsd:element ref="dc:subject"/> <xsd:element ref="dc:date"/> <xsd:element ref="dc:type"/> <xsd:element ref="dc:format"/> <xsd:element ref="dc:language"/> <xsd:element ref="dc:source"/> <xsd:element ref="dc:relation"/> <xsd:element ref="dcterms:temporalcoverage"/> <xsd:element ref="dcterms:spatialcoverage"/> <xsd:element ref="dcterms:accessrights"/> <xsd:element name="url" type="zef:UrlType"/> <xsd:element name="accessinformation" type="zef:DefaultType"/> <xsd:element name="qualitycontrol" type="zef:DefaultType"/> <xsd:element name="coordinatesystem" type="zef:CoordinatesystemType"/> </xsd:choice> </xsd:sequence> <xsd:attribute name="t_stamp" type="xsd:long"/> </xsd:complexType> <xsd:simpleType name="VersionNo"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="1.0"/>

6 Anhänge

130

</xsd:restriction> </xsd:simpleType> <xsd:simpleType name="DefaultType"> <xsd:restriction base="xsd:string"> <xsd:minLength value="1"/> <xsd:maxLength value="255"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="UrlType"> <xsd:restriction base="xsd:string"> <xsd:pattern value="(reldata|relmapfile|relmapdata|relmapgdb|relgdb| googlemaps|map|wms|http|https|ftp){1}(://){1}.+"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="CoordinatesystemType"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="4326 WGS 84 geographic 2D"/> <xsd:enumeration value="32630 WGS 84 / UTM zone 30N projected"/> <xsd:enumeration value="32631 WGS 84 / UTM zone 31N projected"/>  </xsd:restriction> </xsd:simpleType> </xsd:schema> • gvp-dc.xsd für Dublin Core Metadatenelemente (DC-Namespace): <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:dc="http://md.zef.de/dc/elements/1.1/" targetNamespace="http://md.zef.de/dc/elements/1.1/" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:annotation> <xsd:documentation xml:lang="en"> Schema (DC Namespace) for GLOWA Volta Dublin Core XML files. Copyright 2008 Joscha Laubach. All rights reserved. Version 1.0 </xsd:documentation> </xsd:annotation> <xsd:element name="identifier" type="dc:IdentifierType"/> <xsd:element name="description" type="xsd:string"/> <xsd:element name="title" type="dc:DefaultType"/> <xsd:element name="creator" type="dc:DefaultType"/> <xsd:element name="publisher" type="dc:DefaultType"/> <xsd:element name="contributor" type="dc:DefaultType"/> <xsd:element name="subject" type="dc:SubjectType"/> <xsd:element name="date" type="xsd:date"/> <xsd:element name="type" type="dc:TypeType"/> <xsd:element name="format" type="dc:FormatType"/> <xsd:element name="language" type="xsd:language"/> <xsd:element name="source" type="dc:DefaultType"/> <xsd:element name="relation" type="dc:DefaultType"/>

6.9 Schema für die Metadaten in XML

131

<xsd:simpleType name="DefaultType"> <xsd:restriction base="xsd:string"> <xsd:minLength value="1"/> <xsd:maxLength value="255"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="IdentifierType"> <xsd:restriction base="xsd:string"> <xsd:pattern value="(urn:x\-gvp:){1}([0-9])+:([A-Z]|[a-z]|[0-9]| \+|_|\.|\-)+"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="SubjectType"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="Agriculture > Agricultural Aquatic Sciences > Aquaculture"/> <xsd:enumeration value="Agriculture > Agricultural Aquatic Sciences > Fisheries"/> <xsd:enumeration value="Agriculture > Agricultural Chemicals > Fertilizers"/> <xsd:enumeration value="Agriculture > Agricultural Chemicals > Pesticides"/> <xsd:enumeration value="Agriculture > Agricultural Engineering > Agricultural Equipment"/> <xsd:enumeration value="Agriculture > Agricultural Engineering > Farm Structures"/> <xsd:enumeration value="Agriculture > Agricultural Plant Science > Crop/Plant Yields"/> <xsd:enumeration value="Agriculture > Agricultural Plant Science > Cropping Systems"/> <xsd:enumeration value="Agriculture > Agricultural Plant Science > Irrigation"/> <xsd:enumeration value="Agriculture > Agricultural Plant Science > Plant Breeding and Genetics"/> <xsd:enumeration value="Agriculture > Agricultural Plant Science > Plant Diseases/Disorders/Pests"/>   </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="TypeType"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="Text-Document"/> <xsd:enumeration value="Image"/> <xsd:enumeration value="MapProject"/> <xsd:enumeration value="WebMapService"/> <xsd:enumeration value="ExternalWebGISService"/> <xsd:enumeration value="Googlemap"/> <xsd:enumeration value="Software"/> <xsd:enumeration value="Other"/>

6 Anhänge

132

</xsd:restriction> </xsd:simpleType> <xsd:simpleType name="FormatType"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="ArcGIS Geodatabase"/> <xsd:enumeration value="ArcView Grid"/> <xsd:enumeration value="ArcView Shape"/> <xsd:enumeration value="ASCII Text"/> <xsd:enumeration value="Executable Program - Linux"/> <xsd:enumeration value="Executable Program - MS Windows"/> <xsd:enumeration value="Executable Program - Sun Solaris"/> <xsd:enumeration value="HTML"/> <xsd:enumeration value="IMAGE22 UNF"/> <xsd:enumeration value="MS Access"/> <xsd:enumeration value="MS Excel"/> <xsd:enumeration value="MS Word"/> <xsd:enumeration value="Portable Document Format (PDF)"/> <xsd:enumeration value="Proprietary Binary Format"/> <xsd:enumeration value="XML"/> <xsd:enumeration value="Other"/>  </xsd:restriction> </xsd:simpleType> </xsd:schema> • gvp-dcterms.xsd für verfeinerte Dublin Core Metadatenelemente (DCTERMS-Namespace): <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:dcterms="http://md.zef.de/dcterms/elements/1.1/" targetNamespace="http://md.zef.de/dcterms/elements/1.1/" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:annotation> <xsd:documentation xml:lang="en"> Schema (DCTerms Namespace) for GLOWA Volta Dublin Core XML files. Copyright 2008 Joscha Laubach. All rights reserved. Version 1.0 </xsd:documentation> </xsd:annotation> <xsd:element name="box" type="dcterms:BoxType"/> <xsd:element name="temporalcoverage" type="dcterms:DefaultType"/> <xsd:element name="spatialcoverage" type="dcterms:DefaultType"/> <xsd:element name="accessrights" type="dcterms:RightsType"/> <xsd:complexType name="BoxType"> <xsd:all minOccurs="1"> <xsd:element name="northlimit" type="dcterms:LimitType"/> <xsd:element name="southlimit" type="dcterms:LimitType"/> <xsd:element name="eastlimit" type="dcterms:LimitType"/> <xsd:element name="westlimit" type="dcterms:LimitType"/> </xsd:all> <xsd:attribute name="unit" type="dcterms:UnitType"/> </xsd:complexType>

6.10 URLs im Geoportal und ihre Bedeutung

133

<xsd:simpleType name="DefaultType"> <xsd:restriction base="xsd:string"> <xsd:minLength value="1"/> <xsd:maxLength value="255"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="RightsType"> <xsd:restriction base="xsd:string"> <xsd:pattern value="(u:([A-Z]|[a-z]|[0-9]|\+|_|\.|\-)+)| (g:([A-Z]|[a-z]|[0-9]|\+|_|\.|\-)+)|(all)|(everybody)"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="LimitType"> <xsd:restriction base="xsd:string"> <xsd:pattern value="\-?\d{1,8}\.?\d{0,7}"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="UnitType"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="decimal degrees"/> <xsd:enumeration value="meters"/> </xsd:restriction> </xsd:simpleType> </xsd:schema>

6.10 URLs im Geoportal und ihre Bedeutung URL Bedeutung Beispiel URLs für externe Links: http:// https:// ftp://

Links auf externe Webseiten oder Dateien. Werden von jedem Viewer als Links angezeigt, wenn vorhanden.

http://de.wikipedia.org/wiki/Hyperklink

URLs für dynamische Karten: Die Daten für diese Karten müssen zunächst vom Datenserver auf den Webserver transferiert werden. Außerdem muss der Mapbender individuell konfiguriert werden. Erst dann können die Karten angezeigt werden. Dies ist der Normalfall für Karten des Geoportals. relmapfile:// Relative Angabe* des Lageorts der

Konfigurationsdatei des UMN MapServers für die jeweilige Karte auf dem Datenserver.

relmapfile://beispielkarte/beispiel.map

relmapdata:// Relative Angabe* des Lageorts der Geodaten (Verzeichnis) zu der jeweiligen Karte auf dem Datenserver.

relmapdata://beispielkarte/

relmapgdb:// Relative Angabe* des Lageorts der Geodaten zu der jeweiligen Karte in einer ESRI Geodatenbank auf dem Datenserver.

relmapgdb://gdbs/test.mdb/Feature1;Feature2 oder relmapgdb://fgdbs/test.gdb/Feature1;Feature2

6 Anhänge

134

URLs für statische Karten: Diese Karten sind bereits fertig konfiguriert und müssen nicht vom Geoportal dynamisch erzeugt werden. Sie können direkt betrachtet werden. map:// Link auf das externe Angebot, das

die Karte anzeigt. map://http://www.testserver.de/karten/karte1

wms:// Optionale Angabe einer WMS-GetCapabilities-URL für die externe Karte.

wms://http://www.testserver.de/wms/mapserv?map=karte1…

URLs für dynamische Daten: Diese Daten müssen vom Datenserver auf den Webserver transferiert werden, um dem Benutzer zum Download angeboten werden zu können. Für statische Daten kann man URLs für externe Links verwenden (s.o.). reldata:// Relative Angabe* des Lageorts der

Daten (Datei oder Verzeichnis) auf dem Datenserver. Eine Datei wird dem Benutzer direkt zum Download angeboten, ein Verzeichnis wird vorher komprimiert (ZIP).

reldata://beispieldaten/ oder reldata://beispieldaten/bericht.doc

relgdb:// Relative Angabe* des Lageorts von Geodaten (ohne Karte) in einer ESRI Geodatenbank auf dem Datenserver.

relgdb://gdbs/test.mdb/Feature3;Feature4 oder relgdb://fgdbs/test.gdb/Feature3;Feature4

URL für GoogleMaps: googlemaps:// Angabe von Längen- und

Breitengrad und dem Zoomfaktor einer GoogleMaps-Karte.

googlemaps://-1.4575,8.74464,12

(* Alle Lageorte auf dem Datenserver sind relativ zu den Pfaden in der Konfigurationsdatei portal.properties des Geoportals angegeben.)

6.11 Umfrage unter Mitarbeitern des ZEF zum Geoportal In diesem Kapitel werden die Fragen und Antworten einer unveröffentlichten Umfrage zum GLOWA Volta Geoportal unter Mitarbeitern des ZEF dargestellt. Es sind nur die Fragen der Umfrage angegeben, die das Geoportal betreffen. Die gesamte Umfrage wurde erstellt von Serge Shumilov, Ivan Denisovich, Antonio Rogmann und Joscha Laubach. Die Grafiken zur Auswertung wurden von Antonio Rogmann erstellt. Insgesamt gingen zu der Umfrage 13 Antworten ein.

Umfrage Under the URL “http://131.220.109.6/Geoportal/index.jsp” you can observe the prototype of the information system “GLOWA Volta Geoportal”. This tool provides several ways to data exchange, searching, visualization and retrieving. Now the GLOWA data management together with the Department for Computer Science III is going to fill up the portal with content. So we are looking for information about your current needs and interests to the publishing and exchange of data online.

What is for you personally the aim of a Web-based information system? I1: to get information about the project activities I2: to get information about available resources and data

6.11 Umfrage unter Mitarbeitern des ZEF zum Geoportal

135

I3: to give meta information about available data that I produce (content, formats, time/spatial cover, quality etc.) I4: to provide facilities for data sharing (upload/download) I5: other: …

Geoportal: aim of a info system

0

2

4

6

8

10

12

14

I1 I2 I3 I4 I5

vote

s

M ultiple Choice, Total number o f responses = 12

Which of the following Geoportal features are the most important for you? Pease give all the listed features priority from 1 - highest to 5 - lowest. A1: quality of available data A2: quantity of available data A3: catalog of all available data clearly arranged to the topics A4: simple search facilities (based on keywords) A5: advanced search facilities (based on forms or maps) A6: overview maps to important topics A7: visualize georeferenced data on maps online A8: online functions for data processing and analysis A9: download and export of data A10: maintain subscriptions to particular datasets and inform subscribed people if new datasets appear A11: upload and integration of new data to the existing online set A12: functions to communicate or chat with other users A13: project management functions (e.g. a meeting planner) A14: possibility to write information texts together with other users (wiki) A15: stable, smooth run and good availability A16: speed A17: help information texts describing about available functions

6 Anhänge

136

Geoportal: priorities for general functions(sorted)

0,000,501,001,502,002,503,003,504,004,505,00

A1 A9 A4 A15 A3 A5 A6 A11 A7 A17 A16 A2 A10 A8 A14 A13 A12

prio

rity

rank

ing

Priority values:1 = lowest priority5 = highest priorityTotal number of responses = 13

If you are trying to find necessary data on a Geoportal, how would you proceed? Pease give all the listed features priority from 1 - highest to 5 – lowest. Take a look at this picture:

find information to objects on an overview map



informationtexts about

specifictopics


specifictopics


specifictopics

use simple search field

go to advancedsearch

list of subjects

browseall

meta-data or

onlyfor a

subject

B1: choose subject from a list and browse through all metadata entries that belong to this subject. B2: browse through all available metadata entries to find the data you need. B3: enter keywords into a simple search field to find your data. B4: follow link to advanced search to specify more complex search criteria (e.g. search in several metadata elements).


137

B5: follow link to advanced search to search for data in specific coordinates. B6: go to prepared overview map and find data visually by clicking on symbols on this map. B7: go to prepared information texts about specific topics and look for linked data there. B8: go to a known map and look for related maps that are linked to this map. B9: I would never use a Geoportal; reason: … B10: other: …

Geoportal: priorities for search functionalities(sorted)

0,00

0,50

1,00

1,50

2,00

2,50

3,00

3,50

4,00

4,50

5,00

B3 B4 B6 B7 B8 B1 B5 B2

prio

rity

rank

ing

Priority values:1 = lowest priority5 = highest priorityTotal number o f responses = 12

If you need to perform a search, which functionalities would you use? C1: a simple search field where I can use multiple keywords. C2: an advanced search form where I can search in particular metadata elements. C3: lists of preselected values in the advanced search that you can choose from (if possible for that element). C4: a spatial search where you can look for data that belongs to certain coordinates or a region on a map. C5: I would like to select these coordinates on a small map (instead of typing the coordinates as numbers) C6: I would like to have the following search facilities: …

6 Anhänge

138

Geoportal: search functionalities

0123456789

10

C1 C2 C3 C4 C5 C6

vote

sM ultiple Choice, Total number o f responses = 13

The search results should contain … D1: the title of each result entry. D2: the description of each result title. D3: information about responsible persons (creator, publisher). D4: temporal coverage of the data. D5: spatial coverage of the data. D6: information about the quality of the data. D7: a link to full metadata information. D8: I would like to have this information: …

Geoportal: search results

0123456789

10111213

D1 D2 D3 D4 D5 D6 D7 D8

vote

s

M ultiple Choice,

Total number o f responses = 13


139

Let’s assume you have found the data you were looking for. What would you do next? E1: receive all available information about the data. E2: I’m mostly interested to receive the metadata (e.g. information about creator or quality of the data). E3: search for related data or navigate through relations between datasets. E4: combine more than one dataset and view/compare them together. E5: directly download the data and view/work with it offline. E6: view the data online on a map (if possible for that kind of data). E7: I would like to have the following operations: …

Geoportal: after a search

0123456789

1011

E1 E2 E3 E4 E5 E6 E7

vote

s

M ultiple Choice, Total number o f responses = 12

6 Anhänge

140

If you decided to view your data on a map, what functionality would you like to have? Take a look at this picture:

overview

Main map

view WMS information

list of maps and

layers(on/off)

legend

downloadqueryadditional

information

zoom& pan

add external maps (as WMS)print mapoverview

Main map

view WMS information

list of maps and

layers(on/off)

legend

downloadqueryadditional

information

zoom& pan

add external maps (as WMS)print map

F1: panning and zooming in/out of the visible map area F2: switch map layers or entire maps on/off F3: query for attributes of selected objects on the map F4: follow links from selected objects on the map to (external) information/data/documents for this object F5: watch several different maps side by side to compare them F6: view a legend that explains colors and symbols F7: view a overview map to see where the current visible map area is F8: see WMS information of shown map(s) F9: download the actual geo data of the displayed map(s) F10: upload your own data to display it alongside the maps provided by the Geoportal F11: jump directly to certain coordinates (you need to know these coordinates) F12: print the map(s) F13: put my comments and labels on the map F14: encircle or mark certain objects or regions F15: measure distances on the map F16: save current map to be able to return exactly to this state later F17: get a direct link to a saved map (e.g. to send to colleagues per e-mail) F18: define the rules how data is visualized (e.g. desired color scale, symbols…) F19: view statistical graphs or charts (e.g. histogram, scatter plot) for the chosen data F20: I would like to have the following operations: …

6.12 Workflows

141

Geoportal: map functionalities

0123456789

101112

F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13 F14 F15 F16 F17 F18 F19 F20

vote

sM ultiple Cho ice,

Total number o f responses = 13

6.12 Workflows Von ZEF-Mitarbeiter Antonio Rogmann wurden einige Workflows für das Geoportal entworfen, die man mit dem Geoportal durchführen können soll. Im Folgenden werden sie kurz vorgestellt. Mit den implementierten Funktionen des Geoportal lassen sich alle Workflows realisieren, nur das Aufziehen der Bounding Box bei der Koordinatensuche ist nicht möglich. Hier können die Koordinaten aber als Zahlenwerte eingegeben werden.

Workflow 1: Intention: Man will erst mal sehen, was überhaupt da ist. Kein konkretes Zielobjekt.

1. Portal: Thematische Vorauswahl: Hauptthema (Hydrologie), Unterthema (Wassernutzung), Unterthema (Landwirtschaftliche Wassernutzung)

2. Portal: Ergebnisliste mit zwei Kategorien (bzw. Kennzeichnung Ressourcentyp Karte/Nicht Karte): Metadaten für nicht Geodaten, Metadaten für Geodaten. Anklicken des Listenobjektes führt Suchanfrage an Meta-DB aus mit passendem Suchwort(en)

3. Portal: Ergebnisliste Metadaten. Auswahl der Datensätze. 3.1. Map Viewer: ggfs. Visualisierung im WMS (einzeln oder Basket-Funktion) und

Download der Geodaten aus MapViewer heraus 3.2. Portal: sofortiger Download der Datensätze

4. Portal: Ergebnisliste Metadaten: aus den einzelnen Datensätzen Weiterleitung zu anderen Meta-Datensätzen, die mit dem Ausgangsmetadatensatz in Verbindung stehen. Über URN/URL im Feld „Relations“.

5. Portal: Über Öffnen der permanenten Links und somit verbesserte Auswahlmöglichkeiten auf Basis der Metadatensätze (nicht für kartenbasierte Daten)

Dann weiter wie 3.

Workflow 2: Intention: man sucht thematisch (nicht räumlich) klar eingegrenzten Datensatz. Nur thematische Keywords.

1. Portal: Eingabe Keyword in das Haupteingabefeld 2. Portal: Auflistung der Ergebnisse, sonst wie Workflow 1

6 Anhänge

142

Workflow 3: Intention: man sucht einen thematisch, räumlich und durch weitere Metadatenparameter eingrenzbaren Geo-Datensatz mit möglichst hohem Informationsgehalt (hoher räumlicher Auflösung). Z.B. Straßennetz mit möglichst alle (auch kleinen) Straßen

1. Portal: Suche in Metadaten-Interface unter Eingabe der Suchkriterien 2. Portal: Sammeln aller Karten und Layer, die für die gefragte Region gefunden wurden und

Straßennetze beinhalten im Map Basket 3. Map Viewer: Anzeige der Karten im MapViewer und Vergleich der Straßennetze 4. Map Viewer: Auswahl und Download des Datensatzes, welches das Straßennetz in der

höchsten Auflösung bietet

Workflow 4: Intention: ein Sozialwissenschaftler ist interessiert an Studien in ihrem räumlichen Umfeld (bzw. den Survey-Sites). Thematische Karte als Ausgangspunkt der Datensuche

1. Portal: Aus Liste unterhalb Oberthemas „Sozio-Ökonomie“ lässt sich Karte aufrufen: „Untersuchungsgebiete und Studien“ (fester Link auf Karte)

2. Map Viewer: Karte mit Geoobjekten (Region, Dorf) lassen sich aufrufen. Sachdatentabelle enthält Link-Liste mit permanenten Links zu Metadaten, die 2.1. entweder strukturierte Datensätze beschreiben oder Dokumente (Studien) 2.2. oder Link zur GLOWA Literaturdatenbank ???

3. Portal: Metadatensatz sichten. Ggfs. Link zu Literaturdatenbank aufrufen 4. Portal: Download des Datensatzes

Workflow 5: Intention: koordinatenbasierte Suche mit grafischer Unterstützung. Interessiert ist der Nutzer nur an der Region und allen sie betreffenden Geo-Datensätzen, ohne thematische Konkretisierung

1. Portal: Aufziehen einer Bounding Box auf einer Karte 2. Portal: Ergebnisliste aus Meta-DB: alle Geodaten/Karten innerhalb der Bounding Box 3. Portal: Sammeln der Ergebnisse in Map Basket oder Einzelaufruf im MapViewer 4. Map Viewer: Selektion und Download

143

7 Danksagungen Zunächst möchte ich meiner Familie, insbesondere meinen Eltern, herzlich danken, die mir mein Studium ermöglicht und mich dabei immer unterstützt haben.

Sehr herzlich danke ich Herrn Prof. Dr. Armin B. Cremers und Herrn Dr. Serge Shumilov für die Betreuung meiner Arbeit und die damit verbundenen Möglichkeiten und Chancen, die sich damit für mich eröffnet haben. Sehr herzlich danke ich zudem Herrn Antonio Rogmann für die Unterstützung meiner Arbeit. Dank gebührt zudem Herrn Ivan Denisovich und vielen anderen Mitarbeitern der Abteilung III.

Außerdem möchte ich den anderen Mitarbeitern des GLOWA Volta Projekts für ihre Unterstützung meiner Arbeit danken. Insbesondere möchte ich meinen Dank an Herrn Prof. Paul Vlek, Herrn Dr. Jens Liebe, Herrn Dr. Charles Rogers, Frau Laura Zug, Herrn Peter Wittkötter und Herrn Stephan Hofmann richten.

Abschließend bedanke ich mich noch bei allen Freunden und Bekannten, die ihr Interesse an meiner Arbeit kundgetan haben. Hier möchte ich besonders Michael Wingender und meinem Bruder Matthias für ihre Unterstützung danken.

145

8 Eidesstattliche Erklärung Hiermit versichere ich, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, habe ich als solche gekennzeichnet.

Weiter erkläre ich, die Diplomarbeit in gleicher oder ähnlicher Form keiner anderen Prüfungsbehörde vorgelegt zu haben.

Bonn, den

____________________________________

(Joscha Laubach)

aufbau eines geoportals als komponentenbasiertes ... · implementierte system beschrieben und alle...

Documents