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

4 Der Prototyp
Umgang mit SVG, also auch kartographische Mängel des Prototypen. Im Folgenden eine Übersicht
der aufgetretenen Schwierigkeiten.
Zum einen sind allgemeine Faktoren zu nennen, die besonders beim praktischen Einsatz von SVG
auftreten. Gegenwärtig gibt es noch zu wenige Erzeugungs- beziehungsweise Editiermöglichkeiten.
Das macht SVG fast ausschließlich nur für Experten zugänglich. Entwicklungstools mit
grundlegenden Features, wie Javascript Syntaxüberprüfung fehlen. Weiter gibt es noch erheblichen
Nachholbedarf bei der Wahl des User Agent's. Die einzige augenblicklich einsetzbare Viewer
Implementierung, ist Microsoft's Internet Explorer mit installiertem Adobe SVG Viewer 3. Die
Browserabhängigkeit sowie die Installation des mächtigen Plug-In's tragen nicht zur weiten
Verbreitung des Standards bei. Der softwareseitige Zugang fehlt deswegen vielen Anwendern. Ein
weiteres Problem ist die Offenheit des Quellcodes. Die Einsicht des Quellcodes ist vom großer
Bedeutung, da jeder, der die Anwendung startet, darauf Zugriff hat. Besonders bei umfangreichen
clientseitigem Scripting macht sich diese Tatsache negativ bemerkbar. Die "Intelligenz" einer
Anwendung kann von jedem nachvollzogen werden. Auch die Möglichkeit, den erzeugten SVG
Code auf einfache Art und Weise zu interpretieren, stellt sich bei sensiblen Daten als nachteilig
heraus.
Zum anderen treten Probleme kartographischen Ursprungs auf. Bei der automatischen
Kartenerzeugung aus Vektordaten treten schon seit langem Komplikationen auf. Viele dieser sind
tiefgreifender Art und stellen auch Informatiker vor schwierige Aufgaben. Beispielsweise ist die
automatische Platzierung von Schrift noch in fast keiner Anwendung sinnvoll gelöst und daher in
den Karten des Prototypen darauf verzichtet worden. Ein ähnliches Problem ist die Platzierung von
flächentreuen Diagrammen, wobei hier die Berechnung des Referenzpunktes von großer
Bedeutung ist. Im Prototypen kann bei Bundesländern wie Niedersachsen sofort ein Konflikt
erkannt werden. Auch die Darstellung von Bewegung durch gerichtete Banddiagrammen ist in
dessen Anfang- und Endpunkt nicht auf einfache Art und Weise zufriedenstellend zu lösen.
Andere Probleme resultieren aus zu primitiver Realisierung des Prototypen. Diese können aber mit
"einfachen" Mitteln behoben werden.
Zu einen tritt ein Problem bei der Diagrammskalierung auf den verschiedenen Ebenen eines Drill-
Downs auf. Gegenwärtig gibt die Property Bag einen Maximalwert vor, der für einen
Diagrammtypen auf allen Layern gilt. Anhand des globalen Skalierungsfaktors wird aus diesem die
Maximalgröße für die jeweilige Ebene berechnet. Der Darstellungskonflikt entsteht aufgrund
unterschiedlicher Objektdichte auf verschiedenen Layern. Wie Abbildung 54 zeigt, besitzt die
Kartenansicht Brandenburg weniger Landkreise als die Kartenansicht Potsdam-Mittelmark
Gemeinden. Die Diagrammdichte auf Gemeindeebene ist deswegen höher. Demzufolge sind diese
zu groß skaliert. Deswegen sollte für jede Kartenebene die notwendigen Eigenschaften zur
Diagrammgröße in Form einer ebenenspezifischen Property Bag nachgeladen werden.
Zum anderen tritt ein Problem bei der Darstellung der Nachbargebiete auf. Derzeit sind alle Karten
sogenannte Inselkarten, in denen nur die gewünschte Region dargestellt wird. Eine Einbeziehung
der angrenzenden Regionen ist für eine optimiertere räumliche Navigation ratsam. Ein räumlicher
Drill-Across wäre dann auch gegeben.
Weitere Nachlässigkeiten ist das Fehlen einer konkreten Standortkartenimplementierung mit
zugehörigen Events. Beispielsweise könnte eine Karte implementiert werden, die Filialstandorte
anzeigt. Beim Überfahren der zugehöreigen Symbole wird eine Art Filialsteckbrief angezeigt.
Zudem ist eine bessere Identifizierung der Geoobjekte notwendig. Bis jetzt kann man nur erahnen,
welche Gebiete dargestellt werden. Eine derartige Erweiterung kann beispielsweise durch Tool-
Tips gelöst werden.
82