Rheinische Friedrich - Wilhelms - Universität Bonn

Transcrição

Rheinische Friedrich-Wilhelms-Universität Bonn
Landwirtschaftliche Fakultät
Institut für Kartographie und Geoinformation
Diplomarbeit
Entwicklung eines kooperativen Web-Clients
für interoperable Internetkarten
vorgelegt von
Michael Homoet
im Dezember 2003
Betreuer:
Prof. Dr. Lutz Plümer
Dr. Thomas H. Kolbe
Danksagung
Dank gilt Herrn Prof. Dr. Lutz Plümer und Herrn Dr. Thomas H. Kolbe für die Ermöglichung und der intensiven Betreuung dieser Diplomarbeit, sowie allen weiteren Mitarbeitern des Lehrstuhls, die mir stets eine Hilfe waren.
Weiter bedanke ich mich bei Ariane Middel und Iris und Jochen Maubach, die sich als
Lektoren für meine Arbeit zur Verfügung stellten. Dank gilt auch insbesondere Marcus
Pant für seine Hilfestellungen in der Java-Programmierung.
Einen ganz besonderen Dank möchte ich meiner Freundin Diana widmen, die es verstand
mich während meines Studiums immer wieder aufzubauen und zu bestärken. Ich danke
meinen Eltern, die mir das Studium erst ermöglicht und mich in jeder Hinsicht unterstützt haben. Des Weiteren möchte ich einen herzlichen Dank meinem Onkel Rudolf Pölling aussprechen, der mich zu diesem Studium ermutigt hat.
Schließlich möchte ich noch all denen danken, die zum Erfolg dieser Arbeit und meinem
Studium beigetragen haben.
Inhaltsverzeichnis
I
INHALTSVERZEICHNIS
1
Einleitung und Motivation ................................................................1
2
Web-Maps – Karten aus dem Internet.............................................3
2.1
2.2
2.3
3
Grundlagen ............................................................................................... 4
2.1.1
Statische Karten............................................................................ 5
2.1.2
Dynamische Karten ...................................................................... 7
2.1.3
Web-GIS........................................................................................ 7
2.1.4
Web-Technologien zur Umsetzung .............................................. 8
2.1.5
Probleme der Web-Maps............................................................ 11
Interoperabilität von Internetkarten (Web-Maps) .............................. 12
2.2.1
Grundlagen und Definition ........................................................ 12
2.2.2
Das Open GIS Konsortium ........................................................ 15
2.2.3
Web Map Service ........................................................................ 19
Web-Mapping-Clients ............................................................................ 24
2.3.1
ESRI ArcIMS .............................................................................. 24
2.3.2
Ifgi Mapping Client .................................................................... 26
2.3.3
Intergraph WMS Viewer............................................................ 28
2.3.4
GeoServer der LDS NRW .......................................................... 30
2.3.5
Vergleich der vorgestellten Web-Clients................................... 31
Kooperative GIS ..............................................................................33
3.1
Kooperative Konzepte............................................................................ 33
3.1.1
Grundlagen ................................................................................. 34
Inhaltsverzeichnis
II
3.1.2
Community Planning.................................................................. 35
3.1.3
Argumentationskarten – Argumentation Maps........................ 37
3.1.4
GroupARC .................................................................................. 39
3.1.5
Cooperative Web Maps .............................................................. 41
3.2
4
Kooperative interoperable Internetkarten ....................................46
4.1
Zielsetzung .............................................................................................. 46
4.2
Konzept ................................................................................................... 48
4.3
5
6
Ruhrtal à la Karte .................................................................................. 43
4.2.1
Mapping im Web-Browser ......................................................... 49
4.2.2
Persistente Speicherung in der URL ......................................... 52
4.2.3
Gestaltung und Benutzerführung .............................................. 53
4.2.4
Rechtliche Aspekte ..................................................................... 54
4.2.5
Probleme durch Web-Techniken ............................................... 56
Umsetzung – Technische Realisierung .................................................. 57
4.3.1
Implementierung ........................................................................ 57
4.3.2
Besonderheiten............................................................................ 67
4.3.3
Offene Fragestellungen .............................................................. 72
Anwendungsszenarien .....................................................................73
5.1
Allgemeines ............................................................................................. 73
5.2
Bauleitplanung der Zukunft? ................................................................ 74
5.3
Von Dir zu mir........................................................................................ 75
5.4
Highlights einer Stadt ............................................................................ 77
Fazit und Ausblick...........................................................................79
Inhaltsverzeichnis
III
Literaturverzeichnis.................................................................................82
Anhang ......................................................................................................85
Abbildungsverzeichnis
IV
ABBILDUNGSVERZEICHNIS
Abbildung 2-1: Klassifikation von Web - Maps (Quelle: Kraak 2001) ............................ 4
Abbildung 2-2: Kartographisches Zoomen...................................................................... 6
Abbildung 2-3: Screenshot ArcExplorer (Quelle: ESRI)................................................10
Abbildung 2-4: Qualitätsstufen von Internetkarten (Quelle: Averdung 2003) ................11
Abbildung 2-5: Traditionelle GIS (Quelle: Doyle 2003) ................................................13
Abbildung 2-6: Interoperable GIS (Quelle: Doyle 2003) ...............................................13
Abbildung 2-7: Interoperables Netzwerk (Quelle: Stobl 1999) .......................................14
Abbildung 2-8: Aufbau der OGC (Quelle: OGC) ............................................................15
Abbildung 2-9: OGC Web Services Architektur (Quelle: OGC) .....................................17
Abbildung 2-10: Portrayal Modell (Quelle: Cuthbert, Doyle 1998) ................................18
Abbildung 2-11: Thin Client (Quelle: Cuthbert, Doyle 1998) ........................................19
Abbildung 2-12: Thick Client (Quelle: Cuthbert, Doyle 1998) ......................................19
Abbildung 2-13: Kombination zweier WMS ...................................................................23
Abbildung 2-14: Festlegung einer Bounding Box (Quelle: de La Beaujardière 2002) ....24
Abbildung 2-15: Screenshot ArcIMS HTML Viewer......................................................25
Abbildung 2-16: Screenshot ArcIMS Java Viewer..........................................................26
Abbildung 2-17: Screenshot Ifgi Web Map Client ..........................................................27
Abbildung 2-18: Screenshot Intergraph OGC WMS Viewer...........................................29
Abbildung 2-19: Screenshot LDS GeoServer ..................................................................30
Abbildung 3-1: Web-basierte GIS Karte (Quelle: Al-Kodmany 2001)............................36
Abbildung 3-2: Argumentationskarte (Quelle: Rinner 2002) ..........................................37
Abbildung 3-3: GroupARC (Quelle: Churcher and Churcher 1996) ...............................40
Abbildung 3-4: Konzept von Cooperative Web Maps (Quelle: Kolbe et al. 2002)..........42
Abbildung 3-5: Informationsaustausch in kooperativen WebGIS (Quelle: Kolbe et al.
20002) .....................................................................................................................42
Abbildung 3-6: Visualisierungsablauf (Quelle: Kolbe et al. 2002)..................................43
Abbildung 3-7: Screenshot Ruhrtal à la Karte .................................................................44
Abbildung 4-1: Konzeptentwurf Cooperative Map Client ...............................................50
Abbildungsverzeichnis
V
Abbildung 4-2: Servergestützte Konzeptalternative ........................................................51
Abbildung 4-3: Grundstruktur des Clients.......................................................................54
Abbildung 4-4: Fensteraufteilung für Kommentareingaben ............................................54
Abbildung 4-5: Darstellung des Cross-Domain-Scriptings..............................................56
Abbildung 4-6: Web-Server des Prototypens ..................................................................58
Abbildung 4-7: Aufbau der URL des Clients ..................................................................59
Abbildung 4-8: Screenshot des Clients............................................................................60
Abbildung 4-9: Übersicht über die Buttonbar..................................................................60
Abbildung 4-10: Speicherstruktur im Web-Map-Client ..................................................62
Abbildung 4-11: Ablaufskizze.........................................................................................64
Abbildung 4-12: Sequenzdiagramm des Ladevorganges .................................................65
Abbildung 4-13: Darstellung der Schnittmenge dreier WMS Server...............................67
Abbildung 4-14: URL / Link Verbreitung .......................................................................68
Abbildung 4-15: Import von HTML Bildern ...................................................................69
Abbildung 4-16: Auflösungsunterschiede .......................................................................70
Abbildung 4-17: Importfunktion des Clients ...................................................................71
Abbildung 4-18: Problem der Schriftplatzierung.............................................................72
Abbildung 5-1: Mögliche Beteiligungsform....................................................................75
Abbildung 5-2: Wegbeschreibung von der Autobahn 565 zum IKG ...............................76
Abbildung 5-3: Sehenswürdigkeiten von Bonn ...............................................................77
Tabellenverzeichnis
VI
TABELLENVERZEICHNIS
Tabelle 2-1: Gegenüberstellung von Papier- und Bildschirmkarte (Quelle: Averdung
2003) ........................................................................................................................ 5
Tabelle 2-2: Realisierung von Web-GIS-Techniken (Dickmann 2001) ............................ 9
Tabelle 2-3: OGC Web Service Anfrage (Quelle: De La Beaujardière 2002) .................20
Tabelle 2-4: Parameter des GetCapabilities Operators (Quelle: De La Beaujardière 2002)
.................................................................................................................................21
Tabelle 2-5: GetMap Parameter (Quelle: De La Beaujardière 2002)...............................22
Tabelle 2-6: Vergleich der vorgestellten Clients .............................................................31
1 Einleitung und Motivation
Kapitel 1
Einleitung und Motivation
Eine Karte bietet für viele Menschen eine Orientierung. Sie kann die Antwort auf die
Frage: „Wo bin ich?“ sein oder einen Überblick über Planungsvorhaben geben. Während
klassische Karten meist auf materiellen Trägern zu finden sind, werden heutige kartographische Darstellungen oft im Internet oder auf dem Bildschirm eines PCs präsentiert.
Gerade die Veröffentlichung einer Karte im WWW bietet einer breiten Masse der Bevölkerung den Zugang zu spezifischem Wissen. Das Anbieten einer Karte im Internet kann
unter den Begriff Web Mapping gefasst werden.
Wie viele andere Dinge auch, so unterliegt gegenwärtig auch das Web Mapping einem
erheblichen Wandel. Während sich Internetkarten bislang auf die reine Darstellung des
Sachverhaltes konzentrierten, werden dem Benutzer heute immer mehr Interaktionsmöglichkeiten gegeben. Darüber hinaus sind Kartenanbieter derzeit bemüht, ihre Kartendienste konform zur Web Map Service Spezifikation des Open GIS Konsortiums
anzubieten. Durch die Bereitstellung von Karten in einem einheitlichen Standard ist es
möglich, Karteninhalte von verschieden Servern zu kombinieren. Hierdurch kann ein
Informationsgewinn der Karte erreicht werden: Nutzer können entsprechend einer Problem- oder Fragestellung verschiedene Inhalte von unterschiedlichen Servern zusammenstellen. Es existiert derzeit kaum eine Internetlösung, die dies ermöglicht.
Kartennutzer haben oft das Bedürfnis, individuelle Ergänzungen zu einer Karte hinzuzufügen. Dieser Wunsch existiert speziell für Karten, die für den Freizeitbedarf angefertigt
werden. Aber auch auf kommerzieller Ebene werden Planungsvorhaben aus einer Diskussion heraus mit Kommentaren zur Änderung versehen. Oft sind dies kurze Anmerkungen in der Form von: „Hier treffen wir uns um 18 Uhr!“ oder Hinweise, die auf
Unstimmigkeiten in der Planung hindeuten.
Obwohl die Arbeit der Zusammenstellung von Karteninformationen und der individuellen Ergänzung einer Karte sehr aufwändig und zeitintensiv ist, gibt es gegenwärtig keine
frei zugängliche Internetanwendung, die diese Sachverhalte persistent verwalten kann.
Die Informationen des Nutzers gehen oft mit dem Schließen des Web-Browser oder mit
dem Wechseln der Internetseite verloren.
In dieser Arbeit wird ein Konzept vorgestellt, das die obigen Problemstellungen löst. Es
wird gezeigt, wie zusammengestellte Informationen erneut abgerufen werden können.
Dadurch kann der Nutzer eine Karte auch zu späteren Zeitpunkten erneut bearbeiten.
1
Kapitel 1: Einleitung und Motivation
2
Die vorliegende Arbeit gliedert sich in sechs Kapitel. Das folgende Kapitel beschreibt die
Grundlagen der Web Mapping Thematik. Es wird ein Konzept des Open GIS Konsortiums vorgestellt, das Interoperabilität zwischen Systemen herstellt. Weiter werden verschiedene Web Mapping Clients präsentiert, um einen Überblick über momentane
Techniken zu geben. Kapitel 3 befasst sich mit kooperativen GIS Systemen. Dabei werden verschiedene Arten der kooperative Arbeit vorgestellt. Der Fokus von Kapitel 4 liegt
auf der Fassung und der Umsetzung eines Konzeptes für einen kooperativen interoperablen Web-Client. Es wird zunächst ein Lösungsansatz für die Problemstellung dieser
Arbeit formuliert. Anschließend erfolgt die Beschreibung der praktischen Umsetzung. In
Kapitel 5 werden verschiedene Anwendungsszenarien für den entwickelten Web-Client
aufgezeigt. Der Leser soll einen Überblick über mögliche Einsatzfelder bekommen.
Schließlich endet diese Arbeitet im Kapitel 6 mit einem Fazit. Zusätzlich wird ein Ausblick auf Zukunftsvariationen des Clients gegeben.
2 Web-Maps – Karten aus dem Internet
Kapitel 2
Web-Maps – Karten aus dem Internet
Durch Karten werden räumliche Sachverhalte schnell und effektiv übermittelt. Karten
dienen insbesondere zur Orientierung, Planung und Beschreibung von Orten. Durch das
Internet werden Karten im Netz verfügbar, in diesem Sinne spricht man von einer WebMap. Eine Web-Map unterscheidet sich von einer Papierkarte durch das Anzeigemedium: Web-Maps werden durch einen Internet-Browser auf dem Bildschirm eines Computers dargestellt. In den letzten Jahren stieg die Zahl der online verfügbaren Karten enorm
an (Dickmann 2001).
Das Medium Internet unterstützt und erweitert die Funktionalitäten von Karten erheblich.
Es ist zu erkennen, dass der Anspruch, der an Web-Karten gestellt wird, stets wächst.
Benutzer streben nach mehr Möglichkeiten, eine Karte nach ihren Wünschen zu gestalten
und zu nutzen. Sobald Analysewerkzeuge die Funktionalität unterstützen, wird auch vom
Web-GIS gesprochen.
Das Internet ermöglicht eine hohe Aktualität und die schnelle Verbreitung von Daten. Es
ist auf eine einfache Weise möglich, eine Vielzahl von Personen zu erreichen. Durch eine
entsprechende Implementierung werden dem Betrachter interaktive Funktionalitäten an
die Hand gegeben. Multimediale Eigenschaften, wie beispielsweise Sounds, PopUps,
Bewegungen oder Text, fördern dabei die Aufnahme- und Interpretationsfähigkeit des
Betrachters. Bei der Anreicherung einer Karte mit Funktionen gilt es aber zu beachten,
dass die Ladezeiten kurz bleiben. Nur hierdurch kann gewährleistet werden, dass der
Kartennutzer nicht auf eine alternativ verfügbare Karte zurückgreift und somit zu einer
anderen Internetseite abwandert (Kraak 2001).
Dadurch, dass das Internet einfach und ortsunabhängig arbeitet, ergeben sich Vorteile für
die Publikation einer Karte im Internet. Verschiedenste Bereiche profitieren aus dieser
Darstellungsform: Öffentlichkeitsarbeit, Bürgerservice und Dienstleistung aber auch alle
anderen Arbeitsbereiche, in denen in Teamwork gefordert ist (Averdung 2003).
In diesem Kapitel sollen die Grundlagen von Internetkarten beschrieben werden. Anschließend soll auf das Kriterium der Interoperabilität eingegangen werden. Hierzu wird
eine Spezifikation zu Web-Karten vom Open GIS Konsortium (OGC) vorgestellt. Die
OGC ist eine Vereinigung, die an interoperablen Schnittstellen im Internet arbeitet. Ziel
3
Kapitel 2: Web-Maps – Karten aus dem Internet
4
dieser Schnittstellen ist es, sich von proprietären1 Systemen zu lösen und den Austausch
und die Kommunikation von Daten zu erleichtern.
Abschließend werden Web-Mapping Clients vorgestellt und Kriterien erarbeitet, um die
Clients zu vergleichen. Dabei sollen Vor- und Nachteile der einzelnen Anwendungen
herausgestellt werden.
2.1 Grundlagen
Karten können verschiedene Merkmale besitzen. Jeder Mensch betrachtet eine Karte auf
seine individuelle Weise. Dies ist auch der Grund, warum sich in der Literatur immer
wieder neue Einordnungskriterien und Definitionen für Karten finden lassen.
Um eine Karte einzuordnen, wird oft nach den Merkmalen einer Karte unterschieden. Es
sind die Eigenschaften wie das Vektor- oder Rasterformat, die eine Karte auszeichnen.
Allerdings gibt es auch Nutzungsmöglichkeiten, die Karten voneinander unterscheiden.
Heutige Web-Maps zeichnen sich oft auch durch ihre Individualität aus. Während die
Papierkarten meistens unabhängig für sich alleine entworfen werden, kann der Internetnutzer unter Umständen seine Karte selbst gestalten. Hierzu gehört nicht nur die Wahl
des Kartenausschnittes, sondern häufig auch die Wahl der Inhalte (Dickmann 2001).
Kraak (2001) gliedert die Web-Maps in statische und dynamische Karten. Diese Kategorien werden wiederum je in eine „view only“ und „interactive“ Sparte unterteilt (siehe
Abbildung 2-1).
Abbildung 2-1: Klassifikation von Web - Maps (Quelle: Kraak 2001)
1
Proprietär bedeutet, dass die Übernahme von Daten in andere Projekte fast ausgeschlossen ist. Der Nutzer kennt keine Quellcodes.
5
2.1.1 Statische Karten
Statische Karten sind die wohl am häufigsten vertretene Kartenart im Internet (Kraak
2001). Es handelt sich um vorgefertigte Karten, die mit den üblichen Internet-Browsern
angezeigt werden können. Die Karten sind dabei meistens als Bild in die HTML-Seite
eingebunden.
2.1.1.1 View-Only Karten
Wie der Name bereits beinhaltet, handelt es sich um Kartenbilder, die nur zur Anschauung im Netz sind. Die Kartenbilder liegen zumeist als GIF- oder JPEG-Bilddateien auf
dem Web-Server (Asche 1999). Nach Abruf der Karte aus dem Internet kann der Benutzer keine Modifikationen vornehmen. Interaktionen, wodurch neue Elemente in eine Karte gelangen, sind nach Dickmann nicht vorgesehen, während das Scrolling und Zooming
möglich ist.
Die view-only Karten sind häufig nicht speziell für das Internet erstellt worden. Es handelt sich meistens um gescannte Papierkarten, die als Bitmap gespeichert und schließlich
in eine HTML-Seite eingebunden werden (Dickmann 2001).
Im Internet findet man diese Kartenform häufig, wenn historische Karten dargestellt werden. Durch das Internet wird somit einer breiten Masse Zugang zu diesem speziellen
Wissen gewährt. Dadurch braucht der Benutzer nicht mehr in Stadtarchiven suchen. Weitere Beispiele für diese Kartenform sind oft auch dann zu finden, wenn Unternehmen
eine Anfahrtsskizze oder Lagebeschreibung ihrer Firma auf ihrer Web-Seite präsentieren.
Probleme ergeben sich gelegentlich dadurch, dass die gescannten Karten nicht für das
Medium Internet gefertigt wurden (s.o.). Die Karten liegen häufig nur im Rasterformat
vor, und die Informationsaufbereitung in solchen Karten eignet sich nicht für eine Darstellung auf dem Monitor (vergleiche Tabelle 2-1). Die Auflösung auf dem Bildschirm
ist im Verhältnis zur Papierkarte sehr gering.
Tabelle 2-1: Gegenüberstellung von Papier- und Bildschirmkarte (Quelle: Averdung 2003)
Papier
Bildschirm
Format
A0 oder größer (1189x841 mm)
17“ (300x225 mm)
Auflösung
Über 2000 dpi2
72 dpi
Farbraum
CYMK3
RGB4
2
Dots per inch (Punkte pro Zoll - 1 Zoll = 2,54cm). Auflösung von Druckern und Monitoren.
3
CYMK steht für Cyan, Yellow, Magenta und Key.
6
Papier
Farbtiefe
Beliebig
Leseentfernung Ca. 50 cm
Bildschirm
Einzelne Farben (16bit, 24bit)
Ca. 30 cm
2.1.1.2 Interaktive Karten
Interaktive Karten werden auch Clickable-Maps genannt. Diese sind durch verschiedenste multimediale und interaktive Funktionalitäten angereichert.
Neben der Kartendarstellung sind solche Karten oft durch anklickbare Flächen gestaltet.
Über diese kann der Nutzer beispielsweise weitere Texte, Fotos, Graphiken oder Videos
aufrufen (Dickmann 2001).
Schmidt und Rinner (2001) sehen die Form der interaktiven Karte als Dialog zwischen
der Karte und dem Benutzer. Hierdurch wird eine verbesserte Wahrnehmbarkeit und Erschließung der Karte erreicht.
Es ist denkbar, eine Art des kartographischen Zoomens auf diese Weise der Kartengestaltung umzusetzen. Unter dem kartographischen Zoomen versteht man, dass der Karteninhalt mit zunehmender Zoomstufe zunimmt (siehe Abbildung 2-2).
Besonders geeignet sind diese Karten, um Layer-Strukturen5 zu realisieren. So kann der
Nutzer beispielsweise über eine Legende bestimmte Inhalte zu einer Karte hinzufügen
oder entfernen.
Abbildung 2-2: Kartographisches Zoomen
4
5
RGB ist eine Abkürzung für die Farben Rot, Grün und Blau.
Layer bieten die Möglichkeit eine Karte aus verschiedenen Kartenebenen zusammenzustellen. Ein Layer
repräsentiert die Information aus einer Schicht.
7
Web-Maps, die dieser Form entsprechen, werden meistens nur über HTML und JavaScript umgesetzt. Für diese Lösungen werden keine Plug-Ins gebraucht. Dadurch ergibt
sich der Vorteil, dass solche Karten auf fast allen Internetbrowsern und Systemen zu betrachten sind (Dickmann 2001).
2.1.2 Dynamische Karten
Wie auch die statischen Karten gliedert Kraak die dynamischen Karten in „view-only“
und „interaktiv“. Da der Fokus dieser Arbeit allerdings auf den statischen Karten liegt,
wird nur kurz auf diese Kartenform eingegangen.
Dynamische Karten beinhalten immer eine Art von Veränderung. Sie werden beispielsweise benutzt, um ein Veränderung der Zeit oder des Ortes darzustellen.
Die view-only Karten dieser Kartenform existieren meistens in Form eines animierten
GIF6 oder einer Filmsequenz (Kraak 2001).
Ein animiertes GIF ist eine Anreihung von Bildern, die in einzelnen Frames gespeichert
werden. In einem Internet-Browser werden diese Frames dann fortlaufend angezeigt, so
dass ein Effekt der Bewegung auftritt. Je nach Anzahl der Bilder ist die Bewegung bzw.
die Bildveränderung mehr oder weniger flüssig.
Mehr Interaktivität ist in den Filmsequenzen zu finden. Diese Form der Kartendarstellung unterscheidet sich nicht von einer Desktopanwendung. Die Filme werden aus dem
Internet geladen oder sind direkt in die Web-Seite eingebaut. Nach dem Download können diese dann in herkömmlichen Windowstools wie Windows Media Player, Apple
Quicktime Player oder Real One Player abgespielt werden. Typische Beispiele aus dem
Internet sind 3D-Gelände-Überflüge.
Die interaktiven Karten werden in Umsetzungen wie VRML7-Modellen oder Panoramen
präsentiert. Panoramen ermöglichen eine 360° Rundumblick einzelner Positionen. Durch
anklickbare Flächen ist es möglich zu weiteren Informationen gelangen. Zu näheren Information wird an dieser Stelle auf entsprechende Fachliteratur verwiesen (wie zum Beispiel Kraak 2001).
2.1.3 Web-GIS
Web-GIS Karten zeichnen sich durch enorme Interaktion aus. Der Kartennutzer hat vielfältige Möglichkeiten die Karte seinen Wünschen anzupassen. Dickmann (2001) listet
einige Formen der Interaktion auf (modifizierte Liste):
6
GIF = Graphics Interchange Format – Grafikformat des Internets
7
VRML = Virtual Reality Modeling Language
8
-
Einblendung einer Legende
-
Abrufbarkeit von Zusatzinformationen zu einzelnen Kartenobjekten, beispielsweise in Form von Links zu anderen Medien wie Bildern oder Videos
-
Gestaltung des Kartenraumausschnittes (Zooming, Panning, Scrolling)
-
Veränderung von Symbolen und Farben in Karten
-
Selektion von Geodaten
-
Entfernungsmessung in Karten
-
Einfügen eigener Objekte in die Karte
Spricht man von einem Web-GIS, greift der Nutzer nicht mehr nur auf die Karte zu, sondern arbeitet mit den Geodaten. Er hat somit einen direkten Zugriff auf den Server. Heutzutage läuft dieser Prozess bereits in Echtzeit ab.
Einen Höhepunkt der Web-GIS Funktionalitäten bildet das Vernetzen mehrerer Geodatenbanken. Dies bedeutet, dass die Kombinationsfähigkeit von mehreren Datensätzen
geschaffen wird (Dickmann 2000). Hierdurch ergeben sich eine Reihen von Vorteilen:
Man denke beispielsweise an ein Szenario, in dem der Benutzer immer die aktuelle
Stadtkarte vom Landesvermessungsamt abrufen kann und zu dieser Datengrundlage noch
aktuelle Points-Of-Interest aus dem Internet zur Karte hinzufügt.
2.1.4 Web-Technologien zur Umsetzung
Die Umsetzungen von Web-Maps sind sehr verschieden. Es gibt die mannigfaltigsten
Möglichkeiten, eine Karte im Internet zu visualisieren und anzubieten.
Bevor man sich damit beschäftigt, wie die Karte publiziert werden soll, sollte genau geklärt sein, was man darstellen will und welche Funktionalitäten zur Verfügung stehen
sollen. Ist die Zielsetzung klar definiert, kann man mit der Umsetzung beginnen. Es stehen verschiedene Zugriffsstrukturen zur Verfügung. Die einzelnen Umsetzungsvarianten
bergen immer eine Reihe von Vor- und Nachteilen, die gegeneinander abzuwägen sind.
Ferner sollte schon im Vorfeld geklärt werden, welche Belastbarkeit ein Server hat. Konkret stellt sich zum Beispiel die Frage, wie viele Anfragen der Server gleichzeitig bearbeiten kann. Nur so ist sichergestellt, dass eine zuverlässige Kartenpräsentation
gewährleistet ist.
Während bei den view-only Karten die Umsetzung noch recht einfach ist, stehen eine
Vielzahl von Umsetzungsmöglichkeiten offen, sobald interaktive Karten erstellt werden.
Dickmann (2001, S. 59-61) hat eine Tabelle erstellt, die verschiedenen Möglichkeiten
auflistet sowie die Vor- und Nachteile kurz anreißt.
9
Tabelle 2-2: Realisierung von Web-GIS-Techniken (Dickmann 2001)
Technische Realisierung
Standard-HTML
HTML / JavaScript
Java-Applets
Plug-in-Technologie
ActiveX
Vor- und Nachteile
-
Viewer
-
Application Server
-
Providing
Browser-unabhängig
mit Geo-Client
-
Geringe Funktionalität
Plattformunabhängig
Ständig neuer Verbindungsaufbau notwendig
Hohe Funktionalität
u.U. lange Ladezeiten
Rechenleistung vom Client-Rechner abhängig
z. T. instabil
Download- und Installationsprozedur notwendig
Nur zusammen mit einem Browser abhängig
Vergleichbar mit Java
Entwickelt für Microsoft-Produkt-Umgebung
Verbleibt nach dem Download auf dem ClientRechner
Sicherheitsrisiken aufgrund von Zugriffsmöglichkeit
auf die Festplatte
Mit unterschiedlicher Funktionalität
Eigenständige Programme, die vom Browser aus gestartet werden können, aber auch getrennt davon lauffähig sind (z.B. ArcExplorer, RealPlayer,…)
Höchstmaß an Funktionalität
v.a. für kommerzielle Nutzung geeignet
wenig verbreitet
Eigenständiges GIS ohne Browseranbindung
Vollständige Funktionalität eines GIS
Nur Einlesen von binärspezifischen Rohdaten bzw.
Austauschformaten möglich
Die Leistungsfähigkeit des Web-Servers ist von enormer Wichtigkeit. Antwortet ein Server nicht schnell genug, ist es möglich, dass der Nutzer zu einer anderen Web-Seite
wechselt. Durch eine entsprechende Implementierung kann die Arbeitsleistung vom Server zum Client verlagert werden. Für die Darstellung und Visualisierung der Karte ist
dann ein Programm auf dem Client zuständig. In solchen Fällen spricht man vom „thick
10
client“. Ein „thick Client“ wie beispielsweise der ArcExplorer8 von ESRI (siehe
Abbildung 2-3) ist ein eigenständiges Programm, das ein hohes Maß an Funktionalität
verspricht. In einem solchen Programm werden die Geodaten von einem Server aus dem
Internet geladen und können dann im Programm selbst verarbeitet werden. Eine derartige
Anwendung bietet sehr viele Kartenfunktionen (Zoom, Pan9, Messen von Distanzen,
usw.). Durch diese Verlagerung des Kompetenzbereiches ergibt sich ein Vorteil, wenn
die Serverkapazitäten gering sind. Nach dem Abrufen der Daten wird die Verbindung
zum Server nicht mehr benötigt. Der Client kann für sich alleine arbeiten. Ein Nachteil
ist allerdings, dass eine clientseitige Installation notwendig ist. Dies kann vor allem in
Firmen und Behördennetzwerken zu Problemen führen.
Abbildung 2-3: Screenshot ArcExplorer (Quelle: ESRI10)
Das Gegenstück zum „thick client“ ist der „thin client“. Dieser ist einfacher zu implementieren und hat weniger Systemvorausetzungen auf der Clientseite. Die Geodaten
werden bei dieser Umsetzungsvariante auf dem Server visualisiert, und der Client bekommt das fertige Bild über das Internet zugesandt. Die Funktionalität und Flexibilität
sind bei diesem Anzeigetyp sehr begrenzt (vergleiche Kapitel 2.2.2.2, Seite 17).
8
Software ist frei verfügbar unter http://www.esri.com/software/arcexplorer/ (Letzter Zugriff am
16.12.2003).
9
Eine Pan Funktion erlaubt den Kartenausschnitt individuell zu verschieben.
10
http://www.esri.com/software/arcexplorer/graphics/overview2.jpg (Letzter Zugriff am 16.12.2003).
11
2.1.5 Probleme der Web-Maps
Es ist ersichtlich, dass das Internet die technischen Möglichkeiten von Karten erheblich
erweitert und vereinfacht. Jedoch ist es nicht von der Hand zuweisen, dass es auch Probleme mit der richtigen Darstellung geben kann.
Bereits in Kapitel 2.1.1.1 (vergleiche Tabelle 2-1) wurde auf die niedrige Auflösung des
Bildschirms im Gegensatz zum Papier hingewiesen. Die direkte Umsetzung einer Papierkarte zur Bildschirmkarte in Form eines Scans kann die Qualität der Karte erheblich verschlechtern. Es können zum Beispiel unerwünschten „Treppeneffekten“ auftreten
(Dickmann 2001, Averdung 2002). Dadurch kann die Lesbarkeit der Karte unter Umständen in Frage gestellt werden (siehe Abbildung 2-4). Der Einsatz von Glättungsfunktionen
(z.B. Anti-Aliasing) ist in solchen Fällen dringend ratsam.
Abbildung 2-4: Qualitätsstufen von Internetkarten (Quelle: Averdung 2003)
Ein weiterer Problempunkt im Bezug auf Internetkarten wird durch den Drang, immer
mehr Medien in eine Karte einzugliedern, hervorgerufen. Es kann zu einer „audiovisuellen Überfrachtung“ (Dickmann 2001) kommen. Es ist notwendig, ein Verständnis
für ein Maß der Integration von Daten zu entwickeln.
Auch Gartner (1998) kritisiert die fehlende Adaption des Verständnisses für den Einsatz
neuer Medien in Internetkarten. Dabei geht es um die Verwendung eines passenden Maßes für den Einsatz neuer Medien in Karten. Nur so kann gewährleistet werden, dass der
Kartenbetrachter nicht überfordert wird.
12
2.2 Interoperabilität von Internetkarten (Web-Maps)
Viele Menschen können mit dem Begriff Interoperabilität nicht viel verbinden, obwohl
sie täglich damit in Berührung kommen. In den weiteren Unterkapiteln wird ein Überblick über Interoperabilität in Internetkarten gegeben.
2.2.1 Grundlagen und Definition
Die Firma Siemens stellt auf Ihrer Web-Seite eine Definition bereit:
Interoperabilität
“Die Fähigkeit eines Gerätes, bei vergleichbarer Systemumgebung in einem Netz mit anderen Geräten desselben Standards sinnvoll kommunizieren zu können. Dabei sollte es
keine Rolle spielen, dass die Geräte von verschiedenen Herstellern stammen. Der Begriff
repräsentiert das Ziel des Internetworking besonders dadurch, dass eine abstrakte, hardwareunabhängige Netzwerkumgebung geschaffen wird. Diese ermöglicht es, Computer
über die Netzwerkschicht miteinander zu verbinden, so dass die Zusammenarbeit möglich
ist, ohne dass die Beteiligten wissen, welche Technik den benutzten Geräten zugrunde
liegt.“ 11
Es wird deutlich, dass ohne Interoperabilität der Umgang mit Technik sehr erschwert
würde. Man denke beispielsweise an einen CD-Player, der nur CDs des eigenen Herstellers abspielt oder an ein Auto, das nur mit Reifen des Autoherstellers fahren darf und
kann (Guerrero 2002).
Die Schaffung von Interoperabilität und Standards von Geodaten wird von verschiedenen
Organisationen vorangetrieben. Allerdings sieht der momentane Status so aus, dass die
Geodaten meistens aus unterschiedlichen Quellen stammen. Die gemeinsame Nutzung
verschiedener Quellen wird häufig durch die Verwaltung in GI-Systemen unterschiedlicher Hersteller erschwert. Jedes System speichert seine Daten in seinem eigenen proprietären Dateiformat. Ein Austausch der Daten zwischen den Systemen wird mühsam
(Teege, Seuß 2003).
Die Abbildung 2-5 zeigt, wie herkömmliche Systeme zusammenarbeiten. Die System
sind in sich heterogen. Um einen Datenaustausch von Organisation A zu Organisation B
durchzuführen, müssen die Daten in ein Austauschformat konvertiert werden, sobald die
Software sich unterscheidet. Hierdurch können Datenzusammenhänge verloren gehen
und Ungenauigkeiten entstehen. Anschließend können die Daten im zweiten System importiert werden.
In Abbildung 2-6 ist zu erkennen, dass die Systeme einen gegenseitigen direkten Zugriff
haben. Die Daten müssen nicht bearbeitet werden, um sie in das andere System zu integ-
11
http://w3.siemens.de/solutionprovider/_online_lexikon/7/f005477.htm
28.10.2003)
(zuletzt
abgerufen
am
13
rieren. Die Auswertungsbefehle und –ergebnisse sind standardisiert, so kann ein Austausch der Daten stattfinden. Die Systeme arbeiten zusammen und sind zueinander interoperabel.
Abbildung 2-5: Traditionelle GIS
Abbildung 2-6: Interoperable GIS
(Quelle: Doyle 2003)
(Quelle: Doyle 2003)
Die Interoperabilität von Systemen bietet eine Reihe von Vorteilen. Wie aus Abbildung
2-6 bereits ersichtlich ist, können Systeme gegenseitig aufeinander zugreifen. Durch die
Interoperabilität muss das abfragende System nichts über die interne Datenorganisation
des angefragten Systems wissen. Die Daten werden auf den vereinbarten Schnittstellen
zur Verfügung gestellt und abgerufen. Die Daten verbleiben also beim Urheber. Das hat
auch einen anderen Vorteil: In der Vergangenheit war es immer so, dass Daten von einem Anbieter gekauft wurden und dann auf das eigene System implementiert worden
sind. Eine direkte Umsetzung der Daten in die eigene Software war nur bedingt möglich.
Durch eine interoperable Schnittstelle zwischen dem System des Anbieters und dem
Nutzer kann immer auf den aktuellen Datenbestand zugegriffen werden. Man denke hier
zum Beispiel an eine ALK-Karte12. Sobald diese durch eine genormte Schnittstelle abrufbar ist, können Nutzer immer auf eine aktuelle Karte zugreifen. Ein weiterer Datenaustausch ist unnötig (Teege, Seuß 2003).
Aus der Interoperabilität erwächst aber auch ein Nachteil für die GIS-Hersteller: Für die
Kunden ist es einfacher, die Systeme zu wechseln. Sie brauchen keine Angst von Datenverlusten oder Ungenauigkeiten bedingt durch die Datei-Konvertierung haben und können somit auf einfache Weise ihre Software austauschen (Schlicher 2003).
Abbildung 2-7 zeigt ein weiteres Beispiel für ein interoperables Netzwerk. Einzelne Nutzergruppen sind durch das Internet vernetzt und können auf die Daten von anderen Anbietern zugreifen. Dieses Netz ist beliebig erweiterbar. Es wird deutlich, wie der direkte
Zugriff auf die Daten des anderen Herstellers singuläre Firmenlösungen verdrängt und
vor allem Vorteile im täglichen Leben bringt.
12
ALK ist die Abkürzung für „Automatisches Liegenschaftskarte“.
14
Abbildung 2-7: Interoperables Netzwerk (Quelle: Stobl 1999)
Wie oben bereits angedeutet, gibt es verschiedene Organisation, die sich mit der Schaffung von Standards für das Internet beschäftigen. Einige seien hier aufgelistet:
ISO
International Organization for Standardization (http://www.iso.ch/)
OGC
Open GIS Consortium (http://www.opengis.org/)
ANSI
American National Standards Institute (http://www.ansi.org/)
W3C
World Wide Web Consortium (http://www.w3c.org/)
WS-I
Web Services Interoperability Organization (http://www.ws-i.org/)
IHO
International Hydrographic Organization (http://www.iho.shom.fr/)
LIF
Location Interoperability Forum (http://www.openmobilealliance.org/lif/)
GSDI
Global Spatial Data Infrastructure (http://www.gsdi.org/)
CEN
European Committee for Standardization (http://www.cenorm.be/)
DGIWG
Digital Geographic Information Working Group (http://www.digest.org/)
Im Folgenden soll nun das Open GIS Konsortium (OGC) näher vorgestellt werden. Zusammen mit der ISO werden in dieser Organisation Standards erstellt, die sich mehr und
mehr durchsetzen. Die Hersteller sind neuerdings bemüht, die Standards der OGC in ihrer Software zu implementieren.
15
2.2.2 Das Open GIS Konsortium
Das Open GIS Konsortium, Inc., ist ein Gremium zur Standardisierung von offenen Geoinformationssystemen. Es arbeitet auf internationaler Ebene und wurde 1994 gegründet.
Initiatoren kamen aus der US-Regierung, dem Militär und anderen Forschungsgruppen.
Der Begriff OpenGIS® ist mittlerweile ein eingetragenes registriertes Handelszeichen
(Registered Trademark). Er steht für die Spezifikationen und Dokumente, die vom Open
GIS Konsortium erstellt werden. Diese Spezifikationen stehen für interoperable Lösungen. Das Ziel ist die gemeinsame Nutzung von geographischen Informationen mit anderen Datenquellen. Die OGC definiert unter www.opengis.org ihre Ziele und
Missionen wie folgt:
Our Vision
A world in which everyone benefits from geographic information and services made available across any network, application, or platform.13
Our Mission
Our core mission is to deliver spatial interface specifications that are openly available
for global use.14
Abbildung 2-8: Aufbau der OGC (Quelle: OGC15)
13
http://www.opengis.org/about/?page=vision (letzter Zugriff am 7.12.2003)
14
http://www.opengis.org/about/?page=vision (letzter Zugriff am 7.12.2003)
15
http://www.opengis.org/about/?page=programs (letzter Zugriff am 7.12.2003)
16
Das Open GIS Konsortium besteht mittlerweile aus über 250 Mitgliedern aus Firmen,
Regierungsgruppen und Universitätsmitgliedern. Der Aufbau dieses Gremiums ist in
Abbildung 2-8 zu sehen. Auf die Säulen dieser Organisation soll im folgenden eingegangen werden.
Die OGC arbeitet bei der Entwicklung der einzelnen Spezifikationen nach dem KonsensPrinzip. Das heißt, dass die Mitgliedermeinungen gesammelt und zusammengetragen
werden. Es wird dabei eng mit anderen Organisationen wie beispielsweise der ISO oder
dem W3C zusammengearbeitet. Die Erarbeitung der Spezifikationen selbst erfolgt in den
sogenannten Special Interest Groups und Working Groups. Diese bilden zusammen das
„Specification Program“.
Zur Ergänzung des „Specification Program“ wurde das „Interoperability Program“ geschaffen. Hier werden Prototypen und Demo-Szenarien innerhalb von Testbeds entwickelt und die Durchführung von Pilotprojekten geplant. Ein Testbed ist ein Testen der
Software unter realen Bedingungen. Anhand der Ergebnisse können wichtige Resultate
für die Forschung abgeleitet werden.
Im Bereich „Outreach and Community Adoption“ werden Entwicklern und Programmieren Hilfen zu den OGC Standards angeboten. Daneben werden Veröffentlichungen,
Workshops, Seminare und Konferenzen geplant.
2.2.2.1 OGC Web Services
Die OGC versucht durch die Schaffung von Schnittstellen Interoperabilität herzustellen.
In Abbildung 2-9 sind die bisher wichtigsten Schnittstellen dargestellt:
-
Web Registry Server
-
Web Map Server
-
Web Feature Server
-
Web Coverage Server
Die Software Hersteller versuchen diese Schnittstellen in ihrer Software zu implementieren. So kann auf Dauer ein einfacher Umgang mit den Daten erzielt werden. Ein Netz
wie in Abbildung 2-7 wird geschaffen.
Die freie Kombinierbarkeit der einzelnen Komponenten nach dem Baukastenprinzip vervielfacht die Möglichkeiten der Nutzung. Aus den neuen Möglichkeiten ergeben sich
eine Reihe von Nutzungschancen für die Praxis. Große Vorteile für verschiedene Fachbereiche resultieren aus dem neuen Weg der Informationsbeschaffung und -bereitstellung
(Andrae 2003).
17
Abbildung 2-9: OGC Web Services Architektur (Quelle: OGC)
Für nähere Information zu den einzelnen Services wird auf das Open GIS Konsortium
„Discussion Paper #01-022r1 – Basic Services Model Draft Candidate Implementation
Specification“ verwiesen.
Im weiteren soll besonders auf den Service des Web-Map Servers eingegangen werden.
2.2.2.2 Das Portrayal
Das Portrayal (engl. für Darstellung, Schilderung) ist ein Modell, das die Grundlage für
einen Mapping Service bildet.
Das Portrayal ermöglicht, dass die Geoinformationen in einer Karte nicht nur von einem
Anbieter kommen, sondern auch von mehreren überlagert werden (Cuthbert, Doyle
1998).
Cuthbert und Doyle (1998) zeigen die Hauptkomponenten eines interaktiven Portrayals
auf. Interaktiv heißt in diesem Fall, dass der Benutzer neben dem Betrachten auch die
Karte verändern kann. Die Komponenten sind:
-
Request (Initialisierungsanfrage zum Generieren eines Portrayals)
-
Portrayal (Generierung der Karte)
-
Query (Anfrage über einzelne Objekte in einer Karte)
-
Create (neue Daten zur Karte hinzufügen, z.B. weitere POIs)
-
Update (Ändern oder Bearbeiten der Daten in einer Karte)
-
Session (gibt Auskunft über die anderen unterstützten Operationen)
18
Diese Elemente lassen sich in drei Gruppen einteilen: Betrachtung (Request, Portrayal,
Query), Bearbeitung (Create, Update) und Administration (Sesion).
Abbildung 2-10 verdeutlicht den Aufbau einer Kartengenerierung (Portrayal). Das Modell ist dabei von unten nach oben zu betrachten.
Als Grundlage dient die Datenbank (Data Source), hier sind alle Daten gespeichert. Einzelne Objekte können durch eine Anfrage extrahiert werden. Es wird dabei zwischen
StyleInfo und DisplayInfo unterschieden. StyleInfo verkörpert die einzelnen graphischen
Elemente für die aktuelle Zoomstufe. Die DisplayInfo beinhaltet die Informationen zum
aktuellen Kartenausschnitt. Neben der geographischen Ausdehnung gehört auch die Festlegung des räumlichen Bezugssystem (Spatial Reference Systems – SRS) und des Maßstabes dazu. Zusammen erhält man dann die Objekte für den gegenwärtigen abgefragten
Kartenausschnitt. Die Abfrage erfolgt durch ein Filter Encoding. Das ist eine Anfragesprache der OGC, die speziell für räumliche Objekte entwickelt wurde.
Abbildung 2-10: Portrayal Modell (Quelle: Cuthbert, Doyle 1998)
Die Trennung von DisplayInfo und StyleInfo hat den Vorteil, dass nicht immer wieder
neu auf die Datenbank zugegriffen werden muss. Die Objekte der StyleInfo können für
verschiedene Kartenausschnitte dargestellt werden und ermöglichen beispielsweise ein
Zoomen oder Scrollen ohne erneuten Zugriff auf die Datenbank.
Nachdem die einzelnen Objekte zur Verfügung stehen, ist eine Signaturierung notwendig, das heißt, dass den einzelnen Objekten ein Symbol oder eine Zeichendarstellung
19
zugewiesen wird. Oft werden Informationen zur Darstellung mit dem StyleInfo übergeben. Hierzu kann auch eine maßstabsabhängige Darstellung oder einen Reihenfolgenhinweis zählen.
Die signaturierten Objekte können anschließend in eine Karte umgesetzt werden. Dieser
Vorgang ist vergleichbar mit einem Druckaufruf. Es werden die Schriften, die Farben,
die Linien und Flächen und die Symbole in einer Karte angeordnet und geplottet. In der
obigen Abbildung ist dies mit „Render“ bezeichnet.
Der letzte Schritt ist die Darstellung der Karte auf dem Ausgabegerät. Dies kann beispielsweise ein Drucker, ein Personal Digital Assistant (PDA) oder einfach ein Monitor
sein. Es ist dabei auch möglich, die Karte direkt in eine Web-Seite einzubauen.
Im Kapitel 2.1.4 wurde bereits die Realisierung von Web-Maps durch Thin- und ThickClients angedeutet. Die Abbildung 2-11 und Abbildung 2-12 zeigen die Umsetzung dieser Clients auf das Portrayal. Es ist gut zu erkennen, dass der Thin-Client fast ausschließlich nur zum Anzeigen der Karte fähig ist. Der Thick-Client hingegen ist sehr viel
mächtiger. Dieser Client unterstützt auch die Unterscheidung zwischen StyleInfo und
DisplayInfo. Nachdem der Client die Objekte geladen hat, kann die Signaturierung und
das Rendering in der Applikation selbst ausgeführt werden.
Abbildung 2-11: Thin Client
Abbildung 2-12: Thick Client
(Quelle: Cuthbert, Doyle 1998)
(Quelle: Cuthbert, Doyle 1998)
Im weiteren soll nun auf den Web Map Service eingegangen werden.
2.2.3 Web Map Service
Die „Web Map Service“ Spezifikation ist die älteste OGC-Schnittstelle. Sie erlaubt den
Zugriff auf Geodaten in Form von fertigen graphischen Karten und ist seit 1999 verfügbar. (Teege, Seuß 2003). Mittlerweile gibt es die Spezifikation in der dritten Version
(1.1.1). Die alten Versionen 1.0.0 und 1.1.0 sind derzeit noch gültig. Die weiteren Ausführungen basieren auf dem 1.1.1 Standard. Zu beachten ist, dass die vorgestellten Anfragen für die Version 1.0.0 nicht gültig sind, da einige Anfrageparameter von der OGC
zur Version 1.1.0 geändert worden sind.
20
Ein Web Map Service, kurz WMS, produziert nach einer Anfrage eine georeferenzierte
Karte. Die OGC Spezifikation definiert drei WMS Operatoren:
-
GetCapabilities
-
GetMap
-
GetFeatureInfo
Da im Weiteren nicht mehr auf die GetFeatureInfo eingegangen wird, soll an dieser Stelle noch eine Kurze Informationen zu dem Operator gegeben werden: Da dieser Operator
optional ist, muss ein Server nicht zwangsläufig diese Funktion unterstützen. Er ermöglicht einen Informationsabruf von einzelnen Elemente in einer Karte. Näheren Informationen zu diesem Operator enthält die WMS Spezifikation (De La Beaujardière 2002).
Die Anfragen werden über das Internet an den Web Server gerichtet. Typischerweise
wird die Anfrage an einen WMS im HTTP GET Modus geschickt. Dabei werden notwendige Karten-Parameter mit in die URL geschrieben: Nach dem Host folgt ein Fragezeichen (“?“). Im Anschluss an das Fragezeichen werden die serverspezifischen
Anfrageparameter angereiht, die sogenannten „name/value pairs“, diese werden durch
ein „&“ voneinander getrennt. Die Reihenfolge der einzelnen Parameter ist dabei nicht
relevant. Hat ein Parameter mehrere Argumente, werden diese durch ein Komma voneinander getrennt.
Tabelle 2-3: OGC Web Service Anfrage (Quelle: De La Beaujardière 2002)
Sollte bei einer Anfrage an einen Web Server ein Fehler auftreten, so wirft der Server
eine Exception16 aus.
Ein WMS Server bietet nur eine reine Betrachtung der Karte. Es handelt sich dabei um
einen lesenden Zugriff des Nutzer auf den Server. Der Nutzer bekommt immer eine fertige Kartendarstellung und hat auf das Layout der Karte selber nur begrenzten Zugriff.
16
Eine Exception ist ein XML-Dokument, das bei einer ungültigen Anfrage vom Server anstatt der Karte
ausgesandt wird. Dieses Dokument beinhaltet eine Fehlermeldung, die eine Korrektur der Parameter erlaubt.
21
2.2.3.1 GetCapabilities
Der GetCapabilities Operator sendet ein Metadatendokument im XML17-Format (siehe
Anhang). Das übermittelte Dokument beschreibt die Fähigkeiten des Servers.
Eine GetCapabilities Anfrage an einen Server hat folgendes Format:
http://host[:port]/path?SERVICE=WMS&REQUEST=GetCapabilities
Die Anfrageparameter gibt die OGC wie folgt an:
Tabelle 2-4: Parameter des GetCapabilities Operators (Quelle: De La Beaujardière 2002)
Die obige Anfrage beinhaltet nur die notwendigen Parameter. Die Parameter VERSION
und UPDATESEQUENCE sind optional.
Das auf die Anfrage übermittelte Dokument beinhaltet eine Reihe von Informationen.
Am Anfang des Dokuments stehen Angaben über den Anbieter der Karte und eventuelle
Nutzungsbestimmungen. Nach diesen Informationen folgen die Hauptelemente des Dokumentes. Es sind Informationen über unterstützte Ausgabeformate der Karte und die
unterstützten Referenzsysteme. Jedes Dokument muss genau ein „LatLonBoundingBox“
Element enthalten. In diesem wird die geographische Ausdehnung im Bezugssystem
WGS 84 angeben. Dieses soll gewährleisten, dass der Betrachter unabhängig von den
unterstützen Bezugssystemen eine Vorstellung erhalten kann, welches Gebiet durch den
Server abgedeckt wird.
Darauf folgen die Layer mit spezifischen Informationen zur Abfrage. Dies sind beispielsweise Informationen über einen möglichen ScaleHint, den Namen und den Titel des
Layers und der möglichen Styles. Ein ScaleHint deutet darauf hin, dass der Layer nur in
einem bestimmten Maßstabsbereich in der Karte darstellbar ist.
Wenn Styles zu einem Layer im Capabilities Dokument angegeben werden, ist es möglich, den Layer neben der Standarddarstellung auch in weiteren Darstellungsvarianten in
der Karte anzuzeigen. Beispielsweise könnte ein Layer anstatt blau dann grün visualisiert
werden.
17
XML ist eine Metasprache. Die Abkürzung steht für „eXtensible Markup Language“.
22
2.2.3.2 GetMap
Wenn ein Nutzer alle notwendigen Parameter aus dem Capabilities Dokument gesammelt
hat, kann eine Karte in einem Web-Browser vom Server abgerufen werden. Hierzu dient
der Operator GetMap.
Eine mögliche Anfrage ist:
http://host[:port]/path?REQUEST=GetMap&VERSION=1.1.1&LAYERS=
Layer1,Layer3,Layer2&SRS=EPSG:31466&BBOX=2490217.397,5567468
.868,2755523.053,5832774.524&FORMAT=image/png&WIDTH=500&HEIG
HT=500&TRANSPARENT=TRUE&STYLES=
Diese Anfrage beinhaltet eine Reihe von Parametern. Die Inhalte wurden teilweise aus
dem Capabilities Dokument ermittelt, aber teilweise auch vom Nutzer festgelegt, wie
beispielsweise die Ausgabegröße der Karte. Im Folgenden soll auf die wichtigsten Elemente noch einmal kurz eingegangen werden.
Tabelle 2-5: GetMap Parameter (Quelle: De La Beaujardière 2002)
23
Tabelle 2-5 listet die möglichen Parameter für eine Kartenabfrage auf. Die Parameter, die
ein “R“ in der zweiten Spalte besitzen, müssen für eine gültige Anfrage immer in der
URL eingebaut sein. Sind diese Parameter nicht vorhanden, kommt es zu einer Fehlermeldung, einer sogenannten Exception18. Wenn kein Attribut für einen notwendigen Parameter übergeben werden soll, wird der Parameter leer in die Anfrage geschrieben (z. B.
„STYLES=“).
Der LAYERS Parameter legt die darzustellenden Layer in einer Karte fest. Diese werden
in einer durch Komma getrennten Liste an den Parameter angereiht. Dieses Abfrageelement entscheidet über die Sichtbarkeit einzelner Layer. Es werden nur die Layer in der
Karte dargestellt, die in der Liste sind. In der Karte ist die Priorität der Layer durch die
Reihenfolge in der Liste vorgegeben (der erste Layer hat die niedrigste Priorität, usw.).
Abbildung 2-13: Kombination zweier WMS
Wichtig ist auch die Festlegung des räumlichen Referenzsystems (SRS). Dieses legt das
Koordinatensystem fest und ist entscheidend für Verzerrungen in einer Karte. Speziell
wenn zwei Karten von unterschiedlichen Servern zusammen dargestellt werden, können
Probleme entstehen, wenn die Server nicht das gleiche Referenzsystem unterstützen.
Abbildung 2-13 zeigt eine mögliche Kombination: Zwei Karten von unterschiedlichen
Servern sind zu einer Darstellung zusammengefügt worden. Die Überlagerung von mehreren Karten erfordert einen Anzeigeclient. In einem Standard Web-Browser ist dies
nicht möglich. Die Serverkarten müssen mit transparentem Hintergrund abgefragt werden. Es ist allerdings nicht immer so einfach zwei WMS zu kombinieren, wie es in
Abbildung 2-13 scheint. Oft kann eine gemeinsame Darstellung daran scheitern, dass die
beiden WMS Server nicht die gleichen Referenzsysteme unterstützen. Karten mit unterschiedlichem Bezugssystem können nur durch eine Transformation zusammen dargestellt
18
Vergleiche Fußnote 16.
24
werden. Die Implementierung dieser Transformation in einem Client ist umso aufwendiger, je mehr Referenzsysteme ineinander übergeführt werden sollen.
Der Parameter BBOX steht für die Bounding Box der Karte. Dies ist die geographische
Ausdehnung der Karte. Abbildung 2-14 zeigt die Attribute des Parameters. Es wird erst
die untere linke Ecke mit X und Y Koordinaten angegeben, darauf folgt die obere rechte
Ecke. Die Koordinatenangaben müssen aus dem angefragten Referenzsystem stammen.
Abbildung 2-14: Festlegung einer Bounding Box (Quelle: de La Beaujardière 2002)
2.3 Web-Mapping-Clients
Im Weiteren sollen einige Web-Mapping-Clients aus dem Internet vorgestellt werden. Es
soll dabei ein Überblick über die aktuelle Software gegeben werden.
Abschließend werden Kriterien erarbeitet, um die Clients miteinander zu vergleichen.
Dabei soll insbesondere das Kriterium der Interoperabilität Beachtung finden.
2.3.1 ESRI ArcIMS
Der Software-Hersteller ESRI bietet von Haus aus zwei Web-Clients an. Diese sind auf
das Produkt ArcIMS abgestimmt. Die Designer-Applikation des ArcIMS Servers kann
auf der Grundlage der ArcIMS Dienste diese Clients erzeugen und im Internet zur Verfügung stellen. Ein ArcIMS Dienst ist die Karte, die der Server anbietet.
Im Gegensatz zu den anderen Clients, die vorgestellt werden, ist die ESRI ArcIMS Lösung aus diesem Beispiel nicht im Internet verfügbar. Die vorgestellten Clients stammen
aus einer Standard-Installation, die speziell für diese Arbeit angelegt worden ist.
Die zwei Varianten der Web Clients unterscheiden sich in der Programmierung. Der erste Client ist eine reine HTML- und JavaScript-Lösung (siehe Abbildung 2-15). Der
Client ist übersichtlich gestaltet, wenn auch die Anordnung der Layerübersicht auf der
rechten Seite der Karte etwas ungewöhnlich erscheint. Es besteht die Möglichkeit eine
Übersichtskarte einzublenden. Dadurch ist sichergestellt, dass trotz des Zoomens und
Pannings nie der Überblick über die aktuelle Position in der Karte verloren geht.
25
Abbildung 2-15: Screenshot ArcIMS HTML Viewer
Der Client bietet die üblichen Funktionalitäten, die von einem InternetGIS verlangt werden: Die Layer können an- und ausgeschaltet werden, und mit der Karte kann interaktiv
gearbeitet werden. Des Weiteren ist eine Distanzmessung innerhalb der Karte möglich.
Die zweite Lösung, die ESRI präsentiert, basiert auf der Programmiersprache Java. Um
diesen Client im Web-Browser laden zu können, wird ein PlugIn der Firma Sun benötigt.
Beim Laden der Karte wird ein Java Applet ausgeführt. Der Client ist ähnlich gestaltet
wie die HTML Variante (siehe Abbildung 2-16), bietet jedoch mehr Funktionalitäten.
Die Layer reagieren in diesem Client direkt auf eine Auswahl, es ist keine gesonderte
Bestätigung (Refresh) notwendig. Gut gelungen ist, dass neben den Layernamen die
Signaturierung angezeigt wird. Dadurch kann der Kartennutzer den Layer direkt in der
Karte identifizieren, und die Layeranzeige bekommt Legendencharakter.
Weitere Funktionen sind beispielsweise, dass eigene Shapefiles19 in die Karte geladen
werden können. Darüber hinaus ist die Auswahlfunktion von Kartenobjekten erweitert
worden. Als kleine Besonderheit kann noch erwähnt werden, dass der Nutzer kurze Anmerkungen in die Karte schreiben kann. Diese Funktion scheint allerdings wenig ausgereift, da sie sehr kompliziert zu bedienen ist.
19
Ein Shapefile ist ein ESRI-Austauschformat und steht für „Spatia Data Format“.
26
Abbildung 2-16: Screenshot ArcIMS Java Viewer
ESRI bietet die Möglichkeit, bei der Erstellung der Clients die Funktionalitäten zu konfigurieren. Falls ein Anbieter einzelne Funktionen nicht zulassen möchte, so kann er diese
bei der Erstellung des Clients abwählen. Dies ist ebenfalls mit den einzelnen Layern aus
einer Karte möglich. Es ist für den Anbieter der Web Map denkbar, eine Karte individuell nach seinen Wünschen anzupassen.
Beide Clients bieten nicht die Möglichkeit, andere Karten von anderen Servern zu integrieren. Ebenso kann die Karteneinstellungen nicht persistent gehalten werden. Für den
Benutzer ist es nicht möglich die Karte in gleicher Form zu einen späteren Zeitpunkt erneut abzurufen. Die einzige Möglichkeit, die Karteneinstellungen zu sichern, bietet ein
Ausdruck.
Der ArcIMS 4.01 unterstützt nicht den OGC WMS Standard. ESRI bietet allerdings einen kostenlosen Adapter zum Download an, so dass ein Anbieter einer Web Map diese
Funktionalität durch eine Zusatzinstallation herstellen kann. Nach einer ordnungsgemäßen Installation kann die Karte per HTTP Request abgerufen werden (siehe Kapitel
2.2.3.2).
2.3.2 Ifgi Mapping Client
Der Web Client des Institut für Geoinformatik (Ifgi) der Universität Münster wurde im
Rahmen des GDI NRW Testbed II entwickelt. Das Kürzel GDI NRW steht für Geodateninfrastruktur Nordrhein-Westfalen. Diese Organisation hat das Ziel, den Zugang zu Geoinformationen zu verbessern. Die Schaffung von Interoperabilität zwischen den
27
Systemen steht dabei im Vordergrund. Unter anderem versucht diese Organisation die
Standards der OGC regional umzusetzen.
Der Client aus Abbildung 2-17 ist unter der URL: http://rizzo.unimuenster.de:8080/WebMapClient/jsp/navigation.jsp20 zu erreichen.
Im Gegensatz zu der vorgestellten ESRI Lösung handelt es sich bei diesem Client um
einen Viewer, der speziell zum Abruf von WMS Servern programmiert wurde. Der
Client ist sehr robust. Es ist ohne weiteres möglich, andere WMS Karten in den Client zu
laden. Leider lassen sich dabei keine Karten kombinieren.
Die Umsetzung des Clients basiert auf Java Server Pages. Das Layout ist schlicht und
geordnet. Die Bedienung erfolgt über die Elemente in der Kopfzeile und über Gliederungselemente in der Mitte der Seite. Leider ist es nicht möglich, ein Zoomfenster aufzuziehen, sondern der Zoom reagiert nur auf einen Klick in die Karte. Eine individuelle
Vergrößerung des Kartenausschnittes ist dadurch nicht möglich. Durch Pfeile an den
Seiten der Karte ist es möglich, über die Karte zu navigieren. Die Bedienung ist allgemein sehr rudimentär gehalten, erfüllt aber normale Funktionalitäten.
Abbildung 2-17: Screenshot Ifgi Web Map Client
20
Letzter Zugriff am 8.12.2003.
28
Die Layer des Clients lassen sich problemlos an- und abwählen. Es ist möglich, jeden
Layer an die höchste Anzeigepriorität zu setzen. So kann die Layerreihenfolge in der
Karte neu geordnet werden. Mit einem Klick auf den Layer selbst lassen sich Styles zu
den einzelnen Layern einstellen.
Der Ifgi Client ist in der Lage den GetFeatureInfo Operator des WMS Servers abzufragen. Ist diese Option im Client ausgewählt, werden auf einen Klick in die Karte die Informationen zu den ausgewählten Objekten vom Server abgerufen. Diese werden in
einem separaten Fenster präsentiert.
Der Viewer ist speziell auf die OGC WMS Dienste zugeschnitten. Er bietet alle notwendigen Funktionen, um einen WMS Server abzurufen.
Es ist leider nicht möglich, die Einstellungen (wie angezeigter Server, aktuelle Layer,
aktuelle Zoomstufe, aktuelle Position in der Karte) zu speichern. Ein Ausdruck der Karte
selbst wird vom Client nicht unterstützt, es besteht allerdings die Möglichkeit, die Karte
aus dem Internetbrowser zu plotten.
2.3.3 Intergraph WMS Viewer
Die Firma Intergraph präsentiert ihren OGC WMS Viewer unter der URL:
http://www.wmsviewer.com21. Der Client ist auf keine direkte Karte abgestimmt,
sondern speziell für OGC WMS Karten programmiert.
Neue Server können über eine Menuoption aus der oberen Leiste hinzugefügt werden. Es
wird dazu eine Liste mit vordefinierten Servern angeboten. Zudem steht dem Nutzer eine
Eingabezeile zur Verfügung, um WMS Server außerhalb der Liste im Client zu importieren. Der Client unterstützt die Darstellung mehrerer Karten gleichzeitig. Über eine Prioritäteneinstellung kann die Anordnung der Karten im Client bestimmt werden.
Leider ist es nicht gelungen, jeden WMS Server im Client zu integrieren. Auffällig ist,
dass nur WMS Server, die das Referenzsystem WGS 84 unterstützen, eingebunden werden konnten.
Das Layout des Client ist freundlich gestaltet. Intergraph hat eine gute Benutzerführung
entworfen, die intuitiv zu bedienen ist.
Es stehen übliche Funktionalitäten wie beispielsweise das Zoomen und Panning zur Verfügung. Das Layer-Fenster kann zur Legende umgestellt werden. So kann der Nutzer der
Karte sich schnell mit den Signaturen der Karte vertraut machen.
Der Operator GetFeatureInfo steht auch in diesem Client zur Verfügung. Die Informationen aus der Karte werden nach dem Abrufen geordnet in einer Tabelle wiedergegeben.
Diese ist entsprechend den dargestellten Servern geordnet.
21
29
Das Kartenfenster ist mit Pfeilen in allen Himmelsrichtungen ausgestattet, so kann der
Nutzer einfach über die Karte navigieren. Die Kartengröße selbst kann leider nicht angepasst werden. Es kommt zu weißen Überhängen, wenn die Bildschirmauflösung über der
von Intergraph vorkonfigurierten liegt.
Der Viewer ist in der Lage, WMS Context Dokumente zu speichern und wieder zu laden.
Diese Dokumente wurden von der OGC zur Speicherung von Einstellungen spezifiziert.
Context Dokumente sind XML-Dokumente, die alle Informationen zu einer abgespeicherten Kartenkonfiguration beinhalten. In dem Dokument sind die angezeigten Server,
der aktuelle Kartenausschnitt, die aktiven Layer und das eingestellte Referenzsystem
gespeichert. So kann ein Nutzer seine Karteneinstellungen persitent halten und zu einem
anderen Zeitpunkt wieder abrufen. Dieses Dokument könnte auch per Email zu einer
weiteren Person geschickt werden, die somit die Kartenkonfiguration des Versenders
abrufen kann. Die Besonderheit dieser Context Dokumente ist, dass sie nicht an einen
Client gebunden sind. Dem Nutzer solch eines Dokumentes ist also frei gestellt, welchen
Client er benutzen möchte. Leider unterstützen bis jetzt kaum Clients dieses Feature.
Abbildung 2-18: Screenshot Intergraph OGC WMS Viewer
30
2.3.4 GeoServer der LDS NRW
Das Landesamt für Datenverarbeitung und Statistik Nordrhein-Westfalen (LDS NRW)
22
stellt auf der Internetseite http://www.geoserver.nrw.de/OgcWmc.html
einen Java Client zur Verfügung. Mit diesem Client können speziell vorkonfigurierte
Karten abgefragt werden. (vergleiche Abbildung 2-19)
Der Client ist sehr schlicht gehalten. Die Bedienung ist anfangs gewöhnungsbedürftig, da
einige Symbole fremd erscheinen. Die Layerauswahl ist gut angeordnet. Etwas undurchsichtig ist dabei allerdings, dass man nach dem An- oder Abwählen eines Layers auf die
Aktualisierenschaltfläche klicken muss. Dieser ist räumlich getrennt von der Layerauswahl und in der oberen Bedienungsleiste angeordnet.
Der Client unterstützt alle OGC WMS Operatoren und bietet zudem noch spezifische
Funktionen. Beispielsweise ist es möglich, einen separaten Grafikeditor zu starten. Mit
diesem kann man halbtransparente farbliche Flächen über die Karte zeichnen. Durch diese Flächen können einzelne Orte in der Karte hervorgehoben werden.
Abbildung 2-19: Screenshot LDS GeoServer
22
letzter Zugriff am 8.12.2003
31
Besonders zu erwähnen ist die NRW Gebäude-Karten-Anwendung. Diese erlaubt es nach
einer Anschrift in der Karte zu suchen: Der Nutzer kann in einer Maske den gewünschten
Ort, die Strasse und die Hausnummer eingeben und bekommt daraufhin die Adresse
durch ein Kreuz in der Karte angezeigt.
Bedauerlicherweise ist der Client nur für die vorkonfigurierten Server ausgerichtet. Es ist
nicht möglich, weitere WMS Server in den Client zu laden.
Besonders zu erwähnen ist noch, dass dieser Client die Ausgabegröße der Karte immer
speziell an die Fenstergröße des Browsers anpasst. Damit ist ein Betrachten der Karte in
jeder Bildschirmauflösung sichergestellt. Die angezeigte Karte kann ohne Probleme in
ihrer vollen Ausdehnung auf dem Monitor dargestellt werden.
Wie auch in anderen Clients existiert keine separate Ausdruckfunktion. Ebenso können
die persönlichen Einstellungen des Nutzer nicht persistent gespeichert werden. Dadurch
ist ein erneutes Abrufen einer vom Nutzer angepassten Karte zu einem späteren Zeitpunkt unmöglich.
2.3.5 Vergleich der vorgestellten Web-Clients
In den vorstehenden Kapiteln wurden einige Web-Clients beschrieben, dieser Abschnitt
soll einen direkten Überblick über die vorgestellten Lösungen geben. Es wurden Bewertungskriterien geschaffen, die auf den Funktionalitäten der einzelnen Clients aufsetzen.
Anhand dieser Merkmale werden die Clients verglichen.
Viewer
Layout /
Funktionalität
WMS Fähigkeit / gleichzeitiges Anzeigen mehrerer WMS Karten
Speicherung der
Einstellungen
ESRI HTML Client
+
-/-
-
ESRI Java Client
+
-/-
-
Ifgi Client
+
+/-
-
Intergraph Client
+
(+)23 / +
+
GeoServer Client
+
+ / (+)24
-
Tabelle 2-6: Vergleich der vorgestellten Clients
23
24
Es konnten nicht beliebige WMS Server zur Karte hinzugefügt werden.
Der GeoServer ist zwar in der Lage, mehrere Karten übereinanderzulegen, es können aber keine eigenen
WMS zum Client hinzugefügt werden.
32
Die Tabelle 2-6 zeigt einen Vergleich der vorgestellten Clients. Es sind drei Kriterien
herausgearbeitet, die die Clients vergleichbar machen.
Das erste Kriterium bezieht sich auf das Erscheinungsbild des Clients. Es ist das Layout
und die unterstützten Funktionalitäten beurteilt worden. Die vorgestellten Lösungen haben diesem Kriterium viel Beachtung geschenkt. Die Clients sind auf eine gute Benutzerführung abgestimmt und bieten genügend Möglichkeit zur Interaktion mit der Karte.
Auffällig ist, dass bis auf die Clientlösungen der Firma ESRI alle Clients kein gesondertes Druckmenu bieten. Dem Nutzer ist es nicht möglich, die Karte ohne den Client auf
Papier auszudrucken.
Ebenfalls außergewöhnlich ist, dass einige Clients das Kartenfenster nur in einer festen
Pixel-Größe in die Webseite eingebunden haben. Es wird oft Platz verschenkt, der für
eine bessere Kartendarstellung dienen könnte. Die Kartengröße wird oft nicht an die
Bildschirmgröße angepasst, sondern ist nur für eine bestimmte Auflösung optimiert worden.
Das zweite Kriterium zielt auf OGC Konformität. Dabei wird zusätzlich noch unterschieden, ob der Client nur in der Lage ist beliebige WMS darzustellen, oder ob auch
mehrere Karten gleichzeitig in den Client geladen werden können.
Die ESRI Clients sind speziell auf den ArcIMS abgestimmt. Auch wenn dieser in der
Lage ist, durch eine Zusatzinstallation eine OGC Konformität zu erfüllen, arbeiten die
Clients weiterhin über die interne ArcIMS Schnittstelle. Die Clients sind nicht für WMS
Karten programmiert worden.
Bedauerlicherweise unterstützt nur ein vorgestellter Client die Darstellung mehrere beliebiger WMS gleichzeitig. Gerade diese Funktionalität erlaubt dem Nutzer mehrere
WMS Karten bzw. Layer von verschiedenen Servern zu kombinieren und so den Informationsgehalt der Karte zu steigern.
Das dritte Kriterium soll die Persistenz der Einstellungen in einem Client beurteilen.
Während ein Betrachter mit einer Karte arbeitet, wird oft der geographische Ausschnitt
verändert, es werden Layer eingeblendet oder es werden unter Umständen neue Karten
ergänzt. Kartographische Offline-Anwendungen bieten die Möglichkeit diese Einstellungen s zu speichern. Dadurch hat der Nutzer die Möglichkeit die Karte zu einem späteren
Zeitpunkt in gleicher Form erneut abzurufen. Von den vorgestellten Web-Clients bietet
nur die Intergraph Lösung diese Funktion. Der Client benutzt hierzu die Web Map Context Spezifikation der OGC. Hierdurch wird es sogar ermöglicht die gleiche Kartenkonfiguration in einem anderen Client wiederherzustellen.
3 Kooperative GIS
Kapitel 3
Kooperative GIS
Viele Entscheidungen des täglichen Lebens haben einen Raumbezug. Karten sind ein
hilfreiches Medium, um diese Entscheidungen zu unterstützen. Oft werden herkömmliche Papierkarten auf einfache Weise ergänzt, indem ein Betrachter beispielsweise etwas
in eine Karte schreibt oder einen Notizzettel an eine Stelle in der Karte klebt. Eine derartig leichte Ergänzungsform ist mit einer jeden Internetkarte kaum möglich. Dies schränkt
die Nutzbarkeit einer Web Map erheblich ein.
Kartenergänzungen führen zur Personalisierung von Karten und ermöglichen die Diskussion über räumliche Sachverhalte. Kommentare können in Karten Personen zu bestimmten Orten führen, Planungsvorhaben begründen oder Erklärungen zu geographischen
Orten abgeben. Der direkte Bezug vom Text zur Karte ermöglicht eine schnelle Erfassung des Inhaltes für alle Beteiligten. Die georeferenzierten Meinungen machen es möglich, über die Karteninhalte zu diskutieren. Die Karte tritt in den Dialog zwischen
Mensch und Mensch. Eine Kommunikation über das Internet könnte Entscheidungsprozesse beschleunigen, da durch dieses Informationsnetzwerk eine Ortsunabhängigkeit erreicht wird.
Für die Umsetzung einer Karten-Ergänzungs-Methode auf digitale Karten ist ein Softwareumgebung notwendig, die es erlaubt, Karten weiterzubearbeiten. Zudem ist eine
Speicherungsmöglichkeit für die modifizierte Karte zwingend erforderlich, um allen beteiligten Personen in einem Verfahren den Zugang zu den Informationen bieten zu können. Durch Kommentare in Karten wird eine kooperative Planung ermöglicht.
In den folgenden Kapiteln werden verschiedene kooperative Konzepte vorgestellt, die es
erlauben, eine Karte zu modifizieren und zu kommentieren. Abschließend wird anhand
eines Internetportal gezeigt, wie eine Umsetzung für die Kommentierung und Abspeicherung einer Internetkarte aussehen kann.
3.1 Kooperative Konzepte
Kooperative Arbeit setzt immer eine Diskussion in einer Gruppe voraus. Oft stehen spezielle Fragestellungen bei den Dialogen im Vordergrund. Die räumliche Entscheidungs33
Kapitel 3: Kooperative GIS
34
findung wird oft durch eine Kartendarstellung unterstützt. Neue Formen der Beteiligung
werden durch das Internet ermöglicht. Die Kombination von Methoden und Werkzeugen
aus dem GIS Bereich mit Diskussionsforen und Mediationssystemen bieten neue Ansätze
(Greve und Rinner 1999). Es besteht allerdings ein enormer Nachholbedarf an angemessenen Hilfsmitteln zur Umsetzung. Im Bezug auf kooperative Konzepte werden Begriffe
wie „public participation GIS“ (PPGIS), „computer supported cooperative work“
(CSCW) und „collaborative spatial decision-making“ (CSDM) immer wieder in der Literatur erwähnt. Die folgenden Unterkapitel sollen die Ideen, die hinter diesen Begriffen
stecken, näher beleuchten.
3.1.1 Grundlagen
MacEachren (2001) führt in einem Artikel aus, dass die Entscheidungsfindung, die Lehre
und die Forschung Gruppenaktivitäten sind, jedoch die Werkzeuge der Kartographie und
die GIS-Anwendungen oft für den einzelnen Anwender programmiert wurden.
Der Forschungsbereich „Computer supported cooperative work“ (CSCW) unterteilt die
Mitarbeit einer Gruppe in räumliche und zeitliche Variablen. Hierbei wird die Mitarbeit
in „same or different place“ und in „same or different time“ differenziert. MacEachren
konzentriert sich in seiner Arbeit vor allem auf die Problematik, die sich aus der Gruppenarbeit an unterschiedlichen Orten ergibt. Er spricht von Hürden bei der technischen
Umsetzung: Angefangen von der ortsunabhängigen Visualisierung der Daten bis hin zu
den interaktiven Funktionalitäten der Benutzer existiert die Notwendigkeit einer Regelung, wie die Daten und Ideen der Gruppenmitglieder über die Distanz hinweg transportiert werden sollen. Es ist zu unterscheiden, ob eine asynchrone oder eine synchrone
Form der Mitarbeit gewählt wird. Für die synchrone Mitarbeit aller Beteiligten ist neben
dem Telefon, das eine verbale Verständigung ermöglicht, das Internet die wichtigste
Komponente. Die Fähigkeit Daten, Karten und Bilder über das Internet mit anderen Personen zu teilen, ermöglicht erst das Arbeiten unter kooperativen Aspekten.
Softwaresysteme zur asynchronen kooperativen Arbeit werden vor allem im Bezug auf
„public participation GIS“ (PPGIS) entwickelt. Durch solche Systeme wird eine webbasierte Bürgerbeteiligung zu städtebaulichen Entwicklungen ermöglicht. Es muss in solchen Systemen besonders Wert auf die Präsentationsform gelegt werden. Die Daten
müssen aufgearbeitet werden, so dass alle Nutzer unabhängig von ihrem Vorwissen, die
Informationen, die mit der Karte übermittelt werden sollen, verstehen können. Schließlich sollen alle die Chance haben ihre Meinung wiederzugeben. Die Universität von
Leeds hat in empirischen Forschungen herausgefunden, dass diese Form der Beteiligung
besonders die junge Bevölkerung anspricht. Die Flexibilität des Zugangs zum System
findet in dieser Bevölkerungsgruppe besonderen Zuspruch.
Die synchrone kooperative Mitarbeit unterscheidet sich durch die Art der Datenübertragung: Die Diskussion findet in Echtzeit statt. Es sind Methoden zu entwickeln, die die
parallele Interaktion mit der Karte an mehreren Orten erlaubt.
35
Bei der kooperativen Arbeit sind spezielle Aspekte zu beachten. Eine Softwareumgebung
muss verschiedene Perspektiven darstellen um Alternativen zuzulassen. Zudem sollten
Anwendungssysteme speziell auf die Thematik der Karte angepasst sein, um ein effektives Arbeiten zu ermöglichen. Diskussionen über Forschungsgegenstände oder über städtebauliche Entwicklungen sind sehr verschieden, es ist notwendig, dass diese
thematischen Randbedingungen in der Software berücksichtigt werden. Nur so kann eine
effektive computergestützte Entscheidungsfindung realisiert werden.
3.1.2 Community Planning
Al-Kodmany (2000) beschreibt eine Lösung eines PPGIS. Er legt dar, wie Bürger einer
Stadt die Lebens- und Wohnqualität durch die Kopplung von Internet und GIS bewerten
können. Hierdurch wird Einfluss auf die Stadtplanung ausgeübt.
Al-Kodmany führt aus, dass der Maßstab für eine gute Stadtplanung die in der Stadt lebende Bevölkerung selbst ist. Hierbei beruft er sich auf Berichte von Nasar (1998). Nasar
ist der Auffassung, dass der Wert der Stadtgestalt empirisch durch Umfragen zumessen
ist. Beispielsweise kann dadurch, dass Bürger Plätze in einer Stadt nennen, deren Erscheinungsbild sie für besonders gelungen bzw. nicht gelungen halten, eine Karte erstellt
werden, in der diese Ergebnisse evaluiert werden. Eine Umsetzung dieser Bewertung in
einer Farbskala ist besonders anschaulich und übersichtlich.
Eine Bürgerbeteiligung durch das Internet ergibt eine Reihe von Vorteilen. Die Befragten können zum Beispiel unbeeinflusst und zwangsfrei antworten. Die Teilnehmer werden nicht unabsichtlich durch die Art des Fragestellenden manipuliert. Ebenfalls
vorteilhaft ist die Flexibilität eines solchen Systems. Eine orts- und zeitunabhängige Befragung ist möglich. Die Bürger können zu jeder Zeit und von jedem Ort durch das Internet an einer Befragung teilnehmen und sind losgelöst von Teilnehmerversammlungen
oder den Öffnungszeiten der Bürgerbüros (Al-Kodmany 2000).
In seinen Ausführungen beschreibt Al-Kodmany verschiedene Variationen der Befragung. Diese sind jeweils an der Universität von Illinois durchgeführt worden. Hierdurch
kommt er zu dem Fazit, dass beim Einsatz einer Karte berücksichtigt werden muss, welcher Personenkreis angesprochen wird. Das Einstiegsniveau einer Karte darf bei einer
breit angelegten Befragung nicht zu hoch angesetzt werden. Selbst dem Laien muss es
möglich sein sich zu orientieren. Orientierungshilfen können durch die Verwendung von
georeferenzierten Photos gegeben werden. (siehe Abbildung 3-1).
In einer im Weiteren vorgestellten Internetbefragung werden Planquadrate über eine
Stadtkarte gelegt. Die Bürger haben die Möglichkeit, die einzelnen Karrees anzuklicken,
zu bewerten und zu kommentieren. Anhand dieser Bewertung wird für eine abschließenden Zusammenstellung jedem Quadranten ein Intensitätswert zugewiesen. Dieser wird in
eine Farbe umgesetzt und schließlich in die Karte geplottet. Auf diese Weise ist es für die
Planer leicht ersichtlich, an welchen Stellen Handlungsbedarf besteht und welche Stadt-
36
teile Vorbildcharakter haben. Die Kommentare der Bürger zu den jeweiligen Planquadraten werden in einer Datenbank gespeichert, so dass zum Ende des Projektes eine interaktive Karte erstellt werden kann. In dieser Karte können durch Klicks in die einzelnen
Zellen die Kommentare aufgelistet werden. Es wird somit ein Bezug von Kommentaren
zu Objekten in der Karte geschaffen, der vor allem für Planer hilfreich sein kann.
Abbildung 3-1: Web-basierte GIS Karte (Quelle: Al-Kodmany 2001)
Durch die Ergebnisse solcher Umfragen findet eine Kooperation zwischen der Bevölkerung und den Stadtplanern statt. Diese Modell sieht leider nur die Kommunikation zwischen Bürgern und Planern vor. Ein Meinungsaustausch zwischen den einzelnen Bürgern
ist nicht möglich. Ebenso bekommt der Befragte kein direktes Feedback auf seine Stellungnahme. Al-Kodmany sieht aus diesen Gründen eine Erweiterung des Konzeptes vor:
Mit dem Übersenden der Informationen des Bürgers wird eine Feedback-Karte zurückgesendet. Aus dieser Karte soll der aktuelle Status der Befragung abgelesen werden können. Probleme dieses Konzeptes werden in der Anonymität des Systems gesehen: Das
System bietet den Beteiligten die Möglichkeit sich zu frei zu äußern. Beteiligte stehen
somit unter keinem Gruppenzwang und auch nicht unter dem Druck von bestimmten Personen. Jedoch kann nicht gewährleistet werden, dass Personen mehrfach an der Befragung teilnehmen. Das Endergebnis wird dadurch verfälscht, da das Gewicht bestimmter
Einzelmeinungen höher gewertet wird. Ein weiterer Nachteil der Anonymität ist, dass
nicht sichergestellt werden kann, ob die Umfrage repräsentativ ist. Es lässt sich keine
Aussage zur Struktur und Verteilung der teilgenommenen Personenkreise machen.
37
3.1.3 Argumentationskarten – Argumentation Maps
Rinner (1999) befasst sich in seiner Dissertation mit der Verknüpfung von raumbezogenen Diskussionsbeiträgen und deren räumlicher Repräsentation. Argumentationskarten
sind speziell auf Planungsprozesse ausgelegt und sollen bei einer partizipativen Planung
helfen. Das raumbezogene Argument ist das zentrale Element einer Argumentationskarte.
Die Argumente bzw. Kommentare werden mit Objekten in der Karte verknüpft (Greve
und Rinner 1998). Dadurch wird ein direkter Bezug zwischen dem spezifischen Inhalt
der Karte und den Anmerkungen geschaffen. Die Argumente sind für den Betrachter direkt zuzuordnen. Ein Vorteil dieses genauen Raumbezuges liegt in der Assoziation vom
Argument zum Objekt in der Karte. Auf Bürgerversammlungen oder in Newsgroups im
Internet sind räumliche Bezüge oft nur im Wortlaut von Diskussionsbeiträgen enthalten.
Dies sind meistens Straßennamen, Bezeichnungen von Wohnvierteln oder der Name des
Planungsgebietes. Die genaue Zuordnung zu einem Objekt in der Karte fällt oft schwer
(Rinner 1999).
Abbildung 3-2: Argumentationskarte (Quelle: Rinner 2002)
Greve und Rinner (1998) grenzen die notwendigen Karten-Funktionalitäten, die für eine
Argumentationskarte gebraucht werden, klar ab:
-
Navigation (Auffinden und Abrufen von Diskussionsbeiträgen)
-
Partizipation (Beteiligung an der Diskussion und Diskussionseröffnung)
-
Exploration (räumliche Verteilung vorhandener Diskussionsbeiträge)
Es ist zu erkennen, dass die Diskussion und die Unterstützung der Entscheidungsfindung
klar im Vordergrund stehen. Der Nutzer einer Karte soll die Möglichkeit haben, seine
Meinung in einer Karte einzubringen oder auf eine andere Meinung zu antworten. Dabei
38
sollen die Funktionen des Zoomens und des Scrollens es ermöglichen, dass ein Gesamtüberblick erhalten bleibt.
Abbildung 3-2 zeigt den Screenshot eines Prototypen für Argumentationskarten. In diesem System werden Diskussionsbeiträge anhand von Fahnen in einer VRML-Karte angezeigt. Es ist leicht, einen räumlichen Überblick über die Diskussionsthemen zu
bekommen. Ebenso können schnell Schwachstellen in einer Planung gefunden werden.
Eine Anhäufung von mehreren Fahnen in einem Gebiet deutet dementsprechend auf einen Handlungsbedarf in der Planung hin.
Rinner (1998) kategorisiert die online zur Verfügung stehenden Planungskarten in drei
Gruppen:
-
Argumentation Maps (Karten, die dem Nutzer die Topographie des Planungsgeschehens visualisieren und die Mitwirkung zur Diskussion ermöglichen)
-
Annotations Maps (Karten, die dem Nutzer erlauben graphische und textliche Ergänzungen vorzunehmen)
-
Alternative Maps (Karten, die dem qualifizierten Nutzer erlauben inhaltliche Veränderungen vorzunehmen, um Planungsalternativen zu erarbeiten)
Im Bezug auf Argumentationskarten wurde von der GMD in Sankt Augustin ein Prototyp
entworfen. Dieser trägt den Namen Zeno. Zeno ist eine Mediationssystem, das bereits in
Verfahren der Bürgerbeteiligung bei der Stadtplanung eingesetzt wurde.25
Um den hier eingeführten Begriff der Mediation zu erläutern, sei folgendes Beispiel zittiert:
„Zwei Schwestern streiten sich um eine Orange. Jede von beiden möchte die Orange für
sich haben und beharrt auf ihrer Position. Als eine der Schwestern die Orange bereits in
der Mitte durchschneiden will, kommt die Mutter hinzu und fragt jede der Schwestern, wofür sie die Orange gerne hätte. Es stellt sich heraus, dass eine der beiden Saft aus dem
Fruchtfleisch und die andere einen Kuchen mit der Schale machen wollte. Die Orange
wird jetzt natürlich sinnvoll und nicht mittendurch geteilt.“26
Mediation ist somit eine Form der Konfliktlösung. Es ist augenscheinlich, dass Argumentationskarten die Mediation unterstützen. Die Bürger haben die Möglichkeit, sich zu
Planungsverfahren zu äußern. Ihre Belange müssen im Verfahren der Bauleitplanung
berücksichtigt und gerecht miteinander und untereinander abgewägt werden. Mögliche
Konflikte werden somit vermieden. Die Mediation ist ein wichtiger Bestandteil des „col-
25
Näheres hierzu unter: http://forum.esslingen.de/buerger/ - Beispiel der Stadt Esslingen aus dem Jahr
2003 (letzter Zugriff am 8.12.2003).
26
Diese Beispiel wurde der HTML-Seite entnommen, die unter der URL:
http://www.onlinemediation.de/infobereich__mediation/mediation__was_ist_das_/mediation__was_ist_da
s_.html verfügbar ist (letzter Zugriff am 8.12.2003).
39
laborative spatial decision-making“ (CSDM). CSDM steht dabei für die Einbeziehung
der Beteiligten eines Entscheidungsprozesses an der Klärung und Erforschung des Problems und an der Findung und Formulierung der Lösungsalternativen. Wichtig ist, dass
alle Beteiligten den gleichen Zugang zu den Information haben und zudem eine Kommunikation ermöglicht wird (Rinner 1998).
Die neueste Version der Zeno-Anwendung besteht aus mehreren Komponenten und ähnelt einem Forum. Die räumliche Visualisierung der Forumeinträge wird durch einen
Bezug der Kommentare mit der Karte erreicht. Eine GIS Visualisierung ermöglicht Analysen und die räumliche Erforschung des Planungsgebietes (Voss et al. 2003). Die Nutzer
dieser Anwendung können sich leicht einen Überblick über die Diskussionsbeiträge verschaffen. Durch den Bezug zur Karte ist eine eindeutige Zuordnung eines jeden Kommentars zu einzelnen Objekten möglich. Die Software sieht einen Mediator zur
Diskussionführung vor. Dieser soll die Diskussionsthemen überwachen und versuchen
auftretende Konflikte direkt zu lösen.
3.1.4 GroupARC
In den vorherigen Kapiteln wurden Systeme vorgestellt, die eine asynchrone bzw. eine
„different time - different place“ Diskussion ermöglichen. Churcher und Churcher (1996)
stellen ein System vor, das Echtzeit-Diskussionen über räumliche Sachverhalte zulässt.
Diese Anwendung heißt GroupARC und stellt eine spezielle Lösung zum „Computer
Supported Collaborative Work“ (CSCW27) dar. CSCW ist durch die heutige Verteilung
der Firmenstandorte und insbesondere durch die Forderung nach Team- und Gruppenarbeit sehr bedeutend. Insbesondere im Bezug auf die modulare Arbeitsteilung werden kooperative Werkzeuge benötigt, um den einzelnen Beteiligten eine Abstimmung zu
ermöglichen (Churcher und Cerecke 1996). Treffen können sehr ineffizient sein, wenn
die Beteiligten weite Strecken zurückzulegen haben oder die notwendige Räumlichkeiten
nicht zur Verfügung stehen (Churcher und Churcher 1996). CSCW bietet die Möglichkeit virtuelle Treffen durchzuführen.
Wichtig bei einer CSCW-Applikation ist, dass alle Beteiligten der Diskussion die Informationen über die anderen Beteiligten und ihrem Handeln haben. Dazu gehört neben der
gleichen Datengrundlage auch die Kenntnis über die aktuelle geographische Situation
und über die aktuelle Zoomstufe, der anderen Teilnehmer. Dieser Informationsbedarf
resultiert aus den menschlichen Diskussionsformen. In einer Diskussion über eine Karte
wird beispielsweise auf bestimmte Objekte gezeigt oder es werden gewisse Gebiete
durch eine Handbewegung eingegrenzt. Nur wenn die Beteiligten die gleiche Situation
auf dem Bildschirm haben, können sie auch über den gleichen Sachverhalt sprechen. Die
27
CSCW steht für die Computer gestützte kooperative Arbeit über Distanzen hinweg.
40
Software baut deshalb auf der WYSIWIS28-Methode auf. Allerdings sollte es den Teilnehmern einer Diskussion auch möglich, diese Methode auszuschalten, um persönliche
Gedanken in der Karten evaluieren zu können, bevor diese endgültig vorgestellt werden
(Churcher und Churcher 1999).
Abbildung 3-3: GroupARC (Quelle: Churcher and Churcher 1996)
GroupARC ist ein Werkzeug, das Internetbenutzern erlaubt, auf die gleichen Daten zuzugreifen. Dabei können die Teilnehmer die Daten prüfen, begutachten und über den
Sachverhalt diskutieren. Es ist für die Nutzern möglich, Anmerkungen in Form von Skizzen und Texten in die Karte zu schreiben (siehe Abbildung 3-3). Um einen Überblick
über die einzelnen Aktionen der Nutzer zu wahren, wird jedem Teilnehmer an einer Diskussion eine Farbe zugeordnet. Dadurch sind Kartenergänzungen eindeutig. In der GroupARC Lösung wurde darauf geachtet, dass Teilnehmer an der Diskussion weder die
gleiche GIS-Software noch das gleiche Betriebssystem auf ihren Rechnern installiert
haben müssen. Die Software ist plattformunabhängig programmiert. Die Daten werden
über eine ASCII-Schnittstelle von einem Beteiligten in die Anwendung geladen und stehen anschließend allen zur Verfügung. Die Teilnehmer können über die Karte navigieren
und Kartenergänzungen anbringen. Da GroupARC nicht die Fähigkeit besitzt, spezielle
Analysen durchzuführen sollte, wenigstens ein Teilnehmer eine GIS-Software installiert
28
Die Abkürzung steht für „what you see is what I see“.
41
haben. Somit können etwaige kartenbezogene Fragen geklärt werden (Churcher et al.
1997).
Eine Einschränkung der Nutzbarkeit von GroupARC ist dadurch gegeben, dass jeder
Teilnehmer die Software auf seinem PC installiert haben muss. Speziell in Firmen- und
Behördennetzwerken kann dieser Umstand die Teilnahme an Diskussionssitzungen erschweren.
3.1.5 Cooperative Web Maps
Die bisher vorgestellten kooperativen Konzepte tauschten ihre Informationen immer über
einen Server bzw. über ein zu installierendes Programm aus. Kolbe, Steinrücken und
Plümer (2002) stellen ein Konzept vor, das ohne eine clientseitige Installation und ohne
schreibenden Serverzugriff arbeitet. Die Nutzbarkeit eines Systems, das auf diesem Konzept aufbaut, ist sehr viel größer. Es ermöglicht eine spontane und kurzfristige Nutzung
von Internetkarten für kollaborative Zwecke. Zudem werden keine administrativen Serverwartungen des Kartenanbieter gefordert. Die einfachen Zugangsbedingungen erweitern den Nutzerradius um ein Vielfaches. Teilnehmer können an kollaborativen Arbeiten
von jedem beliebigen Internetarbeitsplatz partizipieren.
Kolbe et al. (2002) definieren eine Cooperative Web Map als eine Internetkarte, „die
jedem Internetnutzer zu jeder Zeit den spontanen Austausch raumbezogener Beiträge mit
anderen Nutzern ermöglicht“ (Kolbe et al., 2002, S. 3). In dem Konzept werden die Informationen über die Kommentare und die Karteninformationen im Client beim Nutzer
gespeichert, während die Karte von einem Server aus dem Internet geladen wird (siehe
Abbildung 3-4). Der Client arbeitet mit einem statischen, vom Server bereitgestellten,
und einem dynamischen, vom Client gespeicherten Anteil. Im dynamischen Anteil sind
individuelle georeferenzierte Kommentare, Veränderungen und Löschungen von Kartenobjekten enthalten. Dabei wird ausdrücklich erwähnt, dass eine Bearbeitung der Karte
nur im Client stattfindet und so die Integrität der Kartendaten auf dem Server erhalten
bleibt. Dieses Konzept unterscheidet sich wesentlich von anderen: Der schreibende
Zugriff vom Client auf einen Web-Server wird durch die Aufspaltung der Informationen
vermieden (vergleiche Abbildung 3-5).
Die dynamische Informationen werden durch die Kodierung in der URL persistent.
Durch eine Speicherung der URL als Bookmark oder Lesezeichen wird es ermöglicht,
die Karte in gleicher Form zu einem späteren Zeitpunkt wieder erneut abzurufen. Es wird
zudem ein unkomplizierter Austausch mit anderen Teilnehmern denkbar. Verschiedene
Beteiligte, beispielsweise in einem Planungsverfahren, müssen sich nur gegenseitig ihre
URL zuschicken um über die Kartenergänzungen der anderen informiert zu sein. Eine
Diskussion über räumliche Sachverhalte wird dadurch erreicht.
Zur Realisierung des Konzeptes der Cooperative Web Map, muss eine Auswertung der
URL im Client stattfinden. Beim Aufruf der gespeicherten URL in einem Web-Browser
42
werden die notwendigen Programmstrukturen zur Auswertung vom Server übertragen.
Diese ermöglichen es, die gespeicherten Informationen zu visualisieren, zu editieren und
zu verändern.
Abbildung 3-4: Konzept von Cooperative Web
Abbildung 3-5: Informationsaustausch in ko-
Maps (Quelle: Kolbe et al. 2002)
operativen WebGIS (Quelle: Kolbe et al. 20002)
Das System hat eine kleine Schwachstelle: Während die Änderung der dynamischen Informationen vom Nutzer beeinflussbar ist, werden die statischen Informationen in Form
der Karte vom Kartenprovider gestaltet. Sollte eine Karte fortgeführt werden, ändern sich
inhaltliche Details. Es kann somit passieren, dass die dynamischen Informationen nicht
mehr zur dargestellten Situation in der Karte passen. Ebenso werden die dynamischen
Informationen unbrauchbar, sobald der Server abgeschaltet wird. Ein erneutes Abrufen
der Karte ist dann nicht mehr möglich.
Kolbe et al. (2002) deuten noch auf eine Randbedingung des Konzeptes hin: Die aktuellen Webbrowser begrenzen die maximale Länge einer URL. Sowohl der Internet Explorer als auch Mozilla oder Netscape zeigen dieses Verhalten. Prinzipiell sollte dies
allerdings kein Hindernis sein, da der Internet-Standard RFC 2616 kein Zeichenlimit
vorgibt (Fielding et al. 1999).
Abbildung 3-6 visualisiert die technische Realisierung des Konzeptes. Wie bereits oben
erwähnt, werden die dynamischen Informationen in der URL kodiert. Die Abbildung
skizziert den Ablauf, welcher sich mit dem Aufrufen der URL in einem Web-Browser
ergibt:
1. Der Nutzer fordert die Karte und das Auswerteprogramm an.
2. Im Server werden die Daten aufgearbeitet. Dabei wird die Karte bzw. der Kartenausschnittes für den Nutzer präpariert.
43
3. Die Karte und der Client (inklusive Auswerteprogramm und Bearbeitungsroutinen) werden zum Web-Browser übertragen.
4. Das Auswerteprogramm ergänzt bzw. verändert das übertragene Kartenbild.
Abbildung 3-6: Visualisierungsablauf (Quelle: Kolbe et al. 2002)
In diesem Kapitel wird deutlich, wie das Konzept eine asynchrone kooperative Arbeit
ermöglicht. Die dynamischen Informationen können durch die URL verschickt oder für
persönliche Zwecke als Bookmark zwischengespeichert werden. Eine Implementierung
beispielsweise in eine andere Internetseite ist ebenso denkbar wie die Publikation in einen Forum.
Im nächsten Kapitel wird das Internetportal des Kommunalverbandes Ruhrgebiet (KVR)
vorgestellt. Dieser Internetseite liegt das beschriebene Konzept zu Grunde.
3.2 Ruhrtal à la Karte
Ruhrtal à la Karte ist eine interaktive, multimediale Internetseite des Kommunalverbandes Ruhrgebiet (KVR). Auf dieser Seite können kostenlos Internetkarten des Ruhrgebie29
tes genutzt werden. Der Client ist unter der URL http://www.ruhrtal.de
erreichbar. Eine Bildschirmkopie der Seite ist in Abbildung 3-7 dargestellt. Die abrufbaren Karten dieses Portals sind durch multimedialen Ergänzungen zu ergänzen.
Die Seite bietet neben der Kartendarstellung einen Fahrradroutenplaner. Der Nutzer kann
auf vorgegebenen Radwegen Start-, Zwischen- und Endpunkte auswählen und bekommt
eine Route zwischen seinen Zielen errechnet und visualisiert. Die Funktionalität ergänzt
den Client für den Freizeitbedarf.
Des Weiteren existiert eine Kommentierungsfunktion. Der Nutzer kann beispielsweise
seine Fahrradroute mit zusätzlichen Kommentaren ergänzen. Der Client ist dabei nicht
auf Textinformationen beschränkt, sondern bietet auch die Möglichkeit Bilder, die auf
einem Web-Server liegen, in der Karte darzustellen.
29
44
Die Ergänzung der Karten um Kommentare beruht auf dem Konzept der Cooperative
Web Map von Kolbe et al (2002). Die Einstellungen des Nutzers, Kommentare und Fahrradrouten werden in einer URL kodiert. Dadurch ergibt sich die Möglichkeit die Karte zu
einem späteren Zeitpunkt in gleicher Weise erneut abzurufen. Ebenso kann diese URL
anderen Benutzern zur Verfügung gestellt werden. Hierzu bietet sich beispielsweise die
Kommunikation über eine Email an.
Leider ist die Kommentarfunktion im Client auf einen Zoombereich festgelegt. Sobald
der Nutzer in die Karte zoomt, werden die Kommentare nicht weiter dargestellt. Erst
beim Herauszoomen zur alten Kartendarstellung ist es wieder möglich die Kommentare
zu sehen. Die Kommentare sind nur in einem sehr kleinen Maßstab sichtbar. Dadurch
können Nutzer keine detaillierte Kommentierung vornehmen, sondern lediglich ein Gebiet in einer Karte kennzeichnen. Die Anheftung eines Kommentars beispielsweise an
einer bestimmten Straße ist nicht möglich.
Abbildung 3-7: Screenshot Ruhrtal à la Karte
Ein weiteres Manko liegt darin, dass die Kommentare nicht auszudrucken sind. Beim
Aufruf der Druckfunktion wird lediglich das Kartenbild ohne die persönlichen Ergänzungen gedruckt. Kommentare können somit nur auf dem PC verarbeitet werden. Eine
zusätzliche Sicherung durch einen Ausdruck der Karte ist nicht möglich. Sollte ein Provider das Kartenbild verändern, hat dies einen Verlust des originalen Kommentarbezuges
zur Folge.
Vor allem bei großen Bildschirmauflösungen wirkt es störend, dass der Kartenausschnitt
nur in einer bestimmten Pixelgröße visualisiert wird. Eine Veränderung der Kartengröße
ist nicht möglich, dadurch wird der Bildschirm nicht in seinem vollem Umfang ausgenutzt und es wird wertvoller Platz verschenkt. Ebenso ist die Benutzerführung etwas
45
kompliziert angelegt. Dieser Umstand tritt speziell beim Hinzufügen von eigenen Kommentaren hervor. Speziell für Laien scheinen sich hier Zugangsschwierigkeiten aufzubauen. Eine intuitive Bedienung ist nur begrenzt möglich, gerade unerfahrene Benutzer
werden auf die Hilfe-Funktion angewiesen sein.
4 Kooperative interoperable Internetkarten
Kapitel 4
Kooperative interoperable Internetkarten
Die Bereitstellung einer Karte im Internet sollte gut geplant und organisiert sein. Für einen Anbieter besteht bereits im Vorfeld die Notwendigkeit zur Festlegung der Usability
des Produktes. Es muss geklärt werden, welchen Anspruch die Karte hat und mit welchen Mitteln dieser zu realisieren ist. Anhand eines Konzeptes lässt sich erarbeiten, in
welchem Maße Ressourcen genutzt und gebraucht werden. Hierdurch werden Randbedingungen für die Kartennutzung festgelegt. (Kraak 2000)
Die vorherigen Kapitel haben gezeigt, wie Clients zum Abruf von Karten arbeiten und
wo eventuelle Schwachstelle bei der Implementierung liegen. Des Weiteren wurden
Konzepte zur kooperativen Arbeit vorgestellt. Dieses Wissen soll in diesem Kapitel eingesetzt werden, um ein Konzept für das Arbeiten mit interoperablen Karten zu erstellen.
Darüber hinaus werden in diesem Kapitel die Funktionalitäten der prototypischen Umsetzung hergeleitet und beschrieben.
4.1 Zielsetzung
Das Anwendungsfeld einer Karte ist meistens vordefiniert. Karten sind vorwiegend autonom und lassen sich meist nicht mit anderen Internetkarten verknüpfen: Der Nutzer hat
die Möglichkeit, eine Karte der Stadt X abzurufen, aber nicht die Handhabe diese Karte
mit einer Karte der Stadt Y zu kombinieren. So können verschiedene Karten nur nebeneinander stehen, aber nicht ein zusammengehöriges Kartenbild erzeugen.
In den vorangegangenen Kapiteln wurde ein Konzept der OGC vorgestellt, das es ermöglicht, Karten über eine vordefinierte Schnittstelle im Internet abzurufen. Es wurde gezeigt, wie über die Zusammenstellung von standardisierten Parametern in einer URL ein
Kartenbild von einem Server übertragen wird. Dieser Standard erlaubt es, mehrere Karten von verschiedenen Servern abzurufen und zu kombinieren. Voraussetzung ist die entsprechende Implementierung einer Clientsoftware. Wie aus Internet-Recherchen
ersichtlich ist, werden dem Nutzer immer mehr Karten im WMS Standard zur Verfügung
gestellt. Dies ist auf den Aufbau von regionalen, nationalen und internationalen Geodateninfrastrukturen zurück zu führen.
46
Kapitel 4: Kooperative interoperable Internetkarten
47
Das Abrufen eines Web Map Services ist speziell durch einen Web-Browser sehr aufwändig. Wird der Nutzer nicht von einem Client unterstützt, müssen die Parameter (geographischer Ausschnitt, räumliches Bezugssystem, Layer, Kartengröße etc.) manuell
zusammengestellt werden, um eine Karte abzurufen. Der Client hingegen ist in der Lage
diese Parameterzusammenstellung zu automatisieren.
Speziell die Realisierung von Funktionen wie Zoomen oder Scrollen, sind ohne einen
Client sehr mühsam. Für diese Aufgaben werden neue Koordinatenpaare benötigt, die
aus einem Kartenbild nicht direkt abzulesen sind. Ohne einen Client kann der Nutzer
diese Parameter nur grob abschätzen. Es ist ersichtlich, dass ein komfortables Arbeiten
mit einer Karte nur in einem Client möglich ist. Beispielsweise kann ein Client die Koordinaten von einer Maus in der Karte interpolieren. Dadurch kann im darauf folgenden
Schritt eine neue Karte angefordert werden.
Kapitel 3 hat gezeigt, dass derzeitige kooperative Dienste nur sehr sporadisch für die
spontane ad-hoc Nutzung geeignet sind. Eine Ausnahme bildet hier das Beispiel des
KVR. Nutzer in Firmen- und Behördennetzwerken dürfen meistens aus administrativen
Gründen keine Programme oder PlugIns installieren. Hierdurch werden Zugangsvoraussetzungen zu einigen kooperativen Diensten nicht erfüllbar. Die Folge ist ein Ausschluss
dieses Benutzerkreises.
Der von einigen kooperativen Systemen geforderte schreibende Zugriff auf einen Server
(vergleiche Abbildung 3-5) ist ein großes Problem. Da nicht jeder Benutzer in unbegrenztem Maße auf einen Server zugreifen soll, ist eine Benutzer- und Gruppenverwaltung erforderlich. Dieser administrative Aufwand zieht Kosten nach sich, die einer frei
zur Verfügung stehenden Lösung widersprechen (Kolbe et al. 2002). Weiter ist ungeklärt, wie in einem serverzentrierten System die Haftung für die vom Server verwalteten
Informationen des Nutzers geregelt ist. Wenn beim erneuten Abrufen der Karte alle Karteninformationen (Karten und Kommentare) vom Server zentral zusammengestellt und
übertragen werden, haftet im Regelfall der Serveranbieter für den Inhalt (Strömer 2002).
Dadurch wird die Umsetzung eines serverzentrierten Systems nur schwer möglich sein,
da wohl kein Anbieter für die Kommentare seiner Nutzer haften kann.
Aus der Sicht des Nutzers ist ein serverzentriertes System ebenso problematisch. Die
Seriosität des Serverbetreibers ist nicht immer bereits im Vorfeld bekannt. Es könnten
vertrauliche Informationen und Kommentare eventuell durch unvorhersehbare Sicherheitslücken von Benutzern abgerufen werden, die hierzu gar nicht autorisiert sind. Bei
einem clientseitigen System tritt diese Problem nicht auf. Der Nutzer kann die Informationen selbst verwalten und so beispielsweise per Email an seine gewünschten Diskussionspartner versenden. Die Kontrolle über die Verbreitung seiner erstellten Karte liegt
damit in den Händen des Nutzers.
Aus diesen gewonnenen Erkenntnissen lässt sich das Fazit ziehen, dass eine Lösung anzustreben ist, die auf dem vorgestellten Prinzip der „Cooperative Web Map“ aufbaut
(vergleiche Kapitel 3.1.5). Durch die Kombination dieses Prinzips mit der OGC WMS
48
Spezifikation, kann der Benutzer beliebige Karten aus dem WWW abrufen, kombinieren
und kommentieren.
Ein frei zugänglicher und nutzbarer Client wird nur geschaffen, wenn Zugangshindernisse anderer Systeme berücksichtigt und behoben werden. Das System muss ohne PlugIns
und Installationen im Internet einwandfrei funktionieren. Dadurch ist gewährleistet, dass
eine plattform- und ortsunabhängige Lösung geschaffen wird. Des Weiteren muss das
System benutzerfreundlich und selbsterklärend sein. Nur wenn sich der Nutzer durch den
Client angesprochen fühlt, wird dieser bereit sein das System zu nutzen. Ansonsten werden andere Lösungen gesucht und es wird gegebenenfalls auf diese zurückgegriffen.
Anzustreben ist deshalb eine Lösung, die es dem Nutzer erlaubt, ohne großen Aufwand
seine Wünsche umzusetzen.
Aus diesen Forderungen lässt sich eine Zielvorstellung ableiten: Es ist ein Konzept für
einen Web-Client zu schaffen, das es erlaubt beliebige OGC WMS abzurufen. Im Client
sollen mehrere Karten von verschiedenen Servern kombinierbar sein. Darüber hinaus
muss der Client die Fähigkeit besitzen nutzerspezifische Ergänzungen zur Karte hinzuzufügen. Um diese individuelle Kartenkonfiguration über das Schließen des Web-Browsers
hinaus persistent zu halten, muss das Konzept eine lokale Speicherung vorsehen. Diese
gespeicherten Informationen sollten für kooperative Dienste zwischen verschiedenen
Nutzern austauschbar sein. Dadurch wird es für die Nutzer möglich, über räumliche
Sachverhalte spontan zu diskutieren.
4.2 Konzept
Nachdem im vorherigen Kapitel das Ziel des zu entwickelnden Clients definiert wurde,
soll im Folgenden ein Konzept zur Realisierung dargelegt werden, bevor auf die technische Umsetzung eingegangen wird. Dies ist besonders wichtig, da in Zukunft die Umsetzung eventuell auf anderen Wegen stattfinden kann, das Konzept hingegen
allgemeingültig bleibt.
Das System baut auf standardisierten Internettechniken auf. Hierdurch wird es möglich
das System in beliebigen Browsern und auf beliebiger Hardware zu betreiben.
Ein kooperatives System muss immer den Austausch der Informationen zwischen verschiedenen Beteiligten ermöglichen. Durch die Realisierung mit Internetstandards wird
der Austausch von Informationen zwischen verschiedenen Systemen möglich und erzwingt keinen systembedingten Ausschluss von Beteiligten. Es wird eine asynchrone
Diskussion ermöglicht. Beteiligte können von beliebigen Orten und Systemen an der
Diskussion teilhaben.
Da das Konzept keine Installation oder PlugIns fordert, ist das System auch für Gelegenheitsanwender offen. Zur Anwendung muss keine gesonderte Software heruntergeladen
und installiert werden. Dies ermöglicht auch eine spontane Nutzung, zum Beispiel im
Rahmen einer Freizeitplanung.
49
4.2.1 Mapping im Web-Browser
Um einen einfachen Zugang zum System zu ermöglichen, baut das im weiteren vorgestellte Konzept auf die Implementierung in einem Web-Browser auf. Hierdurch ist gewährleistet, dass Anwender eine bekannte Arbeitsumgebung auf dem PC installiert haben
und nutzen können. Einem Einsatz in Intra- und Internet steht damit nichts entgegen.
Die Umsetzung in einem Browser kann durch die Programmiersprachen Java und JavaScript realisiert werden. Da Microsoft seit der Version 6.0 des Internet Explorers allerdings Java nicht mehr standardmäßig unterstützt und auch andere populäre Browser diese
Programmiersprache nicht ohne ein PlugIn verstehen, bleibt an dieser Stelle nur die Umsetzung in JavaScript. Dadurch wird das System in allen gängigen Browsern einwandfrei
lauffähig. Die Programmiersprache JavaScript wird von allen Systemen und Browsern
unterstützt und bietet dem Benutzer ein komfortables Arbeiten.
Um zu realisieren, dass verschiedene Karten-Server abgerufen werden können, muss das
System auf den OGC WMS Standard aufsetzen. Hierdurch ist es möglich, verschiedene
Kartenbilder zu kombinieren. Unterschiedliche Karten können layerweise übereinander
gelegt werden. Ein Nutzer hat somit die Möglichkeit verschiedenste Inhalte abzurufen
und in einer Karte zu kombinieren.
Die Konzept sieht vor, dass im Web-Browser ein Client geladen wird. Dieser Client
muss zum einen eine komfortable Benutzerführung erlauben und zum anderen ein
Höchstmass an Funktionalität bieten. Eine große Usability kann durch den kombinierten
Einsatz von HTML und JavaScript erreicht werden.
Um einen kooperativen Ansatz im Client zu realisieren, sieht das Konzept vor, dass die
Karten durch den Nutzer um individuelle Informationen ergänzt werden. Für die Ergänzung der Karten wird jeglicher HTML-Text zugelassen. Auf diese Weise können Nutzer
nicht nur reine Textinhalte, sondern auch multimediale Ergänzungen zur Karte hinzufügen. Durch diese Eigenschaft ist es möglich Bilder, Videos, WebCams oder ganze Webseiten zu Objekten in der Karte zu referenzieren. Diese Liste der Kartenerweiterungen ist
noch beliebig gemäß den HTML-Möglichkeiten zu ergänzen.
Wie in Kapitel 4.1 erläutert, soll der schreibende Zugriff auf einen Server vermieden
werden. Dementsprechend werden in Anlehnung an das Konzept von Kolbe et al. (2002)
die Karteninformationen in einen server- und in einen clientseitigen Anteil aufgespalten.
Konkret äußert sich dies darin, dass alle Informationen vom Client gespeichert und verwaltet werden. Die Karten bzw. die Geoinformationen werden von beliebigen Servern
abgerufen. Da die im Client gespeicherten Daten vom Benutzer veränderbar sind, werden
diese im weiteren als dynamische Informationen betitelt. Dynamische Informationen
beinhalten die Server und Layer, die im Client zusammen visualisiert werden. Da das
Abrufen von WMS Karten es auch erlaubt, dass der Nutzer gegebenenfalls. verschiedene
50
Signaturierungen der Kartenobjekte wählen kann30, müssen diese Informationen zusätzlich zu den Layern gespeichert werden. Zusätzlich ist es notwendig, dass das räumliche
Bezugssystem und die Koordinaten, des im Client sichtbaren Kartenausschnittes persistent gehalten werden. Außerdem müssen die individuelle Geoinformationen des Nutzers verwaltet werden: Dies sind im einfachsten Fall georeferenzierte Kommentare, es
können aber auch Bilder oder anderen multimediale Objekte sein.
Web-Browser
Web-Browser
Nutzer A
Nutzer B
Client
Client
Dynamische
Informationen
URL
WMS 1
Karte 1
Dynamische
Informationen
WMS n
.....
Karte n
Abbildung 4-1: Konzeptentwurf Cooperative Map Client
Damit die dynamischen Informationen einer Kartenkonfiguration auch über das Schließen des Browsers hinweg persistent bleiben, müssen diese lokal gespeichert werden. Ebenso ist es für die kooperative Arbeit mit der Karte nötig, dass die dynamischen
Informationen für andere Beteiligte zugänglich gemacht werden.
Für die Verwaltung der Informationen zum erneuten Abruf eines WMS hat die OGC bereits ein Web Map Context Dokument entworfen (Kralidis 2003). Dies ist eine XMLDatei, in der Informationen wie geographischer Ausschnitt, gewähltes räumliches Bezugssystem etc. gespeichert werden können. Zum erneuten Laden einer Karte ist es vorgesehen, diese Datei wieder in den Client einzuspielen (vergleiche Kapitel 2.3.3).
Bedauerlicherweise sieht dieses Dokument keine Speicherung der individuellen Ergänzungen vor. Da zudem die Verwaltung in einer Datei für den Anwender kompliziert erscheint, wird für die Speicherung der dynamischen Informationen eine Ein-Klick-Lösung
bevorzugt. Dies bedeutet, dass der Nutzer die Karte durch einen Klick wieder reproduzieren kann. Die Lösung bietet eine Kodierung aller Informationen in der URL. Das Konzept sieht vor, dass mit dem erneuten Aufrufen der URL die kodierten Parameter im
Client ausgewertet und zu den Karten hinzugefügt werden. Auf welcher Weise diese Kodierung realisiert wird, ist im folgenden Kapitel nachzulesen.
30
so genannte Styles, vergleiche Kapitel 2.2.3.2.
51
Das in diesem Kapitel beschriebene Konzept ist in Abbildung 4-1 schematisch dargestellt. Es ist zu erkennen, wie der Nutzer verschiedene WMS aus einem Client heraus
abruft. Die Karten werden von den WMS Servern in den Client übertragen. Der Client
verwaltet alle Informationen des Benutzers im dynamischen Speicher. Hierzu zählen neben den dargestellten Karteninformationen auch die individuellen Ergänzungen des Nutzer. Diese Informationen können in eine URL kodiert und als Link zu anderen Nutzern
geschickt werden. Dadurch sind diese in der Lage die gleiche Kartenkonfiguration in
ihrem Web-Browser herzustellen.
Diese Form der Informationsverbreitung ermöglicht dem Nutzer die eigene Verwaltung
des Nutzerkreises seiner Kartenkonfigurationen. Eine asynchrone Kommunikation kann
durch das wechselseitige Zusenden der dynamischen Informationen erreicht werden. Im
Gegensatz zu serverzentrierten Lösungen hat der Nutzer somit die Möglichkeit, ohne
administrativen Eingriff vom Client-Anbieter spontan weitere Interessierte einzubeziehen. Die Verbreitung der Informationen liegt somit in der Hand des Benutzers selbst.
Web-Browser
Web-Server
Nutzer A
Client
Servlet
Dynamische
Informationen
Web-Browser
Nutzer B
Client
WMS 1
Dynamische
Informationen
Karte 1
WMS n
..
Karte n
Abbildung 4-2: Servergestützte Konzeptalternative
An dieser Stelle soll ein noch offenes Problem des Konzeptes nicht verschwiegen werden: Der Nutzer ist abhängig von der Konsistenz der Geodaten auf den Servern. Sobald
ein Kartenanbieter seine Daten fortführt oder ändert, kann es passieren, dass die dynamisch gespeicherten Informationen teilweise unbrauchbar werden. Jedoch erhält der Nutzer, dadurch nur eine aktualisierte Karte für seine dynamischen Informationen. Da die
Geodaten sich nicht komplett ändern, ist die weitere Nutzbarkeit der gespeicherten URL
nicht gefährdet. Sollten die Namen der Layer verändert werden, ist die Karte nicht mehr
in gleicher Weise rekonstruierbar. Auf den ersten Blick ist es allerdings ersichtlich, dass
durch eine Anpassung der aktiven Layer im Client die dynamischen Informationen weiter ihre Gültigkeit behalten. Anders sieht es aus, für den Fall, dass ein Kartendienst eingestellt wird. Wenn der Nutzer am Erhalt seiner individuellen Informationen interessiert
ist, muss dieser eine neue Kartengrundlage in Form von einem neuen WMS Server suchen. Nach dem Abrufen der neuen Karten können die alten Informationen unter gewissen Umständen auf dem neuen Datenbestand weiter genutzt werden. Hier ergibt sich ein
52
klarer Vorteil gegenüber dem Konzept der „Cooperative Web Map“: Das Konzept ist
nicht auf einen bestimmten Server angewiesen.
Bevor auf die Kodierung der dynamischen Informationen im Client eingegangen wird,
soll noch einmal ein Vorteil des clientgestützten Konzeptes diskutiert werden. Im vorgestellten Konzept wird beim erneuten Abrufen der Karte die URL im Client ausgewertet.
Hierdurch werden die dynamischen Informationen beim Nutzer analysiert und verarbeitet. Theoretisch ist allerdings auch eine vom Server unterstützte Lösung denkbar. Die
URL könnte so zum Beispiel zu einem Server übertragen werden. Dieser könnten die
dynamischen Informationen auswerten und daraufhin eine Karte zusammenstellen. Abschließend wird die fertige Karte zum Nutzer übertragen (vergleiche Abbildung 4-2).
Diese Lösung wirft allerdings mehrere Probleme auf. Zum einen ist in diesem Fall die
Rechtslage für den Serverbetreiber ungeklärt. Die Daten werden für den Nutzer im Server generiert, damit ist in erster Linie der Serverbetreiber für den Inhalt verantwortlich.
Des Weiteren können durch das Abrufen von Karten Kosten entstehen. Durch das Abrufen der Karten fällt beim Anbieter ein zusätzliches abzurechnendes Datenvolumen an. Im
Gegensatz dazu werden im vorgestellten Konzept die Karten vom Client abgerufen. Der
Nutzer ist für Kosten, die durch die Nutzung entstehen, selbst verantwortlich. Ebenso
werden die dynamischen Informationen erst auf dem Rechner des Clients zur Karten ergänzt.
4.2.2 Persistente Speicherung in der URL
Wie bereits im letzten Kapitel angedeutet, werden die dynamischen Informationen in
Form einer URL persistent gehalten. Hierdurch wird die Transienz eines Web-Browsers
überbrückt.
Der Internet-Standard RFC 2396 (Berners-Lee et al. 1998) definiert den Uniform Resource Locator (URL) wie folgt:
<scheme>://<authority><path>?<query>
Erklärungen:
-
<scheme> bezeichnet das verwendete Protokoll. Im Internet ist dies meist http,
andere Formen sind https, ftp usw.
-
<authority> steht für die Befugnis des Zugriffes auf eine Web-Seite. Diese Authentifizierung ist kein Pflichtbestandteil einer URL, bei öffentlichen Servern
wird dieser Parameter meistens nicht berücksichtigt und kann vernachlässigt werden
-
<path> ist relevant für die Serveradresse (beispielsweise www.ikg.uni-bonn.de),
des Weiteren beinhaltet dieser Parameter den absoluten Pfad und den Dateinamen
der aufzurufenden Datei (beispielsweise geoinformation/index.htm)
-
53
<query> bezeichnet eine Anfrage, es können Parameter mit übergeben werden.
Folgende Trennzeichen sind zur Separation der Parameter reserviert: ";", "/",
"?", ":", "@", "&", "=", "+", "," und "$"
Es ist zu erkennen, dass die dynamischen Informationen im Query-Parameter kodiert
werden müssen. Dieser Parameter ist durch ein Fragezeichen von den anderen Informationen der URL getrennt. Die Auswertung dieses Parameters erfolg, sobald ein Auswertungsprogramm diesen Abschnitt aus der URL abruft. Normalerweise ist der Parameter
dafür gedacht, Servern Informationen zu übermitteln. Dies können zum Beispiel Informationen aus einem Kontakformular sein. Es spricht allerdings nichts dagegen, den Query auch vom Client auswerten zu lassen. Speziell JavaScript sieht hierfür gesonderte
Auswerteroutinen vor.
Durch die Kodierung der dynamischen Informationen in der URL wird eine Ein-KlickLösung des Konzeptes erreicht. Der Nutzer kann durch einen Klick auf die URL erneut
die gespeicherten Kartenkonfiguration abrufen. Durch den Aufruf der URL wird der
Client in den Browser geladen. Dieser interpretiert die Parameter und fordert daraufhin
die passenden WMS-Karten von den Servern an. Zu guter Letzt ist der Client in der Lage, die weiteren Informationen (z.B. Kommentare) zu den Karten zu ergänzen.
Eine Alternative zu dieser Lösung wäre die Kodierung in einem Dokument in Anlehnung
an das OGC Web Map Context Dokument. Diese Lösung bietet allerdings keine einfache
Handhabung für den Nutzer.
An dieser Stelle ist noch auf eine Beschränkung hinzuweisen, die aus den Web-Browsern
resultiert. Es dürfte ersichtlich sein, dass der Query-Parameter auf Grund der Vielzahl
von zu kodierenden Informationen recht lang werden kann. Je mehr Server gleichzeitig
angezeigt werden und je mehr Kommentare ergänzt werden, desto länger wird die URL.
Der Internet-Standard RFC 2616 (Fielding et al. 1999) sieht für die Länge keine Beschränkung vor. Es hat sich allerdings gezeigt, dass die Web-Browser nur eine URL bis
zu einer Länge von 2048 Bytes verarbeiten können. Daraus resultiert eine Einschränkung
für die Anzahl der Kommentare bzw. Server, die ein Nutzer verwalten kann. Praktisch
gesehen wirkt sich diese Einschränkung nur höchst selten aus. Die Länge der URL in den
Browsern lässt es immer noch zu eine Vielzahl von Informationen zu speichern. Ebenso
resultiert aus der durchschnittlichen Lebensdauer einer Web-Map, dass dieser Aspekt in
den Hintergrund tritt.
4.2.3 Gestaltung und Benutzerführung
Die Gestaltung und die Benutzerführung sind von besonderer Prägnanz für die Nutzung
eines Programms. Ein Nutzer wird nur eine Anwendung gebrauchen, wenn diese es erlaubt ohne großen Zeitaufwand ein gewünschte Resultat zu erzeugen. Trifft dies nicht zu
kann es passieren, dass Nutzer zu alternativ vorhandenen Programmen wechseln.
Logo
Buttonbar
Layer
Karte
Abbildung 4-3: Grundstruktur des Clients
54
Textfeld
HTML - Hilfssymbole
Abbildung 4-4: Fensteraufteilung für Kommentareingaben
Vor diesem Hintergrund soll der Client auf bekannte Strukturen aufbauen. Abbildung 4-3
zeigt den typischen Grundaufbau einer Kartenanwendung. Das Fenster ist in vier Hauptkategorien geteilt: Oben links ist meist ein programmspezifisches Logo zu finden. Daran
anschließend folgt oben rechts eine Buttonbar. Dies ist eine Ansammlung von Schaltflächen, die dem Nutzer verschiedene Funktionen zum Arbeiten mit der Karte bieten. Unten
links befindet sich ein Layerfenster. In diesem Fenster werden die Serverinformationen
zu den einzelnen Layern dargestellt. Schlussendlich ist unten rechts ein Kartenfenster zu
finden. Es ist darauf zu achten, dass die Karte im Vordergrund steht.
Abbildung 4-4 zeigt ein Konzept für eine Fenstergliederung für Kommentareingaben.
Das Konzept des Clients sieht vor, dass die Kommentare aus HTML-Text bestehen. Dies
ermöglicht ein breites Spektrum von Kartenergänzungen. HTML hat die Eigenschaft,
nicht besonders benutzerfreundlich zu sein. Ein Nutzer, der sich mit der Sprache nicht
auskennt, wird nicht in der Lage sein, multimediale Anmerkungen einer Karte zu ergänzen. Aus diesem Grunde erhält der Nutzer Eingabehilfen: Neben dem Textfeld existieren
auch Hilfssymbole für Kartenergänzungen. Mit Hilfe dieser Symbole kann der Benutzer
multimediale HTML-Ergänzungen ohne Kenntnis der Sprache zur Karte hinzufügen. Es
ist somit gelungen, die Eingabe vom komplizierten HTML-Texten zu vereinfachen.
4.2.4 Rechtliche Aspekte
Zur Nutzung und Anbietung von Diensten im Internet muss die Rechtslage bereits im
Vorfeld geklärt sein. Da das Internet die Möglichkeit zur Meinungsbildung besitzt, ist es
wichtig festzulegen, wer für publizierte schadhafte Inhalte haftet. Eine gesetzliche Regelung ist im Teledienstgesetz (TDG) und im Mediendienst-Staatsvertrag (MDStV) geschaffen.
Im vorgestellten Konzept werden die dynamischen Informationen (Kommentare, etc) erst
im Client auf dem PC des Nutzers zur Karte hinzugefügt. Die Informationen werden
nicht vom Anbieter des Clients bereitgestellt, sondern sind in einem Link gespeichert.
Dementsprechend sind die Informationen vom Autor des Links und nicht vom Anbieter,
55
auf den verwiesen wird. Letzterer ist lediglich für die Bereitstellung des Mittels zur Umsetzung verantwortlich.
Ein Dienstanbieter muss nicht immer für fremde Inhalte haften, zu denen er nur den Zugang verschafft. Demnach kennt nach Strömer (2002) ein Nutzer, der einen Link setzt, in
aller Regel auch den Inhalt, auf den dadurch verwiesen wird. Folglich muss in diesem
Fall der Autor des Links entsprechend §§ 11 TDG, 5 Abs.2 MDStV auch für fremde Inhalte haften. Ebenso haftet der Autor des Links auch dann für fremde Inhalte, wenn dem
Verweis ein wirtschaftliches oder sonstiges Interesse zu Grunde liegt.
Speziell im beschriebenen Konzept, in dem die Kommentar-Information in dem Link
kodiert und nicht auf einem Server abgelegt sind, haftet der Link-Autor für den Inhalt
selbst. Es sind die eigenen Inhalte des Links-Autors, die durch das Aufrufen des Links
angezeigt werden. Eine Regelung ist in den §§ 8 Abs. 1 TDG und 5 Abs. 1 MDStV zu
finden.
Ein weiterer rechtlicher Aspekt betrifft das Copyright einer Karte. Der Client erlaubt es
beliebige WMS abzurufen. Die Nutzung einer Karte unterliegt in der Regel jedoch gewissen Bedingungen. Eine allgemeine Regelung für sämtliche WMS-Karten wird es
nicht geben können. Deshalb wird an dieser Stelle auf die Bestimmungen der Anbieter
verwiesen. Im Allgemeinen können diese im Capabilities-Dokument nachgelesen werden.
Zur Nachvollziehbarkeit sind die hier zitierten Gesetzestexte im Folgenden aufgelistet:
§ 8 TDG: Allgemeine Grundsätze
(1) Diensteanbieter sind für eigene Informationen, die sie zur Nutzung bereithalten, nach den allgemeinen
Gesetzen verantwortlich.
(2) Diensteanbieter im Sinne der §§ 9 bis 11 sind nicht verpflichtet, die von ihnen übermittelten oder gespeicherten Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit
hinweisen. Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben auch im Falle der Nichtverantwortlichkeit des Diensteanbieters nach den §§ 9 bis
11 unberührt. Das Fernmeldegeheimnis nach § 85 des Telekommunikationsgesetzes ist zu wahren.
§ 11 TDG: Speicherung von Informationen
Diensteanbieter sind für fremde Informationen, die sie für einen Nutzer speichern, nicht verantwortlich, sofern
1. sie keine Kenntnis von der rechtswidrigen Handlung oder der Information haben und ihnen im
Falle von Schadensersatzansprüchen auch keine Tatsachen oder Umstände bekannt sind, aus denen
die rechtswidrige Handlung oder die Information offensichtlich wird, oder
2. sie unverzüglich tätig geworden sind, um die Information zu entfernen oder den Zugang zu ihr zu
sperren, sobald sie diese Kenntnis erlangt haben.
Satz 1 findet keine Anwendung, wenn der Nutzer dem Diensteanbieter untersteht oder von ihm beaufsichtigt
wird.
§ 5 MDStV: Herkunftslandprinzip
(1) In der Bundesrepublik Deutschland niedergelassene Diensteanbieter und ihre Mediendienste unterliegen
den Anforderungen des deutschen Rechts auch dann, wenn die Mediendienste in einem anderen Staat innerhalb des Geltungsbereichs der Richtlinie 2000/31/EG des Europäischen Parlaments und des Rates vom 8.
Juni 2000 über bestimmte rechtliche Aspekte der Dienste der Informationsgesellschaft, insbesondere des
elektronischen Geschäftsverkehrs, im Binnenmarkt (ABl. EG Nr. L 178 S. 1) geschäftsmäßig angeboten oder
erbracht werden.
56
(2) Der freie Dienstleistungsverkehr von Mediendiensten, die in der Bundesrepublik Deutschland von
Diensteanbietern geschäftsmäßig angeboten oder erbracht werden, die in einem anderen Staat innerhalb des
Geltungsbereichs der Richtlinie 2000/31/EG niedergelassen sind, wird nicht eingeschränkt. Absatz 5 bleibt
unberührt.
(…)
4.2.5 Probleme durch Web-Techniken
Für die Verwirklichung des Konzeptes sollte es ursprünglich ausreichen, den Client mit
JavaScript umzusetzen. Es hat sich allerdings gezeigt, dass ein Client in der Domain X
nicht auf ein Dokument aus der Domain Y zugreifen darf. Dieses Phänomen nennt sich
„cross-frame scripting and security“31. Dies ist ein Sicherheits-Konzept, das es verbietet,
auf die Inhalte anderer Seiten zuzugreifen. Hierdurch wird die Integrität von Daten und
die Privatsphäre von Informationen gesichert.
Das Sicherheitskonzept ist notwendig, seitdem Web-Browser auf unterschiedliche Fenster und Frames zugreifen können. Gäbe es dieses Konzept nicht, könnten Internetseiten
registrieren, welche Seiten der Nutzer abruft. Diese Informationen liegen in der Privatsphäre des Nutzers und sind nicht dafür bestimmt, dem Inhaber einer Webseite zu dienen. Zudem wäre es ohne dieses Konzept auch möglich, Inhalte fremder Seiten in die
eigene Web-Seite zu integrieren und damit zu stehlen.
Zur Realisierung des Konzeptes ist es allerdings notwendig, auf die Inhalte anderer WebServer zuzugreifen. Der Client braucht zum Abrufen der Karte die Informationen aus
dem Capabilities Dokument der jeweiligen Server.
Web-Browser
Web-Server
domainX
domainX
X
Servlet
X
Client
WMS 1
domain1
WMS n
.....
domain2
Abbildung 4-5: Darstellung des Cross-Domain-Scriptings
31
http://msdn.microsoft.com/library/default.asp?url=/workshop/author/om/xframe_ scripting_security.asp
(zuletzt besucht im Dezember 2003)
57
Zur Lösung dieses Konfliktes ist ein Servlet programmiert worden. Dieses kann durch
den Client die Informationen bekommen, welche Server abgefragt werden sollen. Daraufhin ruft das Servlet die Capabilities ab und wertet diese aus. Abschließend werden die
Informationen in eine HTML-Seite generiert und dem Client übertragen. Hierdurch befinden sich die Informationen aus den Capabilities in der eigenen Domain und JavaScript
kann problemlos auf diese zugreifen (siehe Abbildung 4-5).
Durch diese Lösung ergibt sich ein Vorteil für die Programmierung: In JavaScript ist es
sehr aufwändig und mühsam, XML-Dokumente auszuwerten. Für die Java Programmierung existiert allerdings ein Java-Package, das den Zugriff auf XML-Strukturen vereinfacht. Dieses Package heißt Jdom und ist unter http://www.jdom.org frei
verfügbar.
Es existieren zwar auch Scripthilfen für JavaScript (z.B. XML for <Script>
http://www.marzhill.mine.nu/xml_db/index.html), allerdings ist die
Auswertung von Dokumenten noch sehr unkomfortabel. Um dieses Script einsetzen zu
können, ist es notwendig, einen Proxy-Server zu installieren. Dieser ermöglicht es, Dokumente aus einer anderen Domain abzurufen und zu interpretieren.
4.3 Umsetzung – Technische Realisierung
In diesem Kapitel soll die technischen Realisierung beschrieben werden. Das Konzept ist
in einem Prototyp verwirklicht worden. Es soll gezeigt werden, dass das Konzept zur
Umsetzung geeignet ist. Dabei wird insbesondere auf die Konzeptschwerpunkte eingegangen.
Der Prototyp ist derzeit unter der Domain: http://wmc.ikg.uni-bonn.de frei
verfügbar. Auf der Webseite werden Beispiel-Szenarien vorgestellt. Zudem ist der Client
auch für kooperative Zwecke spontan einsetzbar.
Im Weiteren wird als erstes auf die Implementierung des Prototyps eingegangen. Anschließend werden einige besonders herausragende Funktionen beschrieben.
4.3.1 Implementierung
Im Folgenden wird die Kodierung der dynamischen Informationen in der URL genau
beschrieben. Diese Informationen müssen im Client verarbeitet werden. Schließlich wird
auf Ablaufstrukturen des Clients eingegangen. Das Kapitel endet mit der Lösungsdiskussion zur Findung eines räumlichen Bezugssystems.
Zunächst soll kurz auf die Programmstruktur eingegangen werden. Zur Überwindung der
Probleme der Web-Technologie (siehe Kapitel 4.2.5) ist ein Servlet zum Abrufen der
Capabilities der WMS Server programmiert worden. Somit ist auf dem Web-Server zum
einen der Web-Map Client und zum anderen ein Servlet implementiert (siehe Abbildung
4-6). Die Verbindung eines Apache Tomcat- und eines Apache Web-Servers dient zur
58
Realisierung des Prototypens (nähere Informationen zu den Programmen sind unter
http://www.apache.org zu finden).
wmc.ikg.uniwmc.ikg.uni-bonn.de
Web-Server
Servlet
Web Map
Client
Abbildung 4-6: Web-Server des Prototypens
Durch das Servlet ist es möglich, die notwendigen Informationen zum Abruf einer Karte
von einem WMS Server zum Client zu übertragen. Das Servlet analysiert die Capabilities
des Servers. Nach der Auswertung wird ein HTML-Dokument erstellt, das zum Client
übertragen wird.
4.3.1.1 Kodierung der URL
Kapitel 4.2.2 hat die Grundlagen für die Informationskodierung gelegt. Zur Umsetzung
wird im ersten Schritt zusammengefasst, was benötigt wird, um eine Karte in gleicher
Weise erneut abzurufen:
-
WMS-Server (URL)
-
abgerufene Layer der Server (notwendig, damit beim Neuaufbau die gleichen
Layer aktiv sind)
-
Status des Servers (zur Festlegung, ob der Server auch aktiv ist)
-
Geographischer Ausschnitt mitsamt dem räumlichen Bezugssystem
-
Kommentarinformationen (HTML-Text und Koordinaten)
Auf Grund dieser Zusammenstellung und der Konzeptinformationen lässt sich der Query-Parameter aus der URL in drei Abschnitte unterteilen (siehe Abbildung 4-7): Serverinformationen, geographischer Ausschnitt, Kommentare. Die Abschnittsbezeichnung wird
absichtlich kurz gefasst, um Zeichen in der URL zu sparen.
Die Serverinformationen werden wie folgt kodiert:
s=URL_Server1,aktiver_Layer1,…,aktiverLayerN$
URL_Server2,aktiver_Layer1,…,aktiverLayerN;
Status_Server1,Status_Server2&
Die Serverinformationen starten mit einem „s=“. Hiernach folgen in einer durch Kommata getrennten Liste, die URL des WMS Servers und die aktiven Layer. Ein Layer ist aktiv, sobald er in der Karte abgerufen wird. Sollten noch weitere Server im Client geladen
59
sein, werden diese in gleicher Weise und durch ein Dollarzeichen getrennt angereiht.
Abschließend folgt der Serverstatus. Dieser ist durch ein Semikolon von den restlichen
Parametern getrennt. Dieser legt fest, ob eine Karte des entsprechenden Servers beim
erneuten Aufbau der Seite abgerufen wird. Die Trennung des Status von den Serverinformationen geschieht absichtlich. Dies resultiert daraus, dass der erste Teil der Informationen vom Servlet ausgewertet wird, die Status-Informationen allerdings in JavaScript.
Trennzeichen
http://wmc.ikg.uni-bonn.de?s=...$...;...&b=...&k=...$...
URL des Web-Clients
WMS-Kartenserver und Layer
Geographischer Ausschnitt
Kommentare
Abbildung 4-7: Aufbau der URL des Clients
Der geographische Ausschnitt ist ähnlich zur WMS Spezifikation kodiert worden:
b=srs,minx,miny,maxx,maxy&
Der Parameterabschnitt wird durch ein „b=“ gekennzeichnet. Hiernach folgt der räumliche Ausschnitt in Form des Referenzsystems. Anschließend werden die Koordinaten der
unteren linken und der oberen rechten Ecke angereiht. Die Parameter sind durch Kommata getrennt.
Abschließend werden die Kommentarergänzungen kodiert:
k=Text1,x1,y1$Text2,x2,y2
Diese Parameteraufzählung startet mit „k=“ und ist optional, das heißt ein Link ist auch
ohne diesen Parameter komplett. Der Parameter ist nicht erforderlich, da es mit dem
Client auch möglich ist, Karten abzurufen, die keine individuellen Ergänzungen haben.
Nach dem „k=“ folgen eine HTML-Textinformation und die Koordinaten für die Platzierung des Textes. Die Textinformationen werden in JavaScript „escaped“, d.h. dass alle
nicht zulässigen Zeichen einer URL, wie beispielsweise Leerzeichen, verschlüsselt werden. Beim erneuten Laden des Clients werden diese Informationen dann wieder entschlüsselt und in der Karte platziert.
60
Es hat sich gezeigt, dass die Wahl der Trennzeichen nicht beliebig ist. Einige Trennzeichen werden speziell von einigen Emailprogrammen ignoriert und führen beim erneuten
Aufruf zu Fehlern. Durch die gegenwärtige Kodierung kann allerdings ein fehlerfreies
Arbeiten mit Software wie Mozilla Mail, Outlook XP und Outlook Express erreicht werden.
4.3.1.2 Übersicht der Frames
Entsprechend dem Konzept aus Kapitel 4.2.3 ist die Umsetzung erfolgt. Abbildung 4-8
zeigt einen Screenshot aus dem Client: im oberen Bereich des Fensters befindet sich das
Logo und die Schaltflächen, im unteren ein Layer- und ein Kartenfenster.
Abbildung 4-8: Screenshot des Clients
In der Buttonleiste stehen die Funktionen des Clients. An dieser Stelle sollen die Haupteigenschaften vorgestellt werden (vergleiche Abbildung 4-9). Im Folgenden werden die
Elemente von links nach rechts beschrieben:
Abbildung 4-9: Übersicht über die Buttonbar
-
ZoomIn: Funktion, um näher in die Karte zu zoomen. Das Zoomen kann durch
einen Klick in die Karte oder durch das Aufziehen einer Zoombox geschehen.
61
Beim Aufruf werden jeweils neue Karten von den WMS-Servern angefordert und
die Kommentare neu platziert.
-
ZoomOut: Diese Funktion bewirkt das Gegenteil von ZoomIn. Der geographische
Kartenausschnitt wird verkleinert.
-
NewZenter: Dieser Button ermöglicht ein Paning über die Karte. Die Stelle, die in
einer Karte angeklickt wird, wird die neue Mitte der Karte. Hierdurch lassen sich
zudem Objekte in der Karte zentrieren.
-
ZoomToExtend: Ein Klick auf diesen Button zeigt den maximal darstellbaren
Kartenausschnitt aus allen WMS Servern.
-
NeuerKommentar: Mit diesem Button können neue HTML-Kommentare in eine
Karte geschrieben werden.
-
KommentareBearbeiten: Diese Funktion eröffnet verschiedene Bearbeitungsfunktionen: Zoom zum Kommentar, Text bearbeiten, Kommentare importieren und
Kommentare löschen.
-
SendURL: Dieser Button ermöglicht die persistente Speicherung der Kartenkonfiguration. Es werden Optionen zum Versenden und zum Speichern der URL im
Browser angeboten.
-
Drucken: Funktion, um die aktuelle Karte mit den oder ohne den Kommentaren
zu drucken.
-
Hilfe: Hier werden Hilfen für den Benutzer gegeben. Zudem befindet sich hier
das Impressum der Seite.
-
Optionen: An dieser Stelle können neue Server zur Karte hinzugefügt werden.
Ebenso ist es möglich, Server aus der Karte zu entfernen oder die Reihenfolge der
Server in der Karte zu ändern.
-
ServerInfo: Hier werden dem User einige Details aus dem Capabilities Dokument
des Servers präsentiert. Zudem wird die URL der aktuellen WMS Karte gezeigt.
Durch die Anlehnung an die Struktur anderer Clients, die einen weiten Bekanntheitsgrad
besitzen, ist es gelungen, eine intuitive Bedienung zu ermöglich.
4.3.1.3 Speicherstruktur im Client
Nachdem die dynamischen Informationen aus der URL ausgewertet worden sind, müssen
diese auch im Client weiterverarbeit werden. Der Client ist nicht nur in der Lage, die
dynamischen Informationen zu visualisieren, sondern kann diese auch bearbeiten, neue
hinzufügen oder gegebenenfalls löschen.
62
Zur Verwaltung der Informationen ist eine Speicherstruktur im Client entwickelt worden.
Der Client verwaltet alle Informationen im HTML-Frameset32. Die Informationen werden durch JavaScript-Speicherstrukturen im Client fortgeführt.
Im Folgenden soll die Speicherstruktur vorgestellt werden. Dieser Struktur liegen die
Anforderungen der dynamischen Informationen zu Grunde.
Client
1
0..*
BoundingBox
ServerInfo
+SRS:String
+minx:double
+miny:double
+maxx:double
+maxy:double
1
MaxBoundingBox
+minx:double
+miny:double
+maxx:double
+maxy:double
{ordered}
+Titel:String
+URL:String
+Version:String
−Abstract:String
+Format:String
+ContactPerson:String
+ContactOrganisation:String
+ContactAdress:String
+ContactCity:String
+ContactEmail:String
−SRS:List
+ScaleHint:boolean
1..*
0..*
{ordered}
Kommentare
+Text:String
+xKoordinate:double
+yKoordinate:double
{ordered}
Layer
+Name:String
+Titel:String
+Status:boolean
Abbildung 4-10: Speicherstruktur im Web-Map-Client
Abbildung 4-10 visualisiert den Aufbau des Informationsspeichers in einem UML33Diagramm. An oberster Stelle steht der Client, dieser besitzt selbst keine Attribute.
Durch Kompositionen sind dem Client verschiedene Informationen zugeordnet. Bei einer
Komposition ist der Teil vom Ganzen existenzabhängig, d. h. in diesem Fall kann es kei-
32
Ein Frameset ist ein HTML-Ordnung für eine Fenstergliederung.
33
UML ist eine Abkürzung für „Unified Modeling Language“.
63
ne Instanzen ohne den Client geben. Dies ist plausibel, wenn man bedenkt, dass es ohne
den Client im Browser auch die Informationen aus den Klassen nicht gibt.
Als erstes besteht ein Client aus einer BoundingBox. Die BoundingBox speichert neben
den aktuellen Karten-Koordinaten auch das angezeigte räumliche Bezugssystem (SRS).
Um zu gewährleisten, das der Benutzer zur maximalen Zoomstufe gelangen kann, muss
der maximal darstellbare Kartenausschnitt im Client verwaltet werden. Hierzu existiert
die Klasse MaxBoundingBox. Eine Abspeicherung des SRS ist nicht notwendig, da die
abzurufenden Karten keine unterschiedlichen Bezugssysteme haben. Das Bezugssystem
ändert sich während der Visualisierung nicht.
Eine weitere Klasse des Clients speichert die Serverinformationen (ServerInfo). Da der
Client sowohl ohne als auch mit mehreren WMS geladen werden kann, können null bis
unendlich viele Instanzen der Klasse existieren. Die Klasse hat mehrere Attribute. Diese
Attribute werden vom Servlet aus dem Capabilities Dokument analysiert und durch den
Layer-Frame im Client gespeichert (vergleiche Kapitel 4.3.1.5). Jeder Server ist in der
Lage, einen oder mehrere Layer darzustellen. Dadurch existiert wenigstens eine weitere
Komposition zu jeder ServerInfo Klasse (Layer). Ein Layer hat entsprechend der WMS
Spezifikation einen Namen und einen Titel. Zudem muss der Status des Layers gespeichert werden. Beide Klasseninstanzen müssen geordnet abgespeichert werden, da die
Reihenfolge der dargestellten Server in der Karte nicht beliebig ist. Die Reihenfolge der
Server und Layer legt die Anzeigepriorität im Client fest.
Der Client ist in der Lage, Karten durch multimediale Ergänzungen zu erweitern. Die
Kommentare sind georeferenziert, daraus folgt, dass neben der Textinformation auch die
Koordinaten für eine Platzierung in der Karte gespeichert werden müssen. Diese Informationen werden in der Kommentar-Klasse geführt. Da die Kommentare entsprechend
ihrer Eintragsreihenfolge gespeichert und in die Karte gezeichnet werden, ist die Reihenfolge der Instanzen mitzuspeichern.
4.3.1.4 Ablauf beim Laden
Abbildung 4-11 zeigt den prinzipiellen Ablauf beim Aufbau der Seite. Es ist zu erkennen, wie der Web-Browser eine Anfrage an den Web-Server schickt (1). Daraufhin wird
der Web Map Client in den Web-Browser übertragen (2). Der Client enthält das Auswerteprogramm für die kodierten Informationen der URL. Ebenso ermöglicht er ein Arbeiten
mit den angeforderten Karten und eine Bearbeitung der Kommentarinformationen. Ist der
Client übertragen, wertet dieser die URL aus. Daraufhin wird das Servlet angewiesen,
eine HTML Datei mit den Serverinformationen zu generieren (3). Das Servlet fragt hierzu die Capabilities von den WMS Servern ab (4) und wertet diese aus. Die Informationen
werden in das HTML-Dokument geschrieben und dem Client übertragen (5). Hierdurch
ist der Client in der Lage, die Karten von den Servern abzurufen und darzustellen (6).
64
wmc.ikg.uniwmc.ikg.uni-bonn.de
Web-Server
Web-Browser
(Ort B)
(Ort A)
1
2
Web Map
Client
Web Map
Client
3
5
Servlet
4
WMS 1
te
K ar
Cap
abil
ities
(Ort C)
6
WMS n
(Ort n)
. . . . . .
Abbildung 4-11: Ablaufskizze
4.3.1.5 Detailbeschreibung des Ladevorganges
Nachdem das vorherige Kapitel eine Kurz-Übersicht über den Ablauf der Programmstruktur gegeben hat, soll dieses Kapitel den konkreten Ladevorgang des Clients noch
einmal speziell beleuchten. Zur Illustration des Ablaufes ist ein Sequenzdiagramm erstellt worden (siehe Abbildung 4-12). Ein Sequenzdiagramm ist ein Instrument, um zeitliche und klassenmäßig begrenzte Situationsabläufe darzustellen (Oestereich 2001). Im
erstellten Diagramm wird zwischen http- und JavaScript-Aufrufen unterschieden. Die
http-Aufrufe haben immer ein Neuladen von Informationen zur Folge.
Das Laden des Clients beginnt mit dem Aufruf der URL in einem Web-Browser. Es wird
das Frameset geladen. Dies wird als Speicher für Informationen genutzt. Diese Informationen können aus beliebigen Frames abgerufen und bearbeitet werden. Nach dem Laden
des Framesets werden die weiteren Frames des Clients aufgerufen, dabei wird dem LogoFrame die URL übergeben.
Als nächstes wertet der Logo-Frame die URL aus. Danach werden die Informationen
über die BoundingBox und evtl. Kommentarinformationen dem Frameset überreicht und
gespeichert. Die dynamischen Informationen über die abzurufenden Server werden anschließend dem Layer-Frame übersandt, und von dort aus wird das Servlet mit diesen
Parametern aufgerufen. Der Aufruf des Servlets aus diesem Frame hat zur Folge, dass
das zurückgelieferte Dokument auch wieder hierher zurückgesendet wird. Das Servlet
wertet die übergebenen Parameter aus und fragt die notwendigen Information (Capabilities) von den Servern ab. Diese Serverinformationen werden von den Servern als XML-
Abbildung 4-12: Sequenzdiagramm des Ladevorganges
Server, Layer,
Kommentare
Statusabfrage
asynchroner Aufruf
Datenspeicher
synchroner Aufruf
Kommentare
Karteninformationen,
Zugriff auf den
http Aufruf
GetMap(s)
(mitte.htm)
Karten
Frame
(1 ... n)
WMS
Server
JavaScript Aufruf
Maps
Capabilities
GetCapabilities
Servlet
erzeugeLegende
(Serverinformationen)
Web-Browser
ServletAufruf (Server)
KarteLaden
(layer.htm)
Layer
Frame
speichern der
Serverinformationen
LayerLaden
(ServerUrl)
(logo.htm)
Logo
Fr a m e
speichern von
Kommentaren, Bbox
LogoLaden(URL)
Erläuterungen:
url()
(index.htm)
Frameset
Szenario: Kartenaufruf durch URL
65
66
Dokument zum Servlet übertragen. Dann werden die Informationen durch Jdom ausgewertet, und es wird eine HTML-Datei erzeugt. Diese Datei wird zum Layer-Frame zurückgeschickt. Im Layer-Frame werden daraufhin die Informationen aus diesem HTMLDokument ausgewertet und ebenfalls im Frameset gespeichert. Der Client enthält nun
alle notwendigen Informationen, um WMS-Karten abzurufen, somit kann der KartenFrame geladen werden. Dies geschieht aus dem Layer-Frame heraus. Der Karten-Frame
fragt beim Laden den Layer-Frame nach den aktiven Servern und Layern der Kartenkonfiguration. Der Layer-Frame fragt daraufhin die notwendigen Informationen aus dem
Speicher des Framesets ab (Titel der Layer, BoundingBox, Kommentare) und liefert die
notwendigen Daten dem Karten-Frame zurück.
Nachdem die Informationen im Karten-Frame sind, kann dieser die unterschiedlichen
WMS abrufen. Anschließend können die Kartenergänzungen in der Karte platziert werden.
Die Karte ist jetzt entsprechend den Informationen aus der URL erneut wieder aufgerufen worden.
4.3.1.6 Festlegung des SRS und der BoundingBox
Die Festlegung des räumlichen Bezugssystems (SRS) und der BoundingBox ist von besonderer Wichtigkeit. Speziell wenn mehrere Karten von verschiedenen WMS-Server
kombiniert werden sollen, ist es wichtig, ein gemeinsames Referenzsystem zu finden.
Nur wenn die Server mindestens ein gemeinsames SRS unterstützen, ist eine Kombination der verschiedenen Karten möglich.
Die Auswertung dieser Information wird im Prototyp vom Servlet realisiert. Hierzu werden die Listen der unterstützten SRS der einzelnen Server einer Java-Methode übergeben. Diese bildet die Schnittmenge aller SRS und bestimmt auf diese Weise die
gemeinsam unterstützten Referenzsysteme. Was eine Schnittmenge ist, wird in
Abbildung 4-13 beispielhaft für drei Server gezeigt. Im dargestellten Beispiel liegen die
gemeinsam unterstützen SRS in der rote Fläche. Um sich aus dieser Menge für ein SRS
zu entscheiden, gibt es verschiedene Verfahren: Es ist beispielsweise möglich, Favoritensysteme zu definieren. Das bedeutet, dass die Schnittmenge nach bestimmten SRS durchsucht wird. Im Falle der Existenz werden diese ausgewählt. Diese Methode ist einsetzbar,
wenn ein Client bevorzugt für die Darstellung eines bestimmten Gebietes genutzt werden
soll. Dadurch kann in einem solchen System immer ein optimales SRS gewählt werden,
in dem es wenig Verzerrungen gibt. Ein weiterer Vorteil ergibt sich für die Darstellung
der Kommentare. Da der Prototyp keine Koordinatentransformation vorsieht, sind die
Kommentare immer an ein SRS gebunden. Durch bevorzugte Systemeinstellungen kann
sichergestellt werden, dass Kommentare nicht alleine durch die Umstellung der Serverreihenfolge verloren gehen.
67
Abbildung 4-13: Darstellung der Schnittmenge dreier WMS Server
Ebenso ist es auch denkbar, immer das erste Element aus der Liste auszuwählen, um sich
für ein SRS zu entscheiden.
Wenn das SRS festgelegt ist, muss noch die zugehörige BoundingBox errechnet werden.
Hierzu ist ebenfalls eine Java-Methode implementiert worden. Dieser Methode werden
die BoundingBox Koordinaten der ausgewählten SRS aller WMS Server übergeben.
Hieraus werden die maximale untere linke Koordinate und die maximale obere rechte
Koordinate ermittelt. Dieses Verfahren kann angewendet werden, da die WMS Spezifikation es vorsieht, dass ein WMS-Server die Flächen außerhalb der unterstützten BoundingBox weiß darstellt. Es ist dadurch sichergestellt, dass für die angeforderte
BoundingBox auch eine Karte übertragen wird.
4.3.2 Besonderheiten
Der Client bietet eine Vielzahl von Funktionen. Dieses Kapitel soll genutzt werden, um
einige Besonderheiten vorzustellen und hervorzuheben. Neben den beschriebenen Funktionen bietet der Client die Möglichkeit der Kartenbetrachtung und –evaluation. Der Benutzer kann beliebige WMS in den Client laden. Ebenso können die einzelnen Layer der
Server zur Karte an- bzw. abgeschaltet werden, so dass der Benutzer eine freie Kartenkonfiguration erstellen kann.
Im Gegensatz zu vielen anderen Clients passt sich die dargestellte Kartengröße der Fenstergröße des Web-Browsers an. Hierdurch wird erreicht, dass keine ungenutzten Flächen
auf dem Bildschirm erscheinen.
Ein weiteres Feature des Clients ist die Möglichkeit, jeden WMS durch multimediale
Ergänzungen zu erweitern. Dabei wird kein PlugIn und keine Installation vorausgesetzt.
Jeder Benutzer kann unabhängig vom System und Ort mit dem Client arbeiten. Dieser
Umstand ist durch die konsequente Einhaltung von Standards erreicht worden.
68
4.3.2.1 Verbreitung der URL
Kooperative Systeme benötigen einen Austausch von Informationen zwischen den Beteiligten an einem Verfahren. Nur wenn alle Beteiligten den gleichen Wissensstand haben
und damit den Zugang zu den gleich Informationen, kann ein erfolgreiches Arbeiten ermöglicht werden.
Im Client werden die Informationen über die Kartenkonfiguration und über die Kartenergänzungen in der URL gespeichert. Dadurch sind diese Informationen auch über das
Schließen des Web-Browsers hinweg persistent. Die URL kann auf verschiedene Weise
verwaltet bzw. vervielfältigt werden. Beispielsweise kann die URL im Browser als Favorit gespeichert werden. Ebenso ist es möglich die URL als Link in einem Forum oder in
einer Email zu verbreiten.
Abbildung 4-14 zeigt das Fenster, in dem der Nutzer die URL einer aktuellen Kartenkonfiguration abrufen kann. Durch den Klick auf das Buchsymbol wird die URL als Lesezeichen (Bookmark) im Browser gespeichert. Der Nutzer kann sich ebenso die URL
durch einen Klick auf die Verknüpfung in die Zwischenablage kopieren. Auf diese Weise
ist es möglich, die URL in verschiedenen Schriftstücken zu schreiben und zu verbreiten.
Abbildung 4-14: URL / Link Verbreitung
Weiter bietet sich die Möglichkeit, die URL direkt in eine Email zuschreiben. Bei Kodierung der Informationen ist darauf geachtet worden, dass alle Trennzeichen von den Email-Clients Microsoft Outlook XP, Outlook Express und Mozillas Mail verstanden
werden. Damit wird verhindert, dass Informationen durch falsche Interpretationen von
Programmen verloren gehen.
69
4.3.2.2 HTML Bilder importieren
Das Konzept des Clients sieht vor, dass beliebiger HTML-Text zur Karte hinzugefügt
werden kann. Da nicht jeder Nutzer HTML-Kenntnisse besitzt, sind Eingabehilfen zur
Unterstützung implementiert.
Abbildung 4-15: Import von HTML Bildern
Im Client ist eine beispielhafte Umsetzung für Bilder und Zeilenumbrüche realisiert. Da
die Karten von beliebigen Rechnern erneut abrufbar sind, ist es nur möglich, auch Bilder
in die Karte zu importieren, die selbst im Internet verfügbar sind.
Abbildung 4-15 zeigt wie einfach Bilder beispielsweise aus beliebigen Web-Seiten in
eine Karte ergänzt werden können. Dazu muss der Nutzer als erstes die URL des Bildes
kennen. Im Internet Explorer wird hierfür auf das Bild mit der rechten Maustaste geklickt. Danach wählt man aus dem PopUp-Menu den Punkt Eigenschaften aus. Daraufhin
öffnet sich ein Fenster, in dem die URL des Bildes zu sehen ist. Diese URL kann dazu
verwendet werden, in einem zweiten Schritt die Karte zu ergänzen.
Die Abbildung zeigt, wie ein Bild aus einer Web-Seite in eine Karte importiert wurde.
Diese Funktionalität kann auch dazu verwendet werden, um aktuelle Informationen beispielsweise aus einem Regional-Ticker einem Ort in einer Karte zuzuordnen (siehe Anhang). Auf diese Weise können Leser eines Tickers direkt ein Geschehen mit einem Ort
verbinden.
70
4.3.2.3 Druckmenü
Im Gegensatz zu vielen anderen Web-Map-Clients bietet der Prototyp eine komfortable
Ausdruckfunktion. Der Leser ist in Lage, das aktuelle Kartenbild aus dem Client heraus
zu drucken. Dabei stehen zwei Auflösungsvarianten zur Verfügung.
Ein Web Map Service unterstützt diese Funktionalität der verschiedenen Auflösungen
nicht. Die hohe Auflösung wird durch das Abrufen der Karte mit der doppelten Pixelanzahl in Breite wie Höhe und einer anschließenden Skalierung erreicht. Abbildung 4-16
zeigt die Unterschiede zwischen den Auflösungen. Die Abbildung ist in zwei Teile unterteilt. Die linke Hälfte zeigt die hohe, die Rechte die normale Auflösung der Karte. Die
Steigerung der Auflösung führt zu einer besseren Lesbarkeit der Karte. Speziell für
Stadtkarten kann diese Option wichtig sein: Wie die Abbildung zeigt, sind die Straßennamen unterschiedlich gut zu lesen.
Abbildung 4-16: Auflösungsunterschiede
Neben der Karte können die Kommentare wahlweise mit ausgedruckt werden. Dadurch
wird auch eine Diskussion losgelöst vom Computer möglich. Benutzer können erstellte
Karten ausdrucken und anderen Benutzern präsentieren, die Hemmnisse vor der Computertechnologie haben. Ebenso wird ein kollaboratives Arbeiten ohne Internetzugang unterstützt.
Durch das Ausdrucken einer Karte bekommt der Benutzer eine unabhängige Kopie der
Bildschirmkarte. Sollte ein Server einmal abgeschaltet werden, kann der Benutzer immer
noch auf einen Ausdruck zurückgreifen.
Auf Grund der Web-Technologie kann nur eine Karte von einem Server gedruckt werden. Obwohl die Karten im Client übereinander visualisiert werden, können die WebBrowser keine transparenten Flächen drucken. Transparente Fläche erscheinen beim
Ausdruck weiß, die Karten niedrigerer Anzeigepriorität sind somit nicht im Druck vorhanden.
Im Anhang kann ein Überblick über das Druckresultat gewonnen werden. Es sind verschiedene Kartensituationen dieser Diplomarbeit beigefügt.
71
4.3.2.4 Kommentare importieren
In einer kooperativen Arbeit sind immer mehrere Beteiligte in eine Diskussion eingebunden. Ebenso können im Rahmen einer Arbeitsteilung verschiedene Abschnitte einer Karte bearbeitet werden. Um die Ergebnisse in einer Karte zu visualisieren, müssen die
dynamischen Informationen zusammengespielt werden. Die dynamischen Informationen
werden in eine URL kodiert. Das Zusammenspielen der Informationen bedeutet, dass
zwei oder mehrere URLs kombiniert werden müssen. Der normale Benutzer dürfte damit
überfordert sein.
Abbildung 4-17: Importfunktion des Clients
Vor diesem Hintergrund ist eine Importfunktion erstellt worden (siehe
Abbildung 4-17). Der Benutzer muss einfach die weiteren URLs in das weiße Textfeld
schreiben und kann damit die Informationen kombinieren, ohne selbst die URL zu entschlüsseln.
Für das Zusammenspielen verschiedener URLs gibt es eine Rahmenbedingung: Die
Kommentare müssen im selben SRS vorliegen. Eine Transformation zwischen verschiedenen Kommentaren ist derzeit im Prototyp nicht vorgesehen.
4.3.2.5 Auswertung der Capabilities / URL der Karte
Jeder WMS-Server hat die Fähigkeit der Selbstbeschreibung. Der WMS kann ein Capabilities-Dokument versenden, in dem notwendige Parameter zum Abruf einer Karte
enthalten sind. Dieses Dokument ist im XML Format. Da normale Benutzer Probleme
haben werden, diese Format zu verstehen, besitzt der Client eine Option, um die
wichtigen Metainformationen tabellarisch darzustellen. Hierzu muss der Benutzer nur auf
den Button „ServerInfo“ klicken.
Der im Client visualisierten Karte liegt ein GetMap-Request zu Grunde. Für den Benutzer ist die Zusammenstellung der Parameter zum Abruf der gleichen Karte außerhalb des
Clients sehr aufwändig. Deshalb bietet der Client die Möglichkeit, die URL der aktuellen
Karte anzuzeigen.
72
4.3.3 Offene Fragestellungen
Jede Software stößt gelegentlich an ihre Grenzen. Ebenso gibt es für den Prototypen offene Fragenstellungen, die noch im Folgenden diskutiert werden.
Der Client bietet die Funktionalität, verschiedene WMS-Server abzurufen und anschließend zu kommentieren. Die Kommentare werden georeferenziert in der URL abgespeichert. Wenn neue Server nach dem Kommentieren zur Kartenkonfiguration hinzugefügt
werden, ist es möglich, dass nicht mehr das gleiche SRS unterstützt wird. Dies wiederum
hat zur Folge, dass die Kommentarinformationen verloren gehen: Es können keine
Kommentare aus zwei unterschiedlichen Bezugssysteme übereinandergelegt werden.
Eine Lösung bietet eine Koordinatentransformation, die die Kommentarinformationen in
ein anderes Bezugssystem überführt.
Eine weitere Schwierigkeit ergibt sich, sobald mehrere Informationen in einem sehr kleinen Umkreis liegen: Die Kommentare können sich überdecken (vergleiche Abbildung
4-18). Dieses Problem wird in der Literatur unter dem Stichwort „Schriftplatzierung“
geführt. Im Client kann Abhilfe geschaffen werden, indem man die Informationen manuell durch HTML-Werkzeuge platziert. Durch Umbrüche und Leerzeichen kann unter
Umständen eine überlappungsfreie Textplatzierung realisiert werden. Ein weiterer Lösungsansatz sieht vor, den geographischen Ausschnitt zu verkleinern, dadurch wird die
Karte auf dem Bildschirm größer. Entsprechend steht mehr Platz für die Informationen
zur Verfügung.
Abbildung 4-18: Problem der Schriftplatzierung
5 Anwendungsszenarien
Kapitel 5
Anwendungsszenarien
Produkte sind immer mit gewissen Zielvorstellungen behaftet, jedes Produkt dient einer
Zweckbestimmung. Der Markt oder gewisse Nutzergruppen zeigen einen Bedarf an einem Produkt oder einer Sache, und die Konsequenz hieraus ist die Entwicklung von verschiedenen Artikeln und Programmen. Ebenso ist es möglich, dass Produktideen aus
Problemen entstehen.
In diesem Kapitel werden Anwendungsszenarien vorgestellt, in denen der beschriebene
Prototyp aus Kapitel 4 eingesetzt werden kann. Darüber hinaus sind im Anhang zu dieser
Diplomarbeit Karten aus dem Prototypen abgedruckt. Diese können eine genaue Vorstellung über die Einsatzfähigkeit des Web Map Clients geben.
5.1 Allgemeines
Der Prototyp ist auf verschiedene Weise einzusetzen. Es gibt viele mögliche Anwendungsfelder, dabei sind der Phantasie des Nutzers keine Grenzen gesetzt.
Im einfachsten Fall kann der Client eingesetzt werden, um WMS von beliebigen Servern
abzurufen und zu betrachten. Der Client bietet die Möglichkeit, die Karte zu erforschen
und darüber hinaus die Kartensituation durch die URL abzuspeichern. Dadurch kann zu
beliebigen Zeitpunkten und von beliebigen Orten die Karte erneut und in gleicher Form
abgerufen werden.
Des Weiteren können individuelle Texte und Bilder der Karte zugeordnet werden. Die
Kartographie hat eine wichtige Rolle in raumplanerischen Aufgabenstellungen. Kartographische Ausdrucksmittel helfen immer wieder neue Sacherverhalte darzustellen. Die
Karte dient dabei als Informationsquelle, Analyse- und Planungsgrundlage und als Präsentationsmittel (Gartner 1998). Aus diesen Funktionen entstehen verschiedene Einsatzmöglichkeiten.
Karten haben die Fähigkeit, Ideen und Daten von Planern zu Entscheidungsträgern zu
transferieren. Der Web-Map-Client bietet hier die Möglichkeit, einen Transfer zwischen
den Beteiligten zu verwirklichen. Hierzu müssen die Planer nur ihre Karte als WMS im
Internet oder Intranet bereitstellen.
73
Kapitel 5: Anwendungsszenarien
74
Weiter bietet sich die Möglichkeit der Kommentierung von Sachverhalten. Kommentare
können mit direktem Bezug zu Objekten in der Karte geschrieben und gespeichert werden. Durch ein wechselseitiges Zusenden der URLs kann eine Diskussion über räumliche
Sachverhalte entstehen. Probleme und Schwachstellen einer Planung können beispielsweise erörtert werden.
Der Client kann ebenso einem Sachverständigen bei der Erstellung von Verkehrswertgutachten dienen. Sobald Bodenrichtwertkarten über einen WMS Server abrufbar sind,
können diese mit einer Stadtkarten im Client überlagert werden. Der Gutachter kann
dann den Bodenwert vom Bewertungsobjekt direkt aus der Karte abgreifen. Im weiteren
kann durch die Stadtkarte die nähere Umgebung des Objektes gut erfasst werden. Der
Gutachter kann später die Karte ausdrucken und als Anhang zum Gutachten hinzufügen.
Auf diese Weise hat er die Lage des Objektes dokumentiert.
Weitere Einsatzmöglichkeiten bieten sich für Auftragsdienste von Handwerken, Kundendienstlern oder Kurieren an. Es kann zum Beispiel eine Karte erstellt werden, in der die
Auftragsorte gekennzeichnet sind. Die Angestellten brauchen nur noch die Karte abzurufen und können direkt ihre Arbeitsorte sehen. In der Karte ist eine räumliche Verteilung
der Orte zu den Aufträgen zu erkennen. Dadurch ist eine effiziente Arbeitseinteilung
möglich.
Oft haben Firmen in ihren Webseiten eine Anfahrtsskizze. Diese ist häufig sehr allgemein und abstrakt. Diese Verallgemeinerung resultiert daraus, dass der Kartenleser nicht
mit zu vielen Informationen konfrontiert werden soll. Die Ergänzung einer solchen Karte
durch einen Link zum Cooperative Web Map Client ermöglicht es, den Nutzern bei Bedarf weitere Informationen zu bieten.
5.2 Bauleitplanung der Zukunft?
In einem Planungsverfahren existieren immer mehrere Beteiligte, die untereinander ihre
Ziele abstimmen müssen. Dies sind auf der einen Seite der Bauherr und der Architekt
und auf der anderen Seite die Planungsbehörde und die Bürger bzw. die Träger öffentlicher Belange (TöB). Es kann zu Konflikten kommen, sobald nicht alle die Chance haben,
ihre Meinung einzubringen. Hindernisse können alleine schon durch die Öffnungszeiten
des Planungsbüros auftreten.
Der Client bietet die Chance eine neuartige Beteiligung der verschiedenen Stellen. Die
Beteiligten können jederzeit durch das Internet an die Informationen gelangen. Der Ausdruck ihrer Meinung kann sich in den individuell platzierten Kommentaren widerspiegeln.
Eine Beteiligung könnte in etwa so ablaufen: Die Stadt bringt ihren Planungsentwurf auf
der Basis eines WMS-Servers in das Internet. Die Bürger haben rund um die Uhr und
von jedem beliebigen Ort mit einem Internetanschluss die Möglichkeit, sich mit dem
Plan vertraut zu machen und gegebenenfalls Anmerkungen in die Karte zu schreiben.
75
Sollte es Kritikpunkte zum Planungsinhalt geben, kann der Bürger die URL als Link an
das Planungsbüro schicken. Mitarbeiter des Büros können durch den Abruf des Links die
Anmerkungen des Beteiligten sehen und können hierauf reagieren.
Abbildung 5-1: Mögliche Beteiligungsform
Abbildung 5-1 zeigt den Screenshot eines möglichen Szenarios. Es ist zu erkennen, wie
ein Flächennutzungsplan (FNP) im Client abgerufen worden ist. An eine Stelle in der
Karte wurde eine Anmerkung geschrieben, diese muss von den Planern mit in die Abwägungsentscheidung einfließen, um einen ordnungsgemäßen Ablauf der Planung zu gewährleisten. In der Abbildung ist zu erkennen, wie ein Luftbild mit der FNP-Darstellung
zusammen angezeigt wird. Es ist somit sehr anschaulich, wie sich die Planung auswirken
kann. Eine halbtransparente Darstellung des FNP würde es ermöglichen, die direkten
Auswirkungen der Planung ersichtlich zu machen.
5.3 Von Dir zu mir
Eine weiterer Einsatz des Clients kann im privaten Sektor liegen. Jedem dürfte das geläufig sein, man lädt Besuch ein, doch dieser kennt den Weg nicht. Der Client erlaubt es,
76
schnell und spontan eine Wegbeschreibung zu erstellen. Zur Umsetzung braucht der Nutzer nicht erst nach einer Kartengrundlage suchen, sondern er lädt sich die aktuelle Stadtkarte in den Client, und fängt an den Weg zu kommentieren. Es ist dabei möglich, noch
hilfreiche Tipps, wie beispielsweise „Hier kannst du parken“, mit in die Karte einzubinden. Nachdem die Karte fertig ist, kann der Nutzer die URL der Karte einfach an seinen
Besuch verschicken. Dieser ist nach dem Abrufen in der Lage, entweder in der Karte zu
navigieren um sich einen zusätzlichen Überblick zu verschaffen, oder sie einfach auszudrucken.
Abbildung 5-2: Wegbeschreibung von der Autobahn 565 zum IKG
Abbildung 5-2 zeigt ein Beispiel für eine Wegbeschreibung. Das Beispiel zeigt den Weg
von der Autobahn 565 zum Institut für Kartographie und Geoinformation. In die Wegbeschreibung wurde noch ein Bild des Zielobjekts eingebunden. Dadurch kann das Gebäude schnell in der Realität wieder gefunden werden.
77
5.4 Highlights einer Stadt
Jede Stadt besitzt besondere Gebäude und Plätze. Für die größeren Städte werden im
Handel oft Reiseführer zum Verkauf angeboten. Eine Alternative hierzu sind selbst erstellte Fremdenführer.
Der Client lässt es zu, Plätze, Gebäude und Lokalitäten in einer Karte hervorzuheben und
Meinungen objektbezogen zu speichern. Daneben können Bilder die Karte zusätzlich
illustrieren. Auf diese Weise kann sehr anschaulich ein privater Reiseführer entstehen.
Man kann Orte, die einem besonders gefallen und die man für besonders sehenswert hält,
in einer Karte präsentieren.
Abbildung 5-3: Sehenswürdigkeiten von Bonn
Ebenso kann man sich selber eine Urlaubserinnerung basteln. Die Photos, die man auf
einer Reise gemacht hat, können, wenn sie auf einem Web-Server liegen, in eine Karte
integriert werden. Sie werden mit der Karte referenziert und sind auf diese Weise auch zu
späteren Zeitpunkten einer eindeutigen Position in der Karte zuzuordnen.
Neben diesem Einsatz für private Zwecke, ist auch der Einsatz für den kommerziellen
Tourismus denkbar. Vorgefertigte Links könnten auf einer Homepage einer Stadt ange-
78
boten werden, dadurch können Touristen schon im Vorfeld die Stadt erkunden. Durch die
Übersicht über die einzelnen Sehenswürdigkeiten kann sich ein Nutzer solcher Links auf
eine sehr übersichtliche Weise eine eigene Stadttour planen.
Abbildung 5-3 zeigt einen möglichen Detailausschnitt aus Bonn. In der Karte sind drei
bekannte Gebäude von Bonn eingetragen. Neben der textlichen Dokumentation sind Bilder der Karte zugeordnet worden. Diese ermöglich ein einfaches Auffinden der Lokalitäten in der Wirklichkeit.
6 Fazit und Ausblick
Kapitel 6
Fazit und Ausblick
Karten sind Ausdruck von Beziehungen einzelner Geoinformationen. Sie werden genutzt,
um Orte zu finden, Situationen zu beschreiben und Planungen zu analysieren. Eine Karte
bietet eine räumliche Übersicht über Orte und deren Relation. Immer öfter werden Karten im Internet angeboten. Dies ermöglicht den Zugang für eine breite Masse der
Bevölkerung: Karten können unabhängig von Ort und Zeit abgerufen werden. Kapitel 2
zeigt, wie die Interoperabilität zwischen Kartenanbietern zu systemunabhängigen
Anwendungen führen kann. Die Standardisierung des Abrufes einer Karte über eine
definierte Schnittstelle ermöglicht den Austausch von Informationen zwischen
unterschiedlichen Systemen. In Kapitel 3 werden verschiedene kooperative Systeme vorgestellt. Leider sind diese Systeme entweder nicht für die spontane Nutzung geeignet,
oder auf einen bestimmten Kartenbestand begrenzt.
Ziel dieser Arbeit war es, ein Konzept für einen interoperablen Web-Map-Client zu entwickeln und umzusetzen. Eine wichtige Maßgabe lag darin, StandardInternettechnologien zu benutzen. Dadurch ist erreicht worden, dass der Prototyp in beliebigen Web-Browsern lauffähig ist und zudem ohne die Installation von PlugIns oder
weiteren Anwendungsprogrammen funktioniert. Der Client ist in Anlehnung zu bekannten Oberflächen und Strukturen programmiert, hierdurch wird eine intuitive Bedienung
des Clients geschaffen. Des Weiteren ist der Client in der Lage, beliebige Web Map Services aus dem Internet abzurufen. Dabei können verschiedene Karten von verschiedenen
WMS-Servern kombiniert werden. Hieraus ergeben sich eine Reihe von Vorteilen: Die
Überlagerung von Sachverhalten aus unterschiedlichen Quellen kann den Informationsgehalt der Karte erheblich steigern. Der Nutzer greift immer auf die aktuelle Karteninformationen zu. Sollte diese einmal fortgeführt werden, muss keine neue Kartendatei im
System aufgespielt werden. Es wird immer auf den aktuellsten Bestand zugegriffen, soweit dieser im Internet verfügbar ist.
Ein weiteres Feature des Konzeptes ist die Umsetzung von kooperativen Aspekten in
einer Karte: Karten können durch beliebigen HTML-Text ergänzt werden. Dadurch werden Objekte in der Karte durch individuelle Geoinformationen beschrieben. Durch das
Zulassen von beliebigen HTML-Texten wird eine multimediale Kartenergänzung mög-
79
Kapitel 6: Fazit und Ausblick
80
lich. Der Benutzer kann neben reinen Textinformationen auch Bilder, Videos oder ganze
Web-Seiten zur Karte hinzufügen (siehe Anhang).
Mit dem entwickelten Konzept lässt sich durch einen Klick die gleiche Kartenkonfiguration samt Kommentaren erneut aufzubauen. Die Information können damit über das
Schließen des Web-Browsers hinweg persistent gehalten werden. Die Transienz der
Web-Browser ist damit überwunden. Die Ein-Klick-Lösung wird durch eine Kodierung
der Informationen in der URL erreicht. Diese Lösung ermöglicht eine einfache kooperative Beteiligung anderer. Durch wechselseitiges Zusenden der URL wird eine asynchrone
Diskussion ermöglicht. Damit kann über räumliche Sachverhalte diskutiert werden.
Die Informationskodierung ist durch die Fähigkeit der Web-Browser auf eine maximale
Länge der URL begrenzt (vergleiche Kapitel 4.2.5). Vor dem Hintergrund, dass der
Client insbesondere für die spontane ad-hoc Nutzung geeignet werden kann, ist dieses
Problem zweitrangig. Gerade kurzfristige Mitteilungen haben nicht den Umfang, um das
Limit an Zeichen zu überschreiten. Karten, die speziell für die Freizeitplanung angelegt
werden, haben von der Natur der Sache her keine besonders lange Lebensdauer. Diese
Karten werden oft unter einem speziellen Hintergrund erstellt und treten dabei in den
Rang einer „Wegwerfkarte“. Dies sind Karten, die einem kurzfristigen einmaligen Zweck
dienen, beispielsweise einer Routenbeschreibung.
Das erstellte Konzept lässt noch Freiraum für Ergänzungen. So können Weiterführungen
dahin gehen, Karten durch weitere Dienste zu ergänzen. Im Internet werden neuerdings
sogenannte Points-Of-Interests (POI) von verschiedenen Interessengruppen angeboten.
Dies sind die Koordinaten von verschiedensten Einrichtungen und Objekten in einer
Stadt, beispielsweise die Filialen einer Bank. Eine Fortführung des Clients könnte dahin
gehen, diese POIs in die Karte zu laden. Auf diese Weise könnte ein Benutzer die Karte
durch die Ergänzung seiner Interessensgebiete vervollständigen.
Der Prototyp erlaubt es derzeit noch nicht, die Styleinformationen der WMS-Server zu
nutzen. Es ist allerdings denkbar, den Client um diese Funktion zu erweitern. Zur Umsetzung des Konzeptes war dies jedoch nicht notwendig. Für eine weiterführende Implementierung kann die URL durch einen zusätzlichen Parameter ergänzt werden. Ebenso
müsste das Servlet zur Analyse der Styleinformationen ausgebaut werden. Ebenso ist die
Änderung der vom Server vorgegebenen Layerreihenfolge ist im Prototyp nicht realisiert.
Im Konzept und der Kodierung der URL ist die Reihenfolge allerdings bereits berücksichtigt: Die Layer werden entsprechend ihrer Reihenfolge in der Karte auch in der URL
gelistet. Dadurch kann diese Information zur Reproduktion der Karte abgerufen werden.
In dieser Diplomarbeit wurde ein Konzept der OGC zur Speicherung der Karteninformationen vorgestellt. Die Informationen wurden in ein XML-Dokument (Web Map Context
Dokument) geschrieben. Eine weitere Ausbaustufe des Clients könnte diese Dokumente
– optional zur Kodierung in der URL – erzeugen und analysieren. Dadurch können Kartenkonfigurationen aus anderen Clients importiert werden.
Kapitel 6: Fazit und Ausblick
81
Die vorliegende Arbeit und speziell der implementierte Client zeigen, dass eine frei nutzbare, spontane und kooperative Arbeit mit einer Karte ermöglicht werden kann. Der
Client setzt neue Maßstäbe für die Ergänzung von Karten. Bis jetzt ist mir keine Anwendung bekannt, die es erlaubt mit einer derartigen Leichtigkeit beliebige WMS-Karten
durch individuelle Ergänzungen zu personalisieren. Eine Anwendung für den Client kann
speziell im privaten Sektor gesehen werden. Nutzer können ihrer Freizeitplanung über
den Client einen Raumbezug geben. Speziell Fragestellungen mit einem Ortsbezug werden eindeutig lösbar. Durch die Kodierung der Information und deren Auswertung im
Client ist der Benutzer gelöst von administrativen Vorschriften. Dem Benutzer steht es
selbst zur Wahl, ob er seine Kartenkonfigurationen mit anderen teilen möchte und überdies hinaus wen er mit der Karte ansprechen möchte. Der Nutzerkreis einer individuellen
frei verfügbaren Karte wird vom Ersteller selbst definiert.
Literaturverzeichnis
Al-Kodmany, K.(1999): GIS and the artist: Shaping the image of a neighborhood in participatory environmental design. Position paper, Varenius Workshop on Empower-ment,
Marginalization, and Public Participation GIS, http://www.ncgia.ucsb.edu/varenius
/ppgis/papers/al-kodmany.html (zuletzt besucht im Dezember 2003).
Al-Kodmany, K. (2000): Using Web-Based Technologies and Geographic Information
Systems in Community Planning. Journal of Urban Technology, Vol. 7, No. 1.
Andrae, C. (2003): Jenseits von Web Mapping. GeoBIT 11/2003, Wichmann Verlag.
Asche, H. (1999): Netzbasierte Geographische Informationsverarbeitung – Prinzipien,
Produkte, Perspektiven. Web.Mapping 1: Raumbezogene Infomation und Kommunikation im Internet, Heidelberg.
Averdung, C. (2002): Kartographie V – Bildschirm- und Internetkartographie.
http://www.ikg.uni-bonn.de/Lehre/Karto/Karto_V/Bildschirmkartographie.pdf (zuletzt
besucht im Dezember 2003).
Baier, M. (2002): JavaScript für Einsteiger. 2. Ausgabe, 3. Auflage. KnowWare Verlag,
Osnabrück.
Baier, M. (2002): JavaScript für Fortgeschrittene. 1. Ausgabe, 1. Auflage. KnowWare
Verlag, Osnabrück.
Bühler, K. / Bacharach. S / Reed, C / Kottmann, C. / Heazel, C. / Davidson, J. / Bisher,
Y. / Niedzwiadek, H. / Evans, J. (2002): OpenGIS Reference Model. OpenGIS Consortium Inc., Reference number: OGC 03-040.
Berners-Lee, T. / Fielding, R. / Irvine, U.C. und Masinter, L. (1998): Uniform Resource
Identifiers (URI): Generic Syntax, Internet Society Standard RFC 2396, August 1998.
Churcher, C. und Churcher N. (1999): Realtime Conferencing in GIS. Transactions in
GIS, Vol. 3 No. 1.
Churcher, N. und Churcher C. (1996): GroupARC – A Collaborative Approach to GIS.
Proc. 8th Anual Colloquium of Spatial Information Research Centre, University of Otago.
Churcher, N. / Prachuabmoh, P. / Churcher, C. (1997): Visualisation Techniques for Collaborative GIS Browsers. Proceedings of GeoComputation ’97 & SIRC ’97, University
of Otago, New Zealand.
de La Beaujardière, J. (2001): Web Map Service Implementation Specification. OpenGIS
Consortium Inc., Reference number: OGC 01-068r3.
82
83
de La Beaujardière, J. (2001): Basic Service Model Draft Candidate Implementation
Specification. OpenGIS Consortium Inc., Reference number: 01-022r1.
Dickmann, F. (2001): Web-Mapping und Web-GIS. 1. Auflage, Westermann Verlag,
Braunschweig.
Dickmann, F. (2002): Interaktionserweiterung von Web-Karten mit Hilfe von Skriptsprachen – das Beispiel Javascript. Kartographische Nachrichten, Jahr 52, Heft 1, Februar
2002.
Doyle, A. und Cuthbert, A. (1998): Essential Model of Interactive Portrayal. OpenGIS
Consortium Inc., Project Document 98-061.
Doyle, S. (2003): What did the OpenGIS Consortium ever do for us?. GIS Development,
September 2003.
Fielding, R. / Irvine, U.C. / Gettys, J. / Mogul, J. / Frystyk, H. / Masinter, L. / Leach, P
und Berners-Lee, T. (1999): Hypertext Transfer Protocol – HTTP / 1.1, Internet Society
Standard RFC 2616, June 1999.
Gartner, G. (1998): Kartographie und Internet – Auswirkungen für die moderne Kartographie. Computergestützte Raumplanung - Beiträge zum Symposium CORP ´98, Wien.
Goll, J. / Weiß, C. / Müller, F. (2001): Java als erste Programmiersprache – Vom Einsteiger zum Profi. 3. Auflage, Tebner Verlag, Stuttgart.
Greve, K. und Rinner, C. (1998): Argumentationskarten – GIS-basiertes Planungswerkzeug im WWW. Angewandte Geographische Informationsverarbeitung, Beiträge
zum AGIT-Symposium Salzburg 1998, Wichmann Verlag, Heidelberg.
Guerrero, I. (2002): The OpenGIS Consortium (OGC) and the Web Services Model. Intergraph’s Geospatial World Conference 2002, www.geospatialworld.com/gsw2002/
proceedings2002/files/433.doc (zuletzt besucht im Oktober 2003)
Kolbe, T. H. / Steinrücken, J. / Plümer, L. (2002): Diskutieren wir es an der Karte - Cooperative Web Maps. Tagungsband der 39. Sitzung der Arbeitsgruppe Automation in der
Kartographie AgA 2002 in München. Mitteilungen des Bundesamtes für Kartographie
und Geodäsie, Band 24, Verlag des BKG, Frankfurt am Main, 2003.
Kolbe, T. H. / Steinrücken, J. / Plümer, L. (2003): Cooperative Public Web Maps. International Cartographic Congress ICC 2003 in Durban, South Africa.
Kraak, M.-J. und Brown, A. (2001): Web Cartography, Developments and Prospects.
Taylor and Francis, London
Kralidis, T. / Sonnet, J. / Lansing, J. (2003): Web Map Context Document. OpenGIS
Consortium Inc., Reference number: OGC 03-036r2.
MacEarchren, A. M. (2001): Cartography and GIS: Extending collaborative tools to support virtual teams. Progress in Human Geography, Vol. 25, No. 4.
84
McKee, L. und Kuhn, W. (1997): The OpenGIS Consortium’s Purpose and Technical
Approach. Photogrammetric Week ’97, Wichmann, Heidelberg.
Microsoft: The Microsoft Developer Network – About Cross-Frame Scripting and Security. http://msdn.microsoft.com/library/default.asp?url=/workshop/author/om/xframe_
scripting_security.asp (zuletzt besucht im Dezember 2003).
Münz, S. und Nefzger, W. (1999): HTML 4.0 Handbuch. HTML, JavaScript, DHTML,
Perl. Franzis Verlag.
Münz, S. und Nefzger, W. (2001): SelfHTML 8.0. http://selfhtml.teamone.de (zuletzt
besucht im Dezember 2003).
Oesterreich, B. (2001): Objektorientierte Softwareentwicklung – Analyse und Design mit
der Unified Modeling Language. 4. Auflage, Oldenbourg Verlag, München.
OpenGIS Consortium Inc.: http://www.opengis.org (zuletzt besucht im Dezember 2003).
Peng, Z.-R. und Tsou, M.-H. (2003): InternetGIS. John Wiley & Sons, Inc., Hoboken,
New Jersey.
Rinner, C. (1999): Argumentation Maps: GIS-based discussion support for online planning. Dissertation, GMD Research Series, No. 22.
Rinner, C. (1999): Argumentations Maps. Poster Presentations at COSIT'99,
http://ifgi.uni-muenster.de/~rinner/papers/cosit99.pdf (zuletzt besucht im Dezember
2003)
Rinner, C. (2002): Argumentation Maps as Spatial Decision Support Tools. University of
Western Ontario, London, CA, http://ifgi.uni-muenster.de/~rinner/talks/argumaps-as-sdstool.pdf, de (zuletzt besucht im Oktober 2003).
Siemens AG: Das Siemens Online Lexikon. http://w3.siemens.de/solutionprovider/
_online_lexikon/7/f005477.htm (zuletzt besucht im Dezember 2003)
Strobl, J. (1999): Online-GIS – das WWW als GIS-Plattform. Web.Mapping 1: Raumbezogene Infomation und Kommunikation im Internet, Heidelberg.
Strömer, T. H. (2002): Online-Recht: Rechtsfragen im Internet. 3. Auflage, dpunkt, Verlag, Heidelberg.
Teege, G. und Seuß, R. (2003): Pilotierung von OGC-Spezifikationen in Projekten des
Runden Tisch GIS e.V.. 8. Münchner Fortbildungsseminar Geoinformationssysteme,
München, März 2003.
Anhang
•
Ausdruck eines Capabilities Dokumentes
•
Verschiedene Ausdrucke aus dem Web-Client
o Karte mit der Integration weiterer Informationen aus einer anderen WebSeite
o Kate mit einer Ergänzung aus einem Regional-Ticker
o Karte mit einer Übersichtskarte
o Karte mit dynamischen Informationen (hier: Web-Cam, es wird immer ein
aktuelles Bild des Platzes in der Karte dargestellt)
Seite 1 von 3
<?xml version="1.0" encoding="ISO-8859-1" standalone="no" ?>

<!DOCTYPE WMT_MS_Capabilities (View Source for full doctype...)>


- <Service>

<Name>OGC:WMS</Name>

<Title>'DTK-V_2' Nutzungsbedingungen</Title>

<Abstract>Nutzungsbedingungen: Sämtliche Rechte an diesem Produkt liegen
beim Landesvermessungsamt NRW. Die Nutzung ist bis auf Widerruf
kostenfrei. Der Nutzer muss sich vor jeder Nutzung beim
Landesvermessungsamt NRW identifizieren und seine spezielle Nutzung mit
Angabe des Verwendungszwecks und Umfang der Nutzung anmelden
(Kontaktmöglichkeiten zum Landesvermessungsamt NRW siehe unten). Die
Nutzung ist ausschließlich für Testzwecke und im Rahmen von GDI-Projekten
zulässig; die Nutzung für kommerzielle Anwendungen ist ausdrücklich
ausgeschlossen. Die mittelbare oder unmittelbare Weitergabe der Daten an
Dritte ist auch in Verbindung mit weiteren Daten ohne ausdrückliche
Genehmigung durch das Landesvermessungsamt NRW nicht zulässig. Der
Nutzer ist verpflichtet, einen deutlichen Copyright-Hinweis auf das
Landesvermessungsamt NRW als Dateneigentümer bei Visualisierungen jeder
Art anzubringe</Abstract>
- <!-Top-level web address of service or service provider. See also
OnlineResource
elements under <DCPType>.
-->

- <ContactInformation>
- <ContactPersonPrimary>
<ContactPerson>Peter Haupt</ContactPerson>
<ContactOrganization>Landesvermessungsamt NRW</ContactOrganization>
</ContactPersonPrimary>
<ContactPosition>Fachbereichsleiter Vertrieb</ContactPosition>
- <ContactAddress>
<AddressType />
<Address>Muffendorfer Str. 19-21</Address>
<City>Bonn</City>
<StateOrProvince>NRW</StateOrProvince>
<PostCode>53177</PostCode>
<Country>Germany</Country>
</ContactAddress>
<ContactVoiceTelephone>49 (228) 846 1340</ContactVoiceTelephone>
<ContactFacsimileTelephone>49 (228) 846 1302</ContactFacsimileTelephone>
<ContactElectronicMailAddress>[email protected]</ContactElectronicMailAddress>
</ContactInformation>
<Fees>none</Fees>
<AccessConstraints>none</AccessConstraints>
</Service>
- <Capability>
- <Request>
- <GetCapabilities>
<Format>application/vnd.ogc.wms_xml</Format>
file://C:\Dokumente%20und%20Einstellungen\Administrator\Lokale%20Einstellungen\Temp\DTK10_2-7...
Seite 2 von 3
- <DCPType>
- <HTTP>
- <Get>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://www.geoserver.nrw.de:80/GeoOgcWms1.3/servlet/DTK10_
xlink:type="simple" />
</Get>
- <Post>
</Post>
</HTTP>
</DCPType>
</GetCapabilities>
- <GetMap>
<Format>image/png</Format>
<Format>image/bmp</Format>
<Format>image/jpeg</Format>
<Format>image/tiff</Format>
- <DCPType>
- <HTTP>
- <Get>
</Get>
</HTTP>
</DCPType>
</GetMap>
- <GetFeatureInfo>
<Format>text/html</Format>
<Format>text/plain</Format>
- <DCPType>
- <HTTP>
- <Get>
</Get>
- <Post>
</Post>
</HTTP>
</DCPType>
</GetFeatureInfo>
</Request>
- <Exception>
<Format>application/vnd.ogc.se_xml</Format>
</Exception>
- <Layer queryable="0" opaque="1" noSubsets="0">
<Title>DTK10 (2)</Title>
<SRS>EPSG:31466 EPSG:31462 EPSG:31492 EPSG:31467 EPSG:25831
EPSG:25832 EPSG:25833</SRS>
<LatLonBoundingBox minx="5.8032" miny="50.2977" maxx="7.5578"
maxy="52.3913" />
<BoundingBox SRS="EPSG:31466" minx="2485975.0" miny="5573975.0"
maxx="2606048.0" maxy="5808024.0" />
Seite 3 von 3
maxx="2606048.0" maxy="5808024.0" />
maxx="2606048.0" maxy="5808024.0" />
maxx="3401870.85" maxy="5807859.72" />
<BoundingBox SRS="EPSG:25831" minx="699575.4600000009"
miny="5575924.98" maxx="810016.7800000012" maxy="5814775.86" />
<BoundingBox SRS="EPSG:25832" minx="272305.5700000003"
miny="5577058.84" maxx="401837.0399999991" maxy="5805978.15" />
<BoundingBox SRS="EPSG:25833" minx="-154496.1400000006"
miny="5612745.92" maxx="-6065.420000001788" maxy="5831103.13" />
<ScaleHint min="0.0010" max="13.811" />
- <Layer queryable="1" opaque="1" noSubsets="0">
<Name>DTK10_2:Gesamt</Name>
<Title>Gesamt</Title>
</Layer>
</Layer>
</Capability>
</WMT_MS_Capabilities>
Cooperativer OGC Web WMS Client - Druckenmenu
Seite 1 von 1
Diese Karte wurde mit dem Cooperativen Web Map Client des Instituts für
Kartographie und Geoinformation der Universität Bonn erstellt.
Dieser ist unter der URL: http://wmc.ikg.uni-bonn.de zu erreichen.
Hier
Hier aktuelle
aktuelle
Straßeninformationen
Straßeninformationen
Am
Am Freitag
schränken örtliche
örtliche
Freitag schränken
Nebelfelder
Nebelfelder die
die Sicht
Sicht ein.
ein.
Besonders
Besonders betroffen
betroffen davon
davon sind
sind
die
die Flusstäler.
Flusstäler. Durch
Durch leichten
leichten
Sprühregen,
Sprühregen, am
am Nachmittag
Nachmittag im
im
äußersten
äußersten Norden
Norden auch
auch durch
durch
zeitweiligen
zeitweiligen Regen,
Regen, können
können die
die
Straßen
Straßen zudem
zudem feucht
feucht oder
oder nass
nass
sein.
sein.
mehr...
mehr...
http://wmc.ikg.uni-bonn.de/Druck_frame.htm05.12.2003
Seite 1 von 1
Hier
Hier ereignete
ereignete sich
sich ein
ein tragischer
tragischer
Flugzeugabsturz
Flugzeugabsturz
http://wmc.ikg.uni-bonn.de/Druck_frame.htm 07.12.2003
Seite 1 von 1
Bonn
Bonn
Seite 1 von 1
Livebild
Livebild vom
vom Bonner
Bonner Marktplatz
Marktplatz

Rheinische Friedrich - Wilhelms - Universität Bonn

Transcrição

Documentos relacionados

Netzwerktechnik CHS Villach Mag. Rainer Swatek Dauer: 2

Herzlich willkommen

Truehouse Internet Streaming Installation

Anleitung Argus Vip als Server und Client Getestet mit Argus Vip

MobileCollect-PROFESSIONAL (MCP)

MOBIDAT smart

wms 40 pro vocal - Musikladen Haidinger

Intelligente Antennen-Arrays optimieren 802.11n - Horus-Net

Rechnernetze Referat: eDonkey2000

eDonkey - Informatik in Bildung und Gesellschaft