2015/10/25

Google Cloud Datalab

Google hat ein neues Service in seiner Cloud Platform am Start. Es heißt Google Cloud Datalab, ist noch im Beta-Stadium und setzt auf Jupyter und dem PyData Stack auf. Hier mein erster Eindruck bei einem kurzen Test.

PyData Stack auf Cloud Platform

Das aufsetzen des Datalabs erfolgt automatisiert, dauert aber seine Zeit (rund 10 min lt. Notification). Es wird eigenartigerweise als Google App Engine Anwendung erstellt und nicht, wie man meinen könnte, als Compute Engine Projekt. Standardmäßig läuft es aktuell auf einer n1-standard-1 Maschine (1 Kern, 3.75GB RAM) mit einem 100GB Laufwerk. Weitere Maschinen und Laufwerke können in den Verbund eingehängt werden, wenn mehr Rechenleistung bzw. Speicherkapazität nötig ist. Die Einbindung der Google-eigenen Storage Dienste ist natürlich unkompliziert möglich und auch sinnvoll - neben der Skalierbarkeit der Infrastruktur mEn. der Hauptgrund warum es sich überhaupt nachzudenken lohnt, die Analysen in die Google Cloud auszulagern. Der Preis für das Service ist aktuell (im Beta-Stadium) noch überschaubar. Man zahlt für die im Projekt verwendete Infrastruktur (Instanzen) und Services (zB. BigQuery), das Datalab ansich ist (noch) kostenlos - was sich möglicherweise nach dem Beta-Stadium ändern wird.

Jupyter Notebook: Anomaly Detection Beispiel
Das Interface für das Datalab ist ein Jupyter Notebook (siehe Bild). Die essentiellen Bibliotheken aus dem PyData Stack sind vorinstalliert und müssen nur mehr bei Bedarf importiert werden. Das Notebook kann genauso wie bei einer lokalen Installation benutzt werden. Auch die interaktiven Visualisierungsfähigkeiten, wie man es von lokalen Notebooks kennt, sind in der Cloud auf selben Wege zu realisieren.  Neben bisschen Dokumentation und Tutorials für das Verwenden des Notebooks und Einbinden von Storage Diensten, werden auch einige Beispiele standardmäßig im Home Ordner zur Verfügung gestellt. Das Bild ist beispielsweise aus dem Anomalie-Erkennungs-Beispiel. 

Grundsätzlich ist mMn. das Google Cloud Datalab ein attraktives Angebot, um Datenanalysen und -visualisierungen in der Cloud mit dem PyData Stack durchzuführen, da man sich einiges an Installations- und Netzwerkadministrationsaufwand sparen kann. Interssant wird natürlich wie die Preisgestaltung dann im Alpha-Stadium sein wird. Vor allem für Data Science Teams, die nicht an einem Standort gemeinsam arbeiten, ist das Datalab eine überlegenswerte Möglichkeit. An einem Einsatz im Unternehmen (zumindest wenn es seinen Sitz in der EU hat) ist derzeit aber noch nicht zu denken. Das liegt aber weniger an der bewährten Technologie aus dem Python Ökosystem selbst, sondern eher an der rechtlichen Situation derzeit in Europa. Die zentrale Instanz wird nämlich in der US Central Region ausgeführt, was eine Verwendung durch europäische Unternehmen im operativen Einsatz derzeit leider unmöglich macht. Auch das sollte nach dem Beta-Stadium gelöst sein und die Region frei wählbar sein.

2015/08/05

MOOC Scalable ML

Der zweite Data Science MOOC unter Verwendung von Apache Spark ist jetzt auch zu Ende gegangen. Wie schon im letzten Post erwähnt, handelt er von skalierbaren maschinellem Lernen. Obwohl die sinnvolle Vertiefung zum Kurs "Introduction to Big Data with Apache Spark", konnte dieser MOOC nicht mal annähernd an dessen Qualität anschliessen.

Theorie

Der Vortrag über die vorgestellten Methoden (im Grunde waren das nur Lineare und Logistische Regression und Faktorenanalyse) war wirklich miserabel. Die Konzepte dahinter wurden, wenn überhaupt, nur kurz erwähnt und auch die Skalierbarkeit kam viel zu kurz. Dafür wurde mit Formeln um sich geworfen und Matrix-Rechenoperationen bis zum Exzess praktiziert. Natürlich auch wichtig, aber wenn schon nur so wenige Methoden vorstellt werden, hätten die zumindest auch leichter verständlich und mit ein paar Beispielen aus der Praxis präsentiert werden können. Der einzige Lichtblick war die Woche 2 - das lag aber nur daran, dass darin in Apache Spark eingeführt wurde und nämlich mit Vorträgen aus dem Vorgängerkurs "Introduction to Big Data with Apache Spark" (für Absolventen wie mich also eine Woche zum überspringen).

Praxis

Die praktisch ausgerichteten Labs waren zwar um Welten besser als die Vorträge, aber auch diese konnten mein Frustrationslevel bezüglich diesem Kurses nicht großartig senken. Man merkte zwar, dass die Ersteller aus den Fehlern der ersten Labs im Vorgänger-MOOC gelernt haben, es schlichen sich jedoch dennoch einige didaktische Fehler ein. Es ist z.B. mühsam, wenn ein Fehler am Ende des Labs auftritt, weil eine Funktion am Anfang nicht gestimmt hat (obwohl ursprünglich damit alle Test einwandfrei liefen) - so geschehen im Lab 4. Alles in Allem ein MOOC den man sich getrost sparen kann, um Zeit und Energie für bessere Lehrmaterialien aufzuwenden.

2015/07/04

MOOC über Big Data & Apache Spark - Teil 3

...Fortsetzung von Teil 2...

Die letzten beiden Wochen des MOOCs sind nun vorbei. Das vorgetragene Material in der vierten Woche handelte von Exploration und Datenqualität. Zwei Themen, die mMn in einer früheren Phase des Kurses besser aufgehoben gewesen wären. Der Inhalt beschränkte sich auch sehr auf Oberflächlichkeiten der beiden Bereiche. Hätte einiges an Zeit gespart, die Videos zu überspringen. Auch das Lab in dieser Woche hätte besser aufbereitet werden können. Die Fragestellung war zwar spannend -Text Analyse auf Produkt-Datensätze von Google und Amazon anwenden -, die Anleitung war aber großteils schwer verständlich und der vorgegebene Lösungsweg mühsam nachzuvollziehen. Die vorgegebenen Hilfsfunktionen, die mit wenig Code zu ergänzen waren, kosteten im Endeffekt mehr Zeit und Nerven, als wenn die komplette Programmlogik neu geschrieben hätte werden müssen. Dieses Lab kostete mir auch die Möglichkeit, 100% der Punkte für den Kurs zu bekommen, da ich die eine Hilfsfunktion bei Frage 4f nicht vor dem Ende der Soft-Deadline lösen konnte. Als ich die Lösung dann endlich hatte, wurden wegen der verspäteten Abgabe Strafpunkte abgezogen. Ein A wird sich dennoch ausgehen ;)

Die fünfte Woche war dann wieder entspannter. Sie bestand nur mehr aus dem letzen Lab des Kurses, das als Übergang zum kommenden MOOC von BerkeleyX, Scalable Machine Learning, gesehen werden kann. Das Lehrmaterial war wieder auf gewohnt hohem didaktischen Niveau und war wirklich lehrreich & spannend. Es ging um die Möglichkeiten mit Spark Maschinelles Lernen umzusetzen, was Dank dessen MLLib Bibliothek auch kein Hexenwerk (nichtmal auf verteilten Systemen) ist. Die Aufgabe beinhaltete, basierend auf einer Teilmenge von Filmbewertungen von MovieLens, ein Vorhersagemodell für Bewertungen, auf Basis von Collaborative Filtering, zu bauen. Am Schluß konnte man ein paar Filme selbst bewerten und erhielt dann eine Vorhersage für jene 20 Filme, die das Modell vorhersagt, dass sie einem am besten gefallen werden (also, dass man sie am besten bewerten wird). Basierend auf nur 10 Filme, die ich in der Aufgabe bewertet habe, waren meine Ergebnisse verblüffend treffsicher (eingedenk der limitierten Daten und Feature Basis):
Ergebnisse von meinem Modell
Die mir bekannten Filme aus der Liste, würde ich tatsächlich alle sehr hoch bewerten. Von einigen habe ich die Story auf Wikipedia gesucht - und sollten mir eigentlich auch zusagen. Somit hatte der MOOC einen zusätzlichen Bonus, nämlich die Einsicht, dass ich mir mal Citizen Kane anschauen sollte ;)

Zusammenfassung

Da der MOOC nun beendet ist, ein kurzes Resümee. Abgesehen von kleineren Schwächen in Woche 4, war "Introduction to Big Data with Apache Spark" ein sehr gut gemachter Kurs. Ich würde sogar sagen, der beste MOOC, den ich bislang -egal auf welcher Plattform- belegt habe. Der vorgetragene Inhalt wurde verständlich aufbereitet und die praktischen Aufgaben hatten definitiv Realitätsbezug - kamen also nicht aus den typischen "Data Science"- und "Machine Learning"-Schubladen wie bei so vielen anderen Lehrmaterialien, die in der Fachliteratur zu finden sind. Im Grunde war das Durcharbeiten des Materials des Kurses sogar lehrreicher als die beiden von mir glesenen Bücher über Spark (Learning Spark: Lightning-Fast Big Data Analysis bzw. Advanced Analytics with Spark: Patterns for Learning from Data at Scale). Insofern freue ich mich jetzt schon sehr auf den kommenden Kurs von BerkeleyX auf edX über Maschinelles Lernen mit Spark, der jetzt auch schon gestartet ist. Praktisch dabei, dass Teile von "Introduction to Big Data with Apache Spark" auch wiederverwendet werden können. Man erspart sich somit eine neue virtuelle Maschine herunter zu laden und das Material der zweiten Woche ist aus dem vorhergegangen MOOC übernommen (inkl. des LABs). Über die Erfahrungen bei diesem MOOC werde ich dann auch die nächsten Wochen mal berichten. 

2015/06/18

MOOC über Big Data & Apache Spark - Teil 2

...Fortsetzung von Teil 1...

3. Woche - Datenstrukturen

In dieser Woche ging es um Datenmanagement. Die beiden Lektionen handelten von strukturierten bzw. semi-strukturierten Daten. Auch die Performance beim IO unterschiedlicher Dateiarten wurde angesprochen.
Lektion 5, über semi-strukturierte Daten, handelte vor allem um tabellarische Strukturen und dem Zusammenspiel von Pandas Dataframes mit Spark. Als Beispiel wurden Server-Log-File Analysen angesprochen und an einer solchen, konnte man sich dann auch im Lab gleich selbst versuchen - konkret an den monatlichen HTTP Requests an einem Server der NASA. Der Schwierigkeitsgrad der Aufgaben wurde schon deutlich erhöht, dafür waren die Aufgabenstellungen auch ganz interessant, weil realitätsnah. 
Die zweite Lektion der Woche handelte von strukturierten Daten. Das war dann natürlich sehr SQL-lastig und alle möglichen joins mit Spark RDD's wurden vorgestellt.

...to be continued...

2015/06/08

MOOC über Big Data & Apache Spark - Teil 1

In diesem Monat war es endlich so weit und der erste von zwei angekündigten MOOCs über Apache Spark wurde auf edX veröffentlicht. Ersterer hat den Titel "Introduction to Big Data with Apache Spark" und meine Erfahrungen dabei werde ich hier teilen. Der Zweite handelt von Maschinellem Lernen mit Spark und wird Ende des Monats starten. Da ich mich in letzter Zeit öfter mal nebenbei mit Spark zu Weiterbildungszwecken beschäftigt habe (Learning Spark: Lightning-Fast Big Data Analysis gelesen und Advanced Analytics with Spark: Patterns for Learning from Data at Scale gerade durcharbeite), passen die MOOCs da auch gerade gut dazu.

1. Woche - Introduction 

Der Einführungskurs in Big Data Analyse und Spark ist letzte Woche gestartet und soll 5 Wochen lange dauern. In Beispielen der Lektionen und Programmieraufgaben wird PySpark (die Python-API von Spark) anstatt Scala verwendet.
In den beiden ersten Lektionen ging es darum, Verständnis zu schaffen, was Big Data ist und welche datenwissenschaftliche Methoden es gibt. Der Inhalt in den Lektionen ist klar strukturiert und wird von Anthony D. Joseph verständlich präsentiert. Da es sich um eine Einführung handelt und die Themen generell komplex und unklar abgegrenzt sind, bleibt es verständlicherweise bei Oberflächlichem.
Die Beurteilung von TeilnehmerInnen erfolgt zu einem kleinen Teil über kurze MC Fragen in den Lektionen und vor allem über die wöchentlichen Labs, in denen programmiert wird. Besonders positiv hervor zu heben ist dabei das Design der Labs. Um die verteilte Ausführung zu simulieren, wird eine bereitgestellte virtuelle Maschine, welche die relevanten Programme ausführt, als Worker installiert und als Treiberprogramm laufen die Labs als IPython Notebooks im lokalen Browser. Der bearbeitete Programmcode wird als Python Skript gepeichert und dann auf edX hochgeladen, um den Code durch einen Autograder überprüfen zu lassen. Die Einrichtung des beschriebenen Setups für die Labs und das Durchführen einer Test Benotung ist dann auch die zu erledigende Aufgabe in der ersten Woche.

2. Woche - Getting started

Die zweite Woche startet mit einer eher theoretischen Lektion über die Voraussetzungen für Computersysteme, um mit Big Data umgehen zu können und wie diese in Spark umgesetzt sind. In der vierten Lektion wird dann endlich in die Logik von Spark eingeführt. RDDs, Transformations, Actions, das Daten Caching, Key-Value RDDs und besondere Variable (Broadcast V und Accumulatoren) werden erklärt.
Im Lab für die zweite Woche kann zuerst ein (unbenotetes) Tutorium absolviert werden. In der eigentlichen Aufgabe werden die Anforderungen graduell gesteigert und es muss ein WordCount Skript zum zählen von Wörtern in einem Textdokument (Texte von Shakespear) erstellt werden. Das Lab versucht praxisnah zu sein, was auch überwiegend gelingt. Die große Herausforderung, an geeignete Daten zu kommen, wird nicht umgesetzt, dafür muss der vorhandene Datensatz aber (zumindest rudimentär) bereinigt und effizient weiterverarbeitet werden. Überhaupt wird bislang in diesem MOOC ein Fokus auf die effiziente Verteilung, Analyse und Verarbeitung der Daten gelegt, was sehr zu begrüßen ist. Sind alle Aufgaben gelöst, bekommt man die 15 häufigst verwendeten Wörtern in Shakespear-Texten präsentiert - da stop words vorher nicht entfernt werden mussten, sind es dann auch die üblichen Verdächtigen ;)

...to be continued... 

2015/05/24

Storytelling mit Odyssey.js

Mit Odyssey.js wird es einem ziemlich einfach gemacht, interaktive kartenbasierte Stories zu erstellen. Mit ein bisschen Markdown und wenigen Klicks sind schnell ein paar Slides mit Kartenausschnitten zu einer interaktiven Geschichte zusammen zu stellen.

Kartenbasierte Geschichten

Odyssey.js ist ein Open Source Projekt von CartoDB und weist noch einen relativ frühen Entwicklungsstand auf. Einiges funktioniert nicht wie es sollte (z.B. die Leaflet Integration) und die Auswahlmöglichkeiten sind teilweise auch noch bescheiden. Aktuell ist es beispielsweise nur möglich zwischen 3 Basiskarten zu wählen. Die Markdown Umsetzung ist auch noch nicht ganz ausgereift. Für erste Versuche und ein paar visuell ganz ansprechende Stories ist das Tool aber schon zu gebrauchen. Als Resultat kann die erstellte kartenbasierte Story in HTML lokal gespeichert, als iFrame in eine Webpage eingebunden oder als eigenständige Page (gehostet über die Projektseite) verwendet werden.

Das Projekt ist mMn aus zwei Gründen sehr sinnvoll. Einerseits ist es ein weiterer Baustein, um Kartenanwendungen zu demokratisieren. Es ermöglicht einen einfachen Zugang zur Erstellung und Verbreitung eigener webbasierter Karten auch für GIS-Laien. Andererseits ermöglicht das Projekt eben die Zusammenstellung der Karten in Stories, inklusive interaktiver Features für BetrachterInnen. Gerade diese Möglichkeit macht das Tool mMn für die Sozialforschung interessant, um beispielsweise qualitative Ergebnisse in den geografischen Kontext zu setzen und dieses Aggregat als gemeinsame Geschichte zu präsentieren. Ausserdem kann damit RezipientInnen auch ermöglicht werden, mit diesen Ergebnissen zu interagieren, ohne den mühsamen Umweg, die Interaktion selbst entwickeln zu müssen.

Beispielgeschichte

Das Thema dieses Beispiels liegt nicht in der Sozialforschung, sondern in der Werbung. Es soll zeigen, wie mit wenig Aufwand der geografische Kontext eines Produktes mit dessen Entstehungsprozess so verbunden werden kann, dass BetrachterInnen einen näheren Bezug zum Produkt entwickeln. Da in diesem Anwendungsfall die exakte geografische Darstellung nicht von zentraler Bedeutung ist, wurde der Watercolor Style von Stamen Design für die Basiskarten verwendet und die PoI's auch nicht exakt verortet. Der Inhalt ist entsprechend eines schnellen Prototyps natürlich auch nicht ausgereift.
Hier der Link zur Geschichte über den Weg meines Lieblingskaffees.

2015/05/20

Spyre - Framework für Python Datenprojekte

Was dem Python Daten Ökosystem bislang noch fehlt, ist ein Modul um webfähige Datenprodukte, schnell und mit wenig Aufwand, zu erstellen. Adam Hajari hat einen ersten Versuch unternommen, das zu ändern und begann die Entwicklung von Spyre. Um dieses Framework zu testen, habe ich eine kleine Beispielapplikation geschrieben, das im Repo für diesen Blog unter den Python Beispielen zu finden ist.

Daten von Strava

Für das Beispiel habe ich ein paar Daten zu meinen sportlichen Aktivitäten in diesem Jahr von Strava herunter geladen. Die Strava API ist zwar nicht gerade ein Highlight in Bezug auf UX beim Datenabgreifen, aber es gibt zumindest ein (selten schlecht dokumentiertes) Python Modul, das die Verbindung managt und somit die Angelegenheit ein bisschen schmerzfreier gestaltet. Das Skript, mit dem ich die Kollektionen mit meinen Radfahr- und Schwimm-Aktivitäten erstellt habe, ist auch im Beispiel Verzeichnis zu finden. Sie enthalten die Art der Aktivität, die Startzeit, Dauer und Distanz.

Spyre Apps

Nach der Installation von Spyre (das Paket heisst dataspyre bei pip) und dem Download des master Repos des Projekts kann gleich mit dem Testen der Beispielanwendungen begonnen werden. Diese sind sehr auf Plots fixiert, es ist z.B. auch möglich Bokeh Plots zu integrieren, aber auch diverse Matplotlib Derivate können gerendert werden. Aber auch das Erzeugen von Tabellen wird durch ein Beispiel abgedeckt. Wirklich sehr nützlich um sich mit dem Modul vertraut zu machen, ist das Tutorial im Spyre Repo, im Form eines Ipython Notebooks. Darin wird anhand der Beispielanwendungen die wichtigsten Input-Elemente (div. Buttons, Slider, Dropdown etc.) und Output-Möglichkeiten (Plot, Tabelle etc.) des Frameworks erklärt.
Radfahr Daten in Browser App
Daten App im Browser

Von den Beispielen im Spyre Repo habe ich dann auch meine Beispielanwendung abgeleitet (hier ist der Code dazu). Um die Anwendung zu starten genügt es, das Hauptskript mit Python (in einer 2er Version) zu starten und im Browser der Wahl den Port 9097 vom localhost aufzurufen. Wie in dem Foto rechts zu sehen ist, kann dann mit einem Dropdown die Sportart gewählt werden. Der Plot (der Simplizität zuliebe mit Pandas erzeugt) zeigt daraufhin die Tage, an denen die Aktivität statt fand und die Distanz, welche mit dem Rad bzw. im Schwimmbecken zurück gelegt wurde.

Ein Spyre Server basiert übrigens auf dem CherryPy Web Framework. Wer daran ein bisschen herum bastelt, kann übrigens auch Spyre Apps auf einen Raspberry Pi 2 zum Laufen bringen (siehe Foto unten). Das halte ich für insofern interessant, da es damit möglich wird, Sensordaten abzugreifen, zu verarbeiten und jetzt eben auch im Internet zu präsentieren mit einer durchgängigen Programmiersprache und auf einem Gerät.
Ein von @datadonk23 gepostetes Foto am


Zusammenfassung

Mit Spyre ist es möglich, webfähige Datenprodukte durchgehend in Python zu erstellen, ohne auf Übersetzungen in eine andere Sprache (wie zB bei plot.ly) und den damit verbundenen Einschränkungen, angewiesen zu sein. Die Funktionalität und Usability ist aber im Vergleich zum R Ökosystem mit Shiny jedoch sehr bescheiden und benötigt noch jede Menge Entwicklungsarbeit der Community. Es bleibt zu hoffen, dass das Projekt weiter an Bedeutung zunimmt und eventuell auch eine Plattform wie ShinyApps.io, nur für das Python Daten Ökosystem, entstehen lässt. Insbesonders für die adäquate Präsentation von Analyse-Ergebnisse oder Daten-Modellen ist ein Modul wie Spyre bedeutend, um datenwissenschaftliche Prozesse durchgehend in Python zu ermöglichen.

2015/03/24

Geo-App: Schlösser und Burgen in OÖ

Als Beispiel-Projekt habe ich eine Geo-App entwickelt. welche den Standort von Schlösser und Burgen in Oberösterreich visualisiert. Sie dient zur Ergründung solcher Bauwerke in der eigenen Umgebung, kann auch Informationen beim Wandern bereit stellen oder zur Planung von Ausflügen verwendet werden.
Dieser Eintrag wird den Entstehungsprozess thematisieren. Die App selbst ist auf folgender Seite erreichbar:


Daten von Wikipedia

Burg Ruttenstein, Foto © S. Wiesinger, 2014
Auf das touristisch verwertbare Thema, Schlösser und Burgen, bin ich durch einen offenen Datensatz des Landes OÖ gekommen. Wie sich jedoch erst heraus stellte, fehlten in diesem Datensatz eine größere Anzahl an Objekten, insbesonders (aber nicht nur) die touristisch interessanten Burgruinen. Aus den Metadaten war das so leider auch nicht ersichtlich. Genau so unzuverlässig und halbherzig dokumentiert sollten Open Data eigentlich nicht sein.
Schloss Lamberg, Foto CC-BY 4.0 Int. T.Treml, 2015
Als Alternative habe ich mich für die Verwendung von Daten von Wikipedia entschieden. Dazu habe ich ein kleines Script geschrieben, das die jeweilgen Namen der Bauwerke, einen Link zur jeweiligen Wikipedia Seite (als Information für die Pop-Ups in der App) und die Geokoordinaten extrahiert. Die Verortung ist zwar weniger genau, als jene im Datensatz des Landes, jedoch ist die Anzahl der Objekte umfassender, insbesonders die erwähnten Ruinen kommen hierbei auch vor. Darüber hinaus klassifiziert das Script die Bauwerke noch, um eine Unterscheidung zwischen Burgen und Schlösser bei der Visualisierung zu ermöglichen. Bei den von den 324 aufgelisteten Objekten, konnten nur 5 wegen mangelnder Geoverortung oder nicht Verfolgbarkeit der Links nicht verwendet werden. Im Vergleich dazu umfasst der Datensatz des Landes nur 240 Objekte.
Um Oberösterreich hervor zu heben, habe ich wieder auf einen DORIS Datensatz vom Land OÖ zurück gegriffen. Dieser ist zwar stark generalisiert, was aber im Kontext dieser App ein Vorteil ist, da Speicherplatz und Ladezeiten dadurch vermindert werden. Um Zweiteres zu verbessern wird er vor dem Rendern im Browser auch noch weiter generalisiert.

Die extrahierten Daten wurden dann in QGIS geoprozessiert und in ein Datenmodell transformiert. Dieses wurde mit MongoDB umgesetzt, da dessen Schemalosigkeit die Entwicklung vereinfachte und die damit mögliche Geoindexierung effiziente Abfragen versprach.

Übersicht Karte

Flask-App mit Bootstrap Frontend

Das Backend der App basiert auf dem Python Framework Flask und wie erwähnt MongoDB. Die Architektur folgt einem vereinfachten MVC Modell.
Marker mit Pop-Up
Das Frontend wurde auf dem Bootstrap Framework aufgesetzt, vor allem um die App auch responsiv zu gestalten. Das ist besonders für den Anwendungsfall der mobilen Abfrage von Objekten nötig, beispielsweise wenn sich ein/e Benutzer/in beim Wandern oder einem Spaziergang befindet und erfahren möchte, wo sich die nächste Burg oder das nächste Schloss befindet. Grundsätzlich nimmt den größten Teil der Frontpage die ganzseitige Karte mit den visualisierten Objekten ein. Eine Navigationsleiste ermöglicht noch das Aufrufen einer kurzen Anleitung und Informationen über die Daten und der App. Diese Informationen wurden auf eine eigene Seite ausgelagert.

Die Kommunikation zwischen Front-  und Backend wurde mit einem Zusammenspiel von Flask mit AJAX und jQuery umgesetzt und könnte bei weitem besser entwickelt sein - bin leider kein Software Ingenieur. In diesem Zusammenhang sei auch erwähnt, dass die App für einen unternehmerischen Einsatz an manchen Stellen noch robuster programmiert werden müsste. Für ein Beispiel, das die Möglichkeiten mit den verwendetetn Daten und Techniken zeigt, sollte dieser Entwicklungsstand aber ausreichen.

Geo-App mit Leaflet

Die Karte selbst wurde mit Leaflet umgesetzt. Mein Konzept für die Visualisierung konnte damit (und auch Dank der verwendeten Plugins) sehr effizient umgesetzt werden.
Als Basiskarte habe ich mich für das Open Static Map Service von MapQuest entschieden. Der Toner Style von Stamen Design hätte zwar grafik-design-technisch mehr her gegeben, aber die MapQuest Tiles geben durch ihr Farbschema visuell Informationen über die geografische Verortung der Bauwerke intuitiver preis.
Standortbestimmung
Der Standort der Schlösser und Burgen wird durch Marker angezeigt. Ein Piktogramm darauf zeigt an, zu welchem Typ das Objekt gehört. Durch das Auswählen eines Markers mittels Click, öffnet sich ein Pop-Up, das den Namen des Bauwerks und einen Link zu dessen Seite auf Wikipedia enthält, um sich näher über das jeweilge Schloss oder die Burg informieren zu können.
Mit einem Button auf der Karte, ist es möglich, seinen eigenen Standort durch die App anzeigen zu lassen. Dabei wird auf Geoinformation aus dem Browser zurück gegriffen, was erst mit mobilen Geräten wirklich Sinn macht. Dennoch ist die Standortbestimmung damit nicht in allen Gegenden, auch trotz dem Einsatz von GPS, wirklich gut. Über die Einschränkungen ist dieser Artikel recht informativ. Jedenfalls, als Näherungswert, sollte die Bestimmung dennoch ausreichen.
Sobald die App den Standpunkt bestimmt hat, wird aus der Datenbank das geografisch nächste Schloss oder die nächste Burg abgefragt. Die Bestimmung des nächsten Objekts vereinfacht der räumliche Index in MongoDB ungemein und ist mit einer einfachen Anfrage auszuführen. Auf der Karte wird das nächste Bauwerk dann mit einem eigenen Marker hervorgehoben.

Deployment auf OpenShift

Weil die Datenbank wenig umfangreich ist und sich auch der Rechenaufwand zur Darstellung der Page in Grenzen hält, wird die App auf einem einzigen Gear in OpenShift gehostet. Problematisch war hierbei nur die alte Version von MongoDB in der Standard-Cartridge. Da die App mit einer neueren Version der Geoindizes lokal entwickelt wurde, habe ich eine aktuelle Version in OpenShift nachgerüstet - was Dank der MongoDB 2.6 Cartridge von Ionut-Cristian Florescu kein großes Problem war.

Zusammenfassung

Mit der Entwicklung dieser Geo-App habe ich versucht zu zeigen, wie es möglich ist mit relativ simplen Mitteln und offenen Daten die Visualisierung von Standorten von mehreren Objekten umzusetzen. Das Thema des Beispielprojekts, Schlösser und Burgen in Oberösterreich, ist touristisch nutzbar. Das beschriebene Vorgehen ist aber auch auf andere statische Objekte wie beispielsweise Geschäftsniederlassungen, Standorte von sportlichen oder kulturellen Einrichtungen etc. anwendbar. Erweiterungsmöglichkeiten sind auch vorhanden, beispielsweise im Rendern von 3D-Modellen der einzelnen Bauwerke an ihren Standorten bei hohen Zoomstufen.
Aus Sicht der Sozialforschung ist der Blick auf die Karte auch nicht uninteressant, liefert sie doch eine Darstellung der Verteilung von machtdarstellenden Bauwerken in früheren Zeiten. Dabei ist besonders markant (wenn auch nicht unlogisch), dass sich solche Gebäude in jenen Gebieten konzentrieren, die noch Heute bevölkerungsreich sind, wohin gegen in ländlichen Regionen solche Objekte verstreut in der Landschaft liegen, wobei diese nicht zwangsläufig in Nähe aktueller regionaler Zentren liegen müssen. Hinsichtlich der Sozialforschung ist des weiteren auch bemerkenswert, dass gemeinschaftlich auf Wikipedia erstellte Information, nicht nur umfangreicher, sondern auch gültiger sein kann, als ein von offizieller Stelle publizierter Datensatz.
Die zum Projekt gehörenden Scripte und der Source Code der App sind im Webbeispiele Repository dieses Blogs ersichtlich. Für die Planung von Tageausflüge und -in eingeschränktem Masse- auch mobil für die Orientierung bei einer Wanderung, lässt sich die App auf jedem Fall nutzen. Auch das Ergründen von bislang einem noch unbekannten Bauwerke kann ganz spannend sein.

Burgruine Ruttenstein, Foto © S. Wiesinger, 2014