Innerhalb des Zend Frameworks werden GData-Features wie Picasa, YouTube oder Kalender automatisiert genutzt. Eine Anbindung für Google Maps gibt es bislang nicht. Im RedSpark Framework, das auf dem Zend Framework basiert, wird diese Lücke jetzt geschlossen. Die RedSpark-GData-Maps wurden in dem Projekt „Stolpersteine online“ erstmals live umgesetzt und werden vielleicht in Zukunft in das Zend Framework übernommen.

Mehr als 33 000 goldfarbene Stolpersteine hat Gunter Demnig in ganz Europa verlegt. Der Kölner Künstler erinnert mit diesem Projekt an die Opfer der NS-Zeit, indem er vor ihrem letzten selbst gewählten Wohnort Pflastersteine aus Messing in den Bürgersteig einlässt. Entstanden ist daraus das größte Holocaust-Mahnmal weltweit. Ein Gesamtverzeichnis über die einzelnen Verlegungsorte existierte bislang nicht. Die Seite www.stolpersteine-online.de bringt das Mahnmal jetzt in die digitale Welt und unternimmt als erste Onlinekarte den Versuch, alle verlegten Steine zu erfassen und durch digital abrufbare Informationen zu erweitern.

Das Projekt „Stolpersteine online“

Als die Hamburger Werbeagentur Jung von Matt im letzten Jahr mit der Idee auf uns zukam, das Projekt „Stolpersteine online“ partnerschaftlich umzusetzen, waren wir sofort begeistert. Neben einer Menge an Ideen gab es wenig vorgegebene Pfade und wir konnten in kreativer und technischer Richtung völlig frei in dieses Projekt starten. Die Ziele sind die digitale Erfassung aller verlegten Stolpersteine, der Ausbau der Informationen zu jedem Stein sowie die Einbindung der Netzgemeinde und vor allem der vielen Helfer, die bereits jetzt an dem Kunstprojekt mitarbeiten oder mitgearbeitet haben. Über die Seite können Namen oder Orte gesucht sowie in Kürze Bilder und Biografien der einzelnen Opfer eingetragen, gepflegt und um weitere Hintergrundinformationen ergänzt werden. So soll die Idee der Stolpersteine vor allem Jugendlichen näher gebracht und zentral zusammengefasst werden.

Technisch gesehen stellt die Plattform damit das erste zentrale Register aller weltweit verlegten Stolpersteine dar und bietet durch die offene Architektur und internationale Ausrichtung eine mögliche Datenbasis für weitere Anwendungen zu den Stolpersteinen. Ein dafür nötiges API ist bereits von Beginn an Teil der Planung gewesen. Zunächst stellt aber die aktuelle Google Map den zentralen Anlaufpunkt auf der Seite dar. Diese Art der Visualisierung vermittelt ein sehr gutes Gefühl über die Größe des Projekts.

Eine individuelle Google Map

Speziell diese hierzu individualisierte Google Map soll in diesem Artikel näher betrachtet werden. Dabei wird jedoch schnell klar, dass eine saubere Anbindung und Verwaltung einer solchen Map am besten mithilfe einer entsprechenden Erweiterung des Zend Frameworks realisiert werden kann. Warum ist das so?

Google bietet zunächst eine sehr einfache Art des Einbaus von Kartenansichten, z. B. für Anfahrtskarten zur eigenen Firma. Hierzu lässt sich unter [1] ein entsprechender Schnipsel JavaScript erstellen, der die Karte auf der eigenen Seite ausgibt. Jedoch sind dies lediglich ein bis zwei („Maps“ und teilweise „HTML“) der möglichen sechs Layer, die im Aufbau individueller Karten genutzt werden können (Abb. 1). Das Layer-Modell dient in diesem Fall zur Veranschaulichung der grundlegenden Struktur einer komplexen Map. Google bietet diesbezüglich keine übergreifende Dokumentation der Ebenen der Karte. So können neben dem Einbau einer einfachen Karte weitere Daten über verschiedene Schnittstellen abgefragt und auf der Karte über eigene Marker angezeigt werden. Zusätzlich erlaubt Google weitreichende optische Anpassungen der Karten, das so genannte „Skinning“, und die Integration der Karten auch in aufwändigen Layouts.

Nicht zuletzt bietet die Karte verschiedenste Interaktionsmöglichkeiten per Java­Script, wie etwas scrollen, zoomen und noch vieles mehr. Um all diese Möglichkeiten zu nutzen und vor allem nicht für jedes Projekt neu schreiben zu müssen, behandelt dieser Artikel den Aufbau einer Maps-Abstraktion analog zu den GData-Services im Zend Framework. Genutzt wird dabei das RedSpark Framework, das ein Applikationsframework auf den Schultern des Zend Framework bietet, es an vielen Stellen erweitert und out of the Box bereits viele Features, wie Backend, CMS, Nutzerverwaltung und vieles mehr mitbringt, ohne dabei die Vorteile der offenen und flexiblen Strukturen des Zend Framework einzuschränken. Aus diesem Grund eignet sich das Zend Framework ausgezeichnet für ein solches Vorhaben. Aber der Reihe nach, zunächst Layer für Layer im Einzelnen und in den folgenden Abschnitten die entsprechende Abstraktion der GData-Klassen.

Die Layer-Architektur

Ganz allgemein kann man sich die individualisierte Map in etwa so vorstellen, dass jeder Layer die spätere Ansicht der Karte um weitere Informationen anreichert. Beginnend mit den Daten über die Karte selbst, bis hin zu optischen Individualisierungen, Markern und natürlich der Integration in die eigene Seite. Eine solche Kombination von Individualisierungen kann man sich über einen Account bei Google auch statisch zusammenstellen, über verschiedene Konfiguratoren anpassen und später per Hashtag-URL (Beispiel unter [2]) quasi als „eigene“ Map veröffentlichen. Abbildung 2 zeigt das Layer-Modell einer Google Map.

Der API Layer

Selbst wenn dieser Layer nicht für alle Anwendungsfälle nötig ist, beginnen wir mit dem zuunterst liegenden API-Layer. Dieser Layer dient dem direkten Zugriff auf die Inhalte der Google Maps. Google bietet diesen Layer in unterschiedlichen Formaten an [3]. Die bevorzugte Zugriffsart ist die Nutzung des „Maps JavaScript API v3“ [4], worüber so gut wie alle Kartenfunktionen gesteuert werden können. Diese Schnittstelle hat darüber hinaus den Vorteil, dass jeder Nutzer seine Anfragen persönlich absetzt und keine zentrale Serverstruktur zur Ermittlung und Abfrage der Daten angeboten werden muss. Bei der Nutzung eines serverseitigen Web-Service-API wäre diese zentrale Struktur nötig, da sich der Server zentral, z. B. zur Abfrage von Ortsinformationen, mit dem Places-API [5] verbindet, die Daten abfragt und an den Client zurückliefert. Google empfiehlt an dieser Stelle im Übrigen ausdrücklich die Verteilung der Zugriffe auf die Clients und die Nutzung des JavaScript-basierten API als Best Practice und hat viele andere Schnittstellen – so zum Beispiel das Flash-API – inzwischen sogar als „deprecated“ markiert.

Ein weiterer entscheidender Vorteil zur Verteilung der Zugriffe sind die Zugriffslimits (siehe dazu Tabelle 1 „Google-API-Limits“), die für die APIs von Google vorgegeben werden. Da die Zugriffe immer nur pro User gezählt werden, hat bei Nutzung der JavaScript-Schnittstelle jeder User die vollen Limits und nicht mehr nur einen einzigen Server, der die Zugriffe für alle Nutzer durchführt. Die Limits sind damit für viele Szenarien zu vernachlässigen, und die Anwendung skaliert an dieser Stelle quasi automatisch.