Heute sind nach langer Vorbereitungszeit die ersten MVG Digitalstelen eröffnet worden. Die meisten stehen im Stadtteil Neuaubing, die Eröffnung fand beim Westkreuz statt. Sie stehen jeweils bei den neuen MVG Mobilitätsstationen, die öffentlichen Nahverkehr, Bike- und Carsharing und die Quartiersboxen bündeln.
Die Digitalstelen bieten einen interaktiven Umgebungsplan, über den man sowohl die Geschäfte, Sehenswürdigkeiten und Straßen erkunden kann als auch verschiedene Angebote der MVG einsehen kann, z.B. die Abfahrtszeiten von U-Bahnen und Bussen, E-Ladesäulen etc.
Auch die Messdaten der intelligenten Lichtmasten, die von der Stadt München im Rahmen des Smarter Together Projekts aufgestellt wurden, können über die Digitalstelen eingesehen werden (auch wenn es zurzeit nur von einem Lichtmast in der Wiesentfelser Straße tatsächlich Daten gibt).
Mein Beitrag dabei war die Software, die auf den Stelen läuft, sowie eine Backend-Komponente dazu. Beides entwickelte ich im Auftrag der Portalgesellschaft München, die auch die Website www.muenchen.de betreibt.
Backend: Echtzeitproxy / Node.JS
Das (softwaretechnisch) spannendste daran ist die Backend-Komponente, der sogenannte „Echtzeit-Proxy“. Dieser kommt nicht nur bei den Digitalstelen zum Einsatz, sondern auch bei anderen Produkten der Portalgesellschaft wie beispielsweise der Spielplatz-München-Karte, dem letztens überarbeiteten muenchen.de-Stadtplan und der neuen Version der Android-App.
Der Echtzeit-Proxy dient vor allem der Daten-Aggregation und -Aufbereitung und ist speziell für effiziente Kartenanwendungen ausgelegt. Wir standen bei den verschiedenen Kartenanwendungen bei muenchen.de vor dem Problem, dass wir es mit einer Reihe an verschiedenen Datenquellen zu tun haben:
- Das Branchenbuch von muenchen.de selbst, das über 100.000 Einträge umfasst.
- Der städtische Dienstleistungsfinder, der zwar über muenchen.de zu finden ist, technisch und organisatorisch komplett unabhängig läuft und Daten wie Spielplätze, öffentliche Toiletten, Behindertenparkplätze enthält.
- Die Schnittstellen der MVG, die Standorte und Abfahrtszeiten von öffentlichem Nahverkehr, MVG-Rädern, Carsharing und E-Ladesäulen bereitstellt und deren Daten sich daher viel häufiger ändern.
- Sowie einige weitere Datenquellen, die perspektivisch integriert werden sollen.
Die Daten sind jeweils deutlich anders strukturiert (z.B. sind die Branchenbuch-Einträge bei muenchen.de per n*m-Relation einem hierarchischen Kategorien-Baum zugeordnet, während Spielplätze sich eher nach Ausstattungsmerkmalen und Zielgruppen gegliedert sind) und haben unterschiedliche Anforderungen an Aktualität (beim Branchenbuch ist eine Zeitverzögerung von einem Tag akzeptabel, während bei den Standorten von frei stehenden MVG-Rädern eine Minute Verzögerung bereits viel ist).
Für die Kartenanwendungen, die auf diese Daten zurückgreifen, ist dagegen vor allem wichtig, die Netzwerklatenz, die Anzahl der HTTPS-Requests sowie die zu übertragene Datenmenge möglichst zu reduzieren:
- Um die Zeit für einen Request möglichst zu reduzieren setzen wir neben reinen Netzwerktechniken wie HTTP2 vor allem auf einen einfach gehaltenen Node.JS-Server, der komplett ohne Datenbank auskommt und einen Großteil des Datenbestands im Arbeitsspeicher vorhält. Dadurch kommen wir i.a. auf unter 50ms, sofern nicht externe Ressourcen nachgeladen werden müssen (z.B. die Bewertungen, Öffnungszeiten und Abfahrtszeiten, die bei jeweils externen APIs liegen). Auf ein dediziertes CDN für die Echtzeitproxy-API verzichten wir aktuell allerdings (im Gegensatz natürlich zu den statischen Ressourcen wie Icons und Bilder).
- Um die Anzahl der Requests und der Datenmenge zu reduzieren müssen verschiedene Abfrage-Modi unterstützt werden, die auf Kartenanwendungen zugeschnitten sind: vor allem Boundingbox-Abfragen mit kombinierten Kategorien-Abfragen („Alle Apotheken und Nahverkehrs-Haltestellen innerhalb des angezeigten Kartenausschnittes“) sind wichtig. Um die Datenmenge gering zu halten werden erweiterte Daten wie Beschreibungstexte nur auf explizite Anfrage hin ausgeliefert und bei Bedarf auch jeweils nur in der abgefragten Sprache (aktuell werden deutsche und englische Titel, Beschreibungen, Adressen etc. unterstützt, perspektivisch könnten aber auch weitere Sprachen hinzukommen). Und natürlich wieder gängige Netzwerk-Techniken wie gzip-Kompression.
Daneben gibt es (und nichts anderes erwartet man natürlich) auch ein kleines Sammelsurium an ad-hoc-PHP-Proxy-kripten – die in diesem Projekt aber tatsächlich nur eine untergeordnete Rolle spielen.
Frontend: Angular, Leaflet, Charts.js
Der Hauptteil des Frontends besteht aus einer Leaflet-Karte, die in ein Angular-Framework eingebettet ist. Hier entwickeln wir natürlich nicht für jede Kartenanwendung alles von Grund aus neu sondern verwenden für mehrere Anwendungen eine gemeinsame Code-Basis, die je nach Anwendung nur angepasst wird. Abgesehen von der Routing-Funktion (Fußgänger, Fahrrad, Auto und öffentlicher Nahverkehr – letzteres ist auf der Digitalstele allerdings aus Gründen™ nicht verfügbar) ist dabei technisch gesehen wenig Weltbewegendes dabei; ein Großteil der Arbeit bestand darin, die vielen verschiedenen Angebote abzubilden (eTrikes müssen anders behandelt werden wie eRäder, und die wiederum anders wie reguläre MVG-Räder; Stattauto-Stationen müssen anders behandelt werden wie Stattauto Flexy, usw. …).
Das Kartenmaterial selbst kommt von Mapbox, basierend auf OpenStreetMap.
Teilweise unabhängig davon gibt es noch ein teils unabhängiges Frontend für die intelligenten Lichtmasten, das als IFRAME in den Digitalstelen eingebunden wird. Diese Lösung wurde deshalb gewählt, da diese Seite nicht nur auf den Digitalstelen verwendet wird, sondern auch als Webview in der neuen Version der muenchen.de-Android-App eingebunden wird. Daher lief es auf eine technisch möglichst einfach gehaltene Seite auf Basis von jQuery und der Charting-Bibliothek Charts.js hinaus.