Im ersten Teil habe ich die Idee des Projektes Zwei Welten vorgestellt und im zweiten Teil wie im Projekt Zwei Welten die Informationen mit Hilfe von XML Technologien extrahiert wurden. In diesem Teil werde ich die drei Hauptanwendungen Datenbank, Server und Client/Webseite vorstellen.

Statische Live-Version des Projektes „Zwei Welten – Berlin damals und heute“.

Die drei Schichten im Projekt Zwei Welten

Zusammenführung der Daten in baseX

Zusammenführung der Daten in baseX

Die Daten wurden in eine baseX XML Datenbank zusammengeführt.

Die Daten werden mit Hilfe der XML Datenbank baseX verwaltet. Ein wichtiger Entscheidungsgrund für baseX im Projekt Zwei Welten war, dass die Datenbank auch einen Kommandozeilenmodus bereitstellt, wodurch mit einem einfachen Befehl XQuery Anfragen an eine XML Datei gestellt werden können, die nicht unter Verwaltung der Datenbank stehen muss.

Dies wird zum Beispiel in der automatisierten Extraktion der Tags aus der XML Datenquelle des Stadtmuseums Berlin eingesetzt.

basex -i <database.xml> -o <output.xml> <queryfile.xq>

Validierung der End- und Zwischenprodukte mit XML Schema

Validierung der End- und Zwischenprodukte mit XML Schema

Alle XML Zwischen- und Endprodukte werden mit selbst definierten XML Schema validiert.

Auch wenn XML Schema hier am Ende der Pipeline zur Erstellung der Datenbank vorgestellt wird, war es die erste Baustelle, die ich im Projekt angegangen bin. Der Hintergrund für diese Entscheidung ist in der Grafik unten dargestellt.

Da wir im Team gleichzeitig in unterschiedlichen Bereichen mit der Entwicklung der Anwendung angefangen haben, war es nötig sich auf ein Datenaustauschformat für die einzelnen Schritte zu verständigen. Mit XML Schema lässt sich aber nicht nur die Struktur einer XML Datei definieren, sondern auch überprüfen (validieren). Dies wurde bei uns mit der Kommandozeilenanwendung xmllint aus dem Paket libxml2-utils umgesetzt. Somit wurden wir sofort auf falsch generiertes XML, unkategorisierte Tags, fehlerhaft extrahiertes HTML oder falsche Geokoordinaten aufmerksam gemacht.

Mit XML Schema 1.1 wäre es möglich gewesen zusätzlich noch assert Überprüfungen auf die Knoten und Attribute durchzuführen. Zugunsten der stabileren und auf Linux Systemen unterstützten Version 1.0 habe ich jedoch darauf verzichtet.

Warum XML Schema?

XML Schema ermöglicht die Dokumentation, Kommunikation und Validierung von XML-Datenstrukturen zwischen Teams.

Python Server als Zwischenschicht

Python Server als Zwischenschicht

Der Python Server diente als Zwischenschicht zwischen Datenbank und Client-Anwendung.

Da sämtliche Teammiglieder zu Beginn des Projektes noch ziemlich unerfahren im Umgang mit XML Technologien waren, wurde zur Sicherheit eine Zwischenschicht mit einem Python Webserver umgesetzt. Dieser sollte folgende Aufgaben übernehmen:

  • Vermittlung zwischen Webclient und Datenbank
  • Templatesystem zur Generierung von Inhalten
  • Skalierung
  • Proxy für Anfragen via REST
  • Vorberechnung gewisser Inhalte, wie zum Beispiel ein Geofence auf Basis der Positionen der dargestellten Gebäude

Gegen Ende hat es sich jedoch herausgestellt, dass die Zwischenschicht nicht unbedingt nötig gewesen wäre. Die Anfragen an die Webservices konnten komplett mit JavaScript umgesetzt werden und die erwartete Datenmenge war weitaus geringer, als erwartet, so dass wir auch keine Performance Probleme hatten. Somit war es mir möglich im Anschluss an das Projekt eine statische Version der Anwendung zu erzeugen, die unter http://zwei-welten.meier-benjamin.de besucht werden kann.

Dynamische Daten via OpenStreetMap, Flickr und Panoramio

Dynamische Daten via OpenStreetMap, Flickr und Panoramio

Weitere Daten wie Kartenmaterial und Bilder wurden mit verschiedenen Plugins nachgeladen.

Eine wichtige Komponente in unserer Webanwendung ist, dass wir aktuelle Daten zu der dargestellten historischen Stadtszene präsentieren. So können sich Besucher einen Eindruck verschaffen, wie es heute an der entsprechenden Stelle aussieht.

Eine Komponente ist eine interaktive zweidimensionale Karte, die an den entsprechenden Positionen der einzelnen Gebäude mit Markern versehen ist. Als Quelle für das Kartenmaterial wird OpenStreetMap mit der JavaScript Anwendung LeafletJS verwendet.

Eine weitere Komponente sind Bilder aus der Umgebung, die zusammen mit der Karte quasi eine dritte Dimension der aktuellen Umgebung zeigen. Hierfür haben wir das API von Panoramio und Flickr angesprochen. Panoramio bietet zur Anfrage von hochwertigen Bildern per Geofence schon ein fertiges JavaScript Widget an, welches lediglich noch konfiguiert werden musste. Das API von Flickr ist etwas komplexer und bot keine für uns passenden Widgets an, weshalb wir ein eigenes JavaScript Widget geschrieben haben, welches unser Ausnutzung des API mehrere ausgewählte Flickr Gruppen nach passenden Bildern absucht.

Auf eine Integration von aktuellen Tweets aus der Umgebung der Stadtansichten haben wir verzichtet. Die mit Ortsdaten versehenen Tweets bestanden hauptsächlich aus Appmeldungen (Instagram, Foursquare, …) oder etwas, was ich hier mal Location Spam nennen möchte (darunter verstehe ich Werbe- oder Spamtweets, die mit interessanten Geodaten versehen wurden). Einen Filter zu entwickeln, der tatsächlich interessante Kommentare von realen Menschen an den entsprechenden Orten findet, hätte den Umfang des Projektes gesprengt.

Die fertige Webanwendung

Sceenshot der Client Anwendung

Die Client-Anwendung mit Tags, sowie Anbindung an OpenStreetMap, Panoramio und Flickr.


Im nächsten Teil gibt es eine Zusammenfassung des Projektes, einen Ausblick und eine Liste der eingesetzten Programme und Technologien.