Anforderungen an einen kartographischen Viewer für ... - Carto:net

Weitere Magazine

Empfehlungen

Info

3 Technologien Weiter können kommerzielle (z.B. Oracle + Oracle Spatial, DB2, MS Access) von Opensource Datenbanken (z.B. MySQL, PostgreSQL + PostGIS) unterschieden werden. Datenbanken aus freien Entwicklergemeinden stellen sich als preiswerte Alternativen heraus. Für ein Testsystem sind Datenbanken ohne Raumbezug ausreichend. Die Koordinaten werden bereits in SVG Fragmenten in der Datenbank gespeichert. Diese werden vom Mapserver ausgelesen und an den Client weitergegeben. 3.3.2.2 Sachinformationen Sachdaten werden in relationalen Datenbanken mit Geomarketing- sowie Unternehmensdaten gehalten. Dabei wird auf vorhandene Datenbankensysteme beispielsweise eines Unternehmens zurückgegriffen. Zum Beispiel setzt Business Intelligence multidimensionale Datenbanken ein. Die Anwendungslogik eines entsprechenden Systems greift auf diese zu und verarbeitet sie durch multidimensionale Analysen weiter. 3.3.3 Serverkomponenten Die Serverkomponenten eines WebGIS dienen dazu, auf Anfrage eines Clients die gewünschte Karte zu erstellen und an den Client zurückzugeben. Im Folgenden werden die wichtigsten Serverkomponenten eines für die SVG Ausgabe geeigneten WebGIS beschrieben. 3.3.3.1 Mapserver Die Aufgabe eines Mapservers besteht darin, die geforderten Geodaten bereitzustellen. Als Mapserverimplementierung dient ein Servletcontainer, wie beispielsweise der Apache Tomcat (vgl. APACHE 2002c). Die Anfrage des Clients richtet sich an ein Java Servlet. Dieses ist als Anwendung auf dem Mapserver zu sehen. Dabei selektiert es Daten aus der Geodatenbank und gibt die Informationen in Form von SVG Fragmenten an den Client zurück. Für den Prototypen entsteht beispielsweise folgendes Szenario: Beim Drill-Down Mapping wird der Identifikationsschlüssel des Geoobjektes als Parameter an ein Servlet übergeben. Dieses selektiert die Objekte der neuen Kartenebene aus der Geodatenbank. Der Client erhält die SVG Fragmente und fügt diese dem SVG Baum an. Hinweis: Wird ein serverseitig generiertes SVG an den Client übertragen, sollte dabei immer der MIME Type mitgeschickt werden, da ansonsten Browser Probleme haben, SVG Dateien eindeutig zu identifizieren. Dateitypidentifizierung anhand der Extension funktioniert nur bei Microsoftprodukten (vgl. SVG-WIKI 2002, MimeType). 3.3.3.2 Anwendungsserver Auf einem Anwendungsserver befindet sich die Sachdatenkomponente. Eine konkrete Implementierung wird über Datenbankzugriffe die gewünschten Informationen aggregieren. Anschließend werden durch eine XSL Transformationen die Daten im vom Client geforderten XML Format bereitgestellt. Gegenwärtig ist der Einsatz von Web Services auf dem Anwendungsserver prädestiniert. Diese unterstützen in einem hohen Maße properitäre Webtechnologien. Die Praxis zeigt, dass in Business Intelligence Anwendungen meist mehrere Anwendungsserver zum Einsatz kommen. Es entsteht eine Anwendungslogik die komplexe Analysen durchführen kann. 3.3.3.3 Proxyserver Aufgrund von Sicherheitsrichtlinien des Clients, können weitere Daten nur von einem Server geladen werden. Da mindestens immer zwei Server eingesetzt werden, wird ein transparenter 66
3 Technologien Proxyserver benötigt. Dieser gibt die Anfragen an die verschiedenen Server weiter. Somit ist der Host immer gleich (vgl. YAHOO SVG-DEVELOPERS GROUP 2002, Message 22311). Zudem steigert ein Proxy unter Umständen Systemgeschwindigkeit, da Anfragen gespeichert (umgangssprachlich "gecached" → Cache) und bei Wiederholung aus dem Cache geladen werden. Hinweis: Sind Web- und Applikationsserver auf einem Host, so ist ein Proxyserver nicht zwingend notwendig. 3.3.4 Der Client zur Darstellung Als Client wird der Teil des Systems bezeichnet, der die Anfrage an einen Server stellt. Weiter sorgt er für die Visualisierung der Daten. Je nach dem, welches Darstellungsformat verwendet wird, sind verschiedenen Anforderungen zu stellen. Für das vorliegende Konzept zum visualisieren mit SVG ist dabei folgendes notwendig. Zum einen muss der Client SVG spezifizierte Dateien unterstützen. Zum anderen muss dieser einen ECMA 262 konformen Javascriptinterpreter besitzen. Beim Test des Prototypen wird ein Microsoft Internet Explorer 6 mit ASV3 Plug-In verwendet. Betriebssystem ist Windows 2000. Hinweis: Im Zusammenhang mit der Wahl der Technologie des Clientes wurde auch der Einsatz von Java Applet's in Betracht gezogen (→ Applet). Derartige Tools diskutieren CECCONI in seiner Diplomarbeit (vgl. CECCONI A. 1999), ANDRIENKO & ANDRIENKO im deutschen Forschungsprojekt "descartes" (vgl. ANDRIENKO G. & ANDRIENKO N. 1999) und bezüglich Geomarketing, CORBLEY (vgl. CORBLEY K. 2002). Die vorgestellten Lösungen können in gewisser Weise als Pendants zu diesem Prototypen betrachtet werden; jedoch mit anderer Technik. 3.3.5 Datenübertragung Die Übertragung von Geodaten erfordert schnelle Datenübertragung. Diese Tatsache resultiert aus dem großen räumlichen Informationsgehalt von Karten. Vor allem Datenreduzierung mit akzeptablem Informationsverlust trägt zum schnelleren Laden des Viewers bei. SVG hat zudem den großen Vorteil, nur zusätzlich benötigte Daten nachladen zu müssen. Einmal übertragene Daten, dies gilt auch für Sachdaten, sind solange die Anwendung geöffnet ist verfügbar. Zudem tragen properitäre Netzwerktechnologien dazu bei, die Geschwindigkeit des ganzen Systems zu steigern. Zur Kommunikation zwischen Webserver und Client dient das in der "Netzwelt" übliche HTTP Protokoll. Dieses ist vom W3C spezifiziert und sehr weit verbreitet (vgl. LAFON I. 2001). 67
Seite 1 und 2:
Anforderungen an einen kartographis
Seite 3 und 4:
Inhalt 1 Einleitung................
Seite 5 und 6:
3.1.2.5 Extensible Stylesheet Langu
Seite 7 und 8:
Abbildungsverzeichnis Abbildungsver
Seite 9 und 10:
1 Einleitung 1.1 Motivation und Zie
Seite 11 und 12:
2 Anforderungen an die Thematische
Seite 13 und 14:
2.1.4 Daten für das Geomarketing 2
Seite 15 und 16: 2 Anforderungen an die Thematische
Seite 21 und 22: Abb. 5: Darstellung der verschieden
Seite 27 und 28: 2.2.4.2.1 Ortsbezogene Diagrammkart
Seite 29 und 30: 2.2.4.4 Darstellung von Bewegung un
Seite 33 und 34: 2.2.5.3.6 Banddiagramme 2 Anforderu
Seite 37 und 38: 2.2.5.6.4 Übersichtskarte zur räu
Seite 47 und 48: 3 Technologien 3 Technologien Damit
Seite 49 und 50: 3.1.2.1 Extensible Markup Language
Seite 51 und 52: 3 Technologien in diesem Zusammenha
Seite 53 und 54: 3 Technologien dieses angefügt. Ma
Seite 55 und 56: 3 Technologien jeweils mit m begonn
Seite 57 und 58: 3 Technologien - ECMA 262 Spezifika
Seite 59 und 60: 3 Technologien Attribute, wie beisp
Seite 61 und 62: 3 Technologien Hinweis: Für kartog
Seite 63 und 64: 3 Technologien Auch serverseitig k
Seite 65: Abb. 37: Vereinfachte Systemarchite
Seite 69 und 70: Abb. 38: Die implementierte kartogr
Seite 71 und 72: 4 Der Prototyp gestellt und zur Lau
Seite 73 und 74: Abb. 42: Auszug aus der XML Propert
Seite 75 und 76: Die globale Variable dsc deklariert
Seite 77 und 78: Abb. 48: Das legend Objekt Quelle:
Seite 79 und 80: 4 Der Prototyp Sammlung aller Diagr
Seite 81 und 82: 4.3.3 Gesamtansichten des Prototype
Seite 83 und 84: 4.5 Verbesserungsvorschläge für d
Seite 85 und 86: 5 Zusammenfassung der Arbeit 5 Zusa
Seite 87 und 88: Literaturverzeichnis Literaturverze
Seite 89 und 90: Literaturverzeichnis HAROLD E. 2002
Seite 91 und 92: Literaturverzeichnis SAMLAND W. & H
Alle anzeigen

Anforderungen an einen kartographischen Viewer für ... - Carto:net

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?