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

3 Technologien
beispielsweise Geokodierung ohne komplizierte Berechnungen möglich. Demzufolge lassen sich
wirkliche Koordinaten auf einfache Art und Weise extrahieren.
Kartenteile können dynamisch verändert werden, ohne die ganze Darstellung noch mal erzeugen zu
müssen; ein erheblicher Vorteil von Vektor- gegenüber Rastergraphiken.
SVG, beziehungsweise verwandte Technologien, bieten verschiedene Möglichkeiten des
Nachladens von Daten. Das ist entweder durch ein Request mit Hilfe der Scripting Engine des
Browsers, oder Plug-In spezifisch, durch die ASV3 spezifische getURL() Methode möglich.
3.2.3.2 Schwächen
Da SVG nicht speziell für Geoinformation geschaffen wurde, bringt es für kartographische
Anwendungen auch einige Schwächen mit sich.
Das Problem vieler Vektordarstellungen ist, dass diese im kartographischem Kontext
objektunabhängig formatiert sind. Diese Tatsache ist besonders bei Signaturen aus
zusammengesetzten Objekten, wie beispielsweise einer Straße mit Füllung, problematisch. Der
Pfad muss in diesem Fall mindestens zweimal definiert werden (vgl. WINTER A. 2000, S.90/91).
Weiter stellt SVG nur unzureichende Möglichkeiten zur räumlichen Navigation zu Verfügung.
Kompliziertes Scripting ist dabei unabdingbar. Zwar lässt sich Zoomen durch das ZoomAndPan
Attribut unterdrücken. Doch ist dieses nur auf das äußerste SVG Element anwendbar und für einen
kartographischen Viewer mit verschachtelten SVGs nicht hilfreich. Deswegen müssen andere
aufwendige Möglichkeiten gefunden werden, räumliche Navigation für Viewerzwecke zuzulassen.
Zum einen ist räumliche Navigation durch die ASV3 spezifischen Attribute currentScale und
currentTranslate zwar möglich, jedoch lassen sich diese nur auf das äußerste Element einer SVG
Datei anwenden. Eine Standalone SVG Implementierung, die die Skalierung verschachtelter
Elemente erfordert, wird dadurch unmöglich. Bedingte Abhilfe schafft die Einbettung von SVG in
HTML. Hierbei ist jedoch problematisch, dass Scripte in den verschiedenen Namensräumen
miteinander kommunizieren müssen. Diese Tatsache stellt sich in der Praxis als schwierig heraus,
obgleich das SVG-Wiki derartige Möglichkeiten beschreibt (SVG-WIKI 2002,
InterDocumentCommunication). Zum Anderen ist räumliche Navigation durch die Anpassung des
viewBox Attributs denkbar. Um die einzelnen Viewbox Werte beim Skalieren zu berechnen, ist ein
globaler Skalierungsfaktor nötig. Diese Variante lässt eine Standalone Lösung zu. Dabei wird nur
eine SVG Datei geladen, ohne in eine HTML Seite eingebunden zu sein. Der Prototyp zeigt eine
derartige Lösung. Verbesserungen, die auch eine "Level of Details" Implementierung ohne
komplexe Scripte zulassen, sind sehr wünschenswert.
Ein weiteres großes Problem ist die Datensicherheit. Diese kann bei einem textbasiertem Format
gegenwärtig noch nicht vorhanden sein. Dies führt in der Entwicklergemeinde zu einer großen
Barriere bezüglich des SVG Einsatzes. Obwohl besonders trickreiche Anwendungen dem ersten
Anschein nach Einsicht des Quellcodes verhindern, können beispielsweise durch "Sniffer", alle
Daten, die vom Server zum Client übertragen werden nachvollzogen werden. Jedoch ist dieses
Problem dem W3C bekannt und eine Empfehlung zur Ver- und Entschlüsselung von XML Dateien
wurde verabschiedet (vgl. EASTLAKE D. & REAGLE J. 2002). Auch umfangreiche clientseitige
Scriptroutinen können nicht verschleiert werden. Gründe und Gedanken sind bei LEY zu finden
(vgl. LEY J. 2002).
Als weitere Schwäche gelten auch die fehlenden Ausdruckmöglichkeiten von SVG Graphiken. Die
Druckfunktion des Browsers stellt gegenwärtig die einzige Möglichkeit dar, Karten auszudrucken.
Jedoch kann diese nicht als allgemeine Möglichkeit angesehen werden, da dabei immer wieder
Probleme auftreten.
60