Tobias Hößl

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.

Antragsgrün hat in den letzten Monaten große Fortschritte gemacht und nähert sich nun der Version 4: der erste zweite Release Candidate wurde gerade veröffentlicht, womit die Version aus meiner Sicht nun prinzipiell einsatzbereit ist. Sowohl organisatorisch als auch funktional gibt es dabei grundlegend Neues, weswegen es seit langem wieder einen großen Versionssrung (von 3.8 auf 4.0) gibt.

Ins Leben gerufen wurde Antragsgrün vor allem für Parteitage von Bündnis 90 / Die GRÜNEN. Immer mehr zeigt sich aber, dass Antragsgrün auch Probleme anderer Organisationen löst, die ebenfalls Anträge, Programmentwürfe und Änderungsanträge transparent und basisorientiert diskutieren wollen. Schon seit längerem bringt sich daher der Deutsche Bundesjugendring sehr aktiv in die Weiterentwicklung und die Verbreitung von Antragsgrün mit ein. Mit NEOS – Das Neue Österreich und Liberales Forum setzt ab Herbst nun auch eine weitere Partei auf das Projekt und bringt sich entsprechend konstruktiv mit ein.

Konkrete Neuerungen:

Für alle, die Antragsgrün auf einem eigenen Server bzw. Webhoster betreiben, dürfte der neue Update-Mechanismus die wichtigste Neuerung sein. Mit diesem ist es möglich, künftige neue Versionen über die Web-Oberfläche mit wenigen Klicks einzuspielen. Mühsames erneutes Hochladen per (S)FTP, sowie händische Datenbank-Anpassungenn (die für die meisten wohl unzumutbar komplex waren) entfällt damit. Ich hoffe, dass dies verhindert, dass allzu viele veraltete Versionen online bleiben. Wer sich für den technischen Aspekt des Update-Mechanismusses interessiert, insbesondere wie die Integrität sichergestellt wird, kann hier das Sicherheitskonzept sehen.

Das Kommentarsystem wurde grundlegend erneuert: es ist nun möglich, auf Kommentare zu antworten, und dabei die Kommentare einzelner Anträge zu abonnieren – die Diskussionen zu Anträgen sollten dadurch deutlich vereinfacht werden. Auch optisch wurde das Kommentarsystem etwas verbessert.

Antragsgrün bietet nun auch deutlich bessere Möglichkeiten, redaktionelle Textseiten zu veröffentlichen – zum Beispiel Hilfeseiten, auf denen das Verfahren der jeweiligen Veranstaltung genauer erklärt wird oder weitere Informationen über die Mitgliederversammlung angeboten werden. Grundsätzlich lassen sich nun beliebig viele Inhaltsseiten anlegen und bei Bedarf im Menü oben verlinken. Neu ist dabei auch die Möglichkeit, dass man per Drag&Drop einfach Bilder hochladen kann; will man beispielsweise im Willkommenstext einer Veranstaltung eine Illustration einfügen, kann man beim Bearbeiten dieses Textes einfach ein Bild an die entsprechende Stelle schieben, und es wird automatisch hochgeladen.

Zuletzt gibt es auch eine Neuerung, die nach außen auf den ersten Blick kaum sichtbar ist, mittelfristig aber immer wichtiger werden dürfte: ein Plugin-System, mit dem sich sowohl Layout-Varianten als auch komplexere Workflows nachrüsten lassen. Das aktuell wichtigste konkrete Beispiel dafür ist das Tool Beteiligungsgrün, das vor kurzem vom Bundesverband der Grünen gestartet ist: sowohl die alternativen Antragslisten als auch das Konzept der Offenen Diskussion und des folgenden Unterstützungs-Sammelns werden über das neue Plugin-System gelöst. Auch die organisationsspezifischen Layouts (sowohl die beiden Grünen-Layouts als auch die neue NEOS-Variante) sowie die Verwaltung zum Anlegen neuer Subdomains werden als Plugin angeboten. Perspektivisch werden wohl auch weitere Login-Mechanismen (analog zur jetzigen SAML- und OpenID-Einbindung des Wurzelwerks) über das Plugin-System möglich sein.

Weitere Änderungen werden natürlich auch wieder im ausführlichen Changelog aufgelistet. Den Download gibt es auf der Github-Projekteseite.

Antragsgrün ist nun in der Version 3.8 erschienen, nachdem die Version auf der letzten Grünen-BDK bereits eingesetzt wurde. Neben einer ganzen Reihe an Bugfixes gibt es auch einige wichtige neuen Funktionen, die vor allem für größere Veranstaltungen relevant sind:

• Es gibt eine recht umfangreiche Möglichkeit für die Antragskommission, Verfahrensvorschläge für Anträge und Änderungsanträge festzulegen. Dazu gehören unter anderem alternative Versionen von Änderungsanträgen, das Festlegen von Abstimmungsblöcken und eine Kommentarfunktion für die Antragskommission.
• Wenn sich Änderungsanträge auf den Titel eines Antrags beziehen, wird diese Änderung nun auch in der „Laschenansicht“ neben dem Titel des Antrags angezeigt.
• Wenn Änderungsanträge in einen Antrag eingepflegt werden (oder aus anderem Grund eine neue Antragsversion erstellt wird), gibt es nun eine Vergleichsfunktion, welche die Änderungen der beiden Versionen in der Diff-Ansicht anzeigt.

Daneben gibt es einige Technische Änderungen unter der Haube, insbesondere die Kompatibilität mit PHP 7.2.

Die neue Version und das ausführliche Changelog gibt es hier:
https://github.com/CatoTH/antragsgruen/releases/tag/v3.8.0

Jetzt, wo ich schon seit ein paar Wochen an der neuen Version 3.8 von Antragsgrün arbeite, wird es auch langsam einmal Zeit, Version 3.7 offiziell zu veröffentlichen – was hiermit getan ist. 🙂

Diese Version wurde großteils vom Deutschen Bundesjugendring in Auftrag gegeben, der wie viele seiner Mitgliedsorganisationen inzwischen auch regelmäßig Antragsgrün einsetzt. Das genaue Einsatzszenario des DBJRs unterscheidet sich dabei aber doch deutlich von dem, wie Antragsgrün bei Bündnis 90 / Die GRÜNEN eingesetzt wird: vor allem das Überarbeiten des Antrags, bei dem die Änderungen der Änderungsanträge auf einer Präsenzveranstaltung eingepflegt werden, spielt hier eine große Rolle. Die wichtigsten Neuerungen in der Version 3.7 beziehen sich also auch auf diese Funktion.

Aber auch bei der Darstellung der Änderungen in Änderungsanträgen gab es eine ganze Reihe an Verbesserungen, besonders wenn längere Textpassagen davon betroffen sind. Insbesondere gibt es nun auch die Möglichkeit, Änderungsanträge als „Globalalternative“ zu kennzeichnen, die daraufhin separat dargestellt werden.

Eine der wichtigsten Neuerungen ist aber nicht-technischer Natur: es gibt nun erstmals auch ein Handbuch, das die wesentlichen Funktionen von Antragsgrün beschreibt.

Eine genaue Liste der Änderungen in der neuen Version gibt es im Changelog.

Über zwei Jahre ist es her, dass ich München Transparent veröffentlicht hatte – ein Projekt, das ich über mehrere Jahre hinweg zuerst alleine, später zusammen mit Konstantin Schütze und Bernd Oswald in meiner Freizeit entwickelt hatte. Die Seite ist nahezu durchgehend sehr gut angenommen worden, und obwohl wir nie größer Werbung dafür machten und die Weiterentwicklung seitdem zugegebenermaßen eher auf Sparflamme lief, hat sie täglich zwischen 400 und 500 Besucher. Bürgerinnen und Bürger Münchens können davon profitieren, dass sie E-Mail-Benachrichtigungen erhalten, wenn es Beschlüsse oder Auskünfte aus dem Stadtrat oder den Bezirksausschüssen zu ihrem Lebensumfeld gibt, Journalist*innen und Mitarbeiter*innen der Stadtverwaltung schätzen die unkomplizierte Suchfunktionen.

Als der Prototype Fund ausgerufen wurde, eine recht interessante Kooperation aus der Open Knowledge Foundation (OKF), dem Deutschen Luft- und Raumfahrtzentrum (DLR) und dem Bundesministerium für Bildung und Forschung (BMBF), hatten Konstantin unabhängig voneinander die selbe Idee: die Erfahrungen von München Transparent nutzen, um ein neues Ratsinformationssystem zu schreiben, das nicht nur auf München zugeschnitten ist, sondern sich für beliebige Kommunen einsetzen lässt – selbstverständlich als Open Source.

Die Bewerbung und die Vorbereitung nahm dabei einiges an Zeit in Anspruch: die Bewerbungsphase lief im März, im Juni schließlich bekamen wir den erhofften Anruf mit der Bestätigung, von Juni bis Juli hieß es dann, alle notwendigen Unterlagen sammeln, GbR gründen, Konto eröffnen, und jetzt, Anfang September, geht es endlich los! Heute fand der Kick-Off-Workshop in Berlin statt, bei dem wir die anderen geförderten Teams kennenlernen durften.

Zuerst heißt es einmal, den genauen Projektumfang abzustecken und die Arbeitsaufteilung festzulegen. Konstantin und ich haben recht unterschiedliche Schwerpunkte, was sich aber recht gut ergänzen dürfte: durch seine Arbeit am OParl-Standard hat Konstantin bereits viel Erfahrung mit der Modellierung von RIS-Daten und wird sich besonders um die Such-Funktionalität sowie das Backend kümmern, ich interessiere mich vor allem für die Geodaten, die Benachrichtigungs-Funktionalität sowie die Benutzerverwaltung und werde wohl auch größere Teile des Frontends übernehmen.

Generell ist das Ziel, ein Frontend für Ratsinformationssysteme zu schaffen, das sich aus den öffentlichen Daten eines existierenden RIS-Systems speist – Rechte-Verwaltung, interne Dokumente und dergleichen nehmen wir derzeit explizit aus – das sich möglichst einfach für andere Städte anpassen lässt. OParl wird dabei eine wichtige Rolle spielen, da es der einzige Standard ist, über den RIS-Daten maschinenlesbar ausgelesen werden können, was eine Voraussetzung für unser System ist (um nicht wie bei München Transparent für jede Stadt aufwändig einen Scraper schreiben zu müssen). Wir wollen das System dabei auf für mindestens eine Stadt prototypisch implementieren, schon alleine um die Vorteile unseres Systems anschaulich darstellen zu können. Welche Stadt das sein wird, werden wir aber erst evaluieren müssen.

PS: Die Bewerbungsphase für die dritte Runde des Prototype Funds läuft noch – wer also auch Open Source Anwendungen entwickelt und sich für eine Förderung interessiert, kann sich noch bis Ende September bewerben.

Seit diesem Jahr arbeite ich als regelmäßiger Freelancer bei der „Portal München Betriebs-GmbH“ – oder besser bekannt einfach als „muenchen.de“, also dem offiziellen Münchner Stadtportal.

Nikolaus Gradl, den ich schon seit seiner Stadtratszeit kenne, hatte mich als einer der Projektleiter dort eingeladen und mit einem Projekt geködert, bei dem ich nach München Transparent wohl ein recht naheliegender Kandidat war: der Web-Umsetzung der Münchner Rathaus Umschau, einer werktäglich erscheinenden „Zeitschrift“ der Stadtverwaltung, die neben einer Printversion bisher nur im PDF-Format erschienen ist. Die Herausforderung dabei war, das so in den bisherigen Prozess der Rathaus Umschau zu integrieren, dass dieser erst einmal weit gehend unverändert weiter laufen kann und das PDF auch weiterhin die „Referenzfassung“ bleibt. In der Praxis heißt das, dass die Web-Version hauptsächlich durch ein automatisiertes Parsen des PDFs erstellt wird. Das PDF wird dabei in die einzelnen Meldungen, Terminhinweise, Anträge usw. zerlegt, analysiert und dann veröffentlicht. Das ist sicher nicht die eleganteste Lösung (PDFs wieder zurück in Text umzuwandeln ist leider nicht ganz so komplikationsfrei wie man annehmen könnte), aber hier erst einmal das zweckmäßigste.

Da die PHP-Anwendungen im muenchen.de-Umfeld (der Kern von muenchen.de selbst läuft nicht unter PHP) hauptsächlich auf Laravel basieren, war das außerdem einmal eine gute Gelegenheit, mich damit intensiver zu beschäftigen – sonst hatte ich ja hauptsächlich mit Yii und früher noch mit Zend gearbeitet. Mein persönlicher Favorit bleibt aber bis auf weiteres Yii2. 😀

Ansonsten geht es technisch recht bislang recht abwechslungsreich zu: ein automatischer Konverter von HTML nach AMP war dabei, mit München 360° die Web-Umsetzung einer VR-App auf Basis des Tools krpano, und aktuell ein Projekt, bei dem ich einmal mit Angular2 und Typescript auf Tuchfühlung gehen kann. Typescript finde ich sehr cool, da ich inzwischen ein recht großer Freund statischer Typisierung bin. Mit Angular 2… komme ich auch langsam zurecht, auch wenn ich das 1er darin eigentlich gar nicht mehr wiedererkenne. Wahrscheinlich wäre es sinnvoller, darin gleich ein komplett unabhängiges, neues Framework zu sehen, und weniger einen Nachfolger von Angular 1. Für größere Projekte sehe ich auf alle Fälle die Vorteile gegenüber dem 1er, auch wenn es um einiges komplizierter erscheint.

Bei der demnächst neu erschienen Version 2.1 von OpenSlides hatte ich die Gelegenheit, auch ein paar wichtigere neue Funktionen beizutragen: die Zeilennummerierung, das Inline-Bearbeiten von Anträgen sowie die Verwaltung von Änderungswünschen inkl. Änderungsansicht. Alles sind natürlich Funktionen, von der Art, mit der ich bei Antragsgrün bereits Erfahrung gesammelt habe, auch wenn sich die konkrete Implementierung schon allein deshalb maßgeblich unterscheidet, dass sie bei Antragsgrün hauptsächlich serverseitig in PHP implementiert, während OpenSlides hauptsächlich AngularJS-basiert (mit minimalem Python-Backend) ist. Das hat Vor- und Nachteile: grundsätzlich ist das Interface von OpenSlides dadurch natürlich deutlich responsiver. Gerade bei den aufwändigeren Algorithmen (Zeilennummern und Änderungsansichten sind komplizierter, als man anfangs oft meint) und bei längeren Texten stellt das aber auch höhere Ansprüche an die Leistungsfähigkeit des Client-Rechners, und mindestens an einer Stelle konnten wir aus diesem Grund auch nicht die beste Implementierung wählen.

Spannend war auch das Erzeugen des PDFs auf Basis der JavaScript-Bibliothek PDFMake. Es ist einerseits cool, dass es überhaupt funktioniert, PDFs rein clientseitig im Browser zu erzeugen – andererseits sind wir auch an einige problematische Einschränkungen gestoßen. Wobei der Antragsgrün-Ansatz, auf LaTeX bzw. XeTeX als Backend fürs PDF-Rendering zu setzen, auch nicht unproblematisch ist.

Ich bin auf alle Fälle gespannt, wie es sich weiter entwickelt – und wie sich das Zusammenspiel zwischen OpenSlides und Antragsgrün weiterentwickelt. Anders als einige andere sehe ich die zwei Tools ja auch immer noch als eher komplementär zueinander, und weniger als Konkurrenz. Auf alle Fälle wird ein weiteres Betätigungsfeld sein, die Schnittstellen zwischen den beiden Tools weiter zu verbessern.