Update 1: “Verspätung für alle” – SZ berichtet über Zugmonitor

Ein Sonntag-Nachmittag und meine Freundin klettert demnächst in Hamburg in einen ICE um ein paar Stunden später wieder zu Hause zu sein. Natürlich hole ich sie vom Bahnhof ab. Nun wäre es gut zu wissen, ob der Zug Verspätung hat und wenn ja wie viel. Bei Flügen ist das eine Standard-Information und es gibt sogar Smartphone-Apps dafür. Für Züge der DB ist das irgendwie schwieriger, zumal unterwegs und kompakt.

Da gab es doch dieses Projekt Zugmonitor der SZ und Opendatacity, dass Ich mir mal ansehen wollte. In kurz zusammengefasst scrapt Zugmonitor die Website der DB und holt so die aktuellen Zeiten und Daten zusammen. Das wird dann entsprechend aufbereitet und ansprechend visualisiert. Und: die Jungs von Opendatacity stellen die Daten für Projekte zur Verfügung – klingt nach einem kleinen aber feinen Projekt für mich…

Zugmonitor

Ich mag dieses Projekt u.a. deshalb, weil ich finde, dass öffentliche Informationen auch entsprechend frei zur Verfügung stehen sollten, da man dann damit sinnvolle Dinge tun kann (Stichwort “Open Data“). Zugmonitor ist ein Paradebeispiel dafür.

Wie Zugmonitor genau funktioniert wird hier im folgenden Video kurz erklärt:

Ein paar Insights, wie es zu dem Projekt kam und wie es implementiert wurde hat Philip Banse anlässlich der re:publica 2012 in einem Interview mit Stefan Plöchinger (süddeutsche.de) und Lorenz Matzat (OpenDataCity) für dctp.tv gesammelt.

Link zum Beitrag bei dctp.tv

Für mein kleines Projekt ist der wichtigste Punkt bei Zugmonitor, dass die Daten unter http://www.opendatacity.de/zugmonitor-api/ per API für eigene, nicht-kommerzielle Projekte zur Verfügung stehen. Alle Stationen inklusive Geo-Koordinaten, sowie alle Züge werden an einer einfachen JSON-Schnittstelle bereitgestellt. Bei den Zügen kann man jeweils ihre Route auslesen und bekommt zu jeder Station geplante Ankunfts- und Abfahrtszeiten, sowie eventuelle Verspätungen mit Dauer und teilweise Grund – soweit dies von der DB angegeben wird.

Zugmonitor selbst ist schon sehr schön – allerdings für meinen Anwendungsfall etwas zu komplex. Ich wollte ja einfach nur wissen und auf dem Laufenden bleiben, ob und wieviel Verspätung ein bestimmter Zug hat. Das muss irgendwie kompakter gehen.

Aus Zugmonitor wird @ZugMon

Statt immer alle Daten einen Zuges auszugeben wie bei Zugmonitor, konzentriert sich @ZugMon auf die Abweichungen vom Normalen – den Verspätungen und entfallenen Halten. Dazu wird regelmäßig die Schnittstelle von Zugmonitor abgefragt und die Daten jedes Zuges mit den vorhergehenden verglichen um so die Änderungen zu identifizieren.

Die Verspätungsmeldungen werden dann über den Twitter-Account @ZugMon gepostet und enthalten die Zugnummer als Hashtag. Damit kann man auf Twitter einfach nach einer Zugnummer suchen und erhält die letzten Tweets dazu. Über den Namen der Stadt kann man die Suche weiter einschränken.

Im Idealfall erscheint ein eigener Tweet pro Zug und Haltestelle, um die Relevanz eines jeden Tweets möglichst hoch zu halten. So kann man auch unterwegs in einem Zug mitbekommen, ob man den nächsten Umsteiger noch erreicht oder nicht.

Und so sieht das dann aus: http://twitter.com/ZugMon

Tweets von @ZugMon

Probleme mit Twitter

Es wäre natürlich zu schön, wenn alles so läuft, wie man sich das denkt. Natürlich lässt mich Twitter nicht so viele Tweets absetzen, wie ich gern würde. Das Limit wurde da mittlerweile so dratisch runtergefahren, dass ich sogar in Nebenzeit konstant gegen das Rate Limit angelaufen bin. Mit der REST API 1.1 wurde das dann nochmal einen Zacken schärfer.

Die Anzahl der Meldungen mussten also deutlich reduziert werden. Erster Versuch: Konzentration auf ICE. Ich habe also alle anderen Meldungen erst einmal herausgefiltert und damit schon eine beträchtliche Reduktion erreicht. Gut, aber noch nicht gut genug. Immer noch schlägt das Rate Limit mindestens einmal pro Stunde zu – das geht so nicht.

Zweiter Versuch: mehrere Meldungen in einen Tweet zusammenfassen, wenn möglich. Hierbei geht dann zwar die Ein-Tweet-pro-Zug-und-Halt-Idee verloren, aber es ist ein Schritt in die richtige Richtung. Allerdings, zu viele Meldungen lassen sich nicht zusammenfassen, die Ersparnis ist eher mittel gut.

Dritter Versuch: Meldungsinhalt deutlich herunterkürzen. Konkret heißt das, dass die Links pro Zug rausfliegen, ebenso die Gründe für eine Verspätung und dass die Stationsnamen und Minutenangaben etwas komprimiert werden. Das reicht dann endlich, um auch in Spitzenzeiten noch alle Meldungen posten zu können. Im Schnitt passen nun 5 Meldungen in einen Tweet.

#ICE79 ZürichHB: Halt entfällt | #ICE635 HannoverMesse/Laatzen 35m | #ICE1517 JenaParadies 10m | #ICE1515 NürnbergHbf 5m

— ZugMon (@ZugMon) March 6, 2013

Wie gehts weiter?

Prinzipell funktioniert @ZugMon so erstmal stabil und postet fleißig die Verspätungsmeldungen aller ICE der DB. Meine Freundin wurde natürlich auch inzwischen vom Bahnhof abgeholt. Das Fehlen der anderen vom Zugmonitor unterstützten Zugtypen, sowie die der Meldungskürzung zum Opfer gefallenen Verspätungsgründe und die Direktlinks pro Zug sind noch nicht optimal – aber wie lösen?

Die Direktlinks sind im Twitter-Profil beschrieben und funktionieren nach dem Schema: http://zugmon.de/t/ice1515.

Für mehr Daten – z.B. auch wenn es einfach mehr Verspätungsmeldungen gibt – bräuchte man unweigerlich mehr Posting-Bandbreite. Das ginge bei Twitter selbst nur über mehrere Accounts, aber da würde Twitter wohl nicht offiziell mitmachen – man kann sich also nicht darauf verlassen.

Alternativen zu Twitter?

Da sieht es meiner Meinung nach noch etwas mau aus. Ich habe mal bei einigen Diensten rein geschaut.

Identi.ca scheint am naheliegensten, immerhin gilt es als Twitter-Clon. Theoretisch bietet Identi.ca auch genügend Posting-Bandbreite, allerdings verlangt das Projekt, dass alle Inhalte unter CC-Lizenz veröffentlicht werden und das kann ich nun mal nicht garantieren, schade. Außerdem ist das Ecosytem um Identi.ca nicht so ausgeprägt wie bei Twitter.

Tumblr ist etwas anders aufgestellt, eine Art gehostetes CMS für verschiedene Ausrichtungen, meist aber für (Foto-)Blogs benutzt. Zum Rate Limit habe ich erstmal keine offiziellen Daten gefunden, aber bei der alten API v1 gab es wohl ein Read-Limit von einem Request pro zehn Sekunden. Man kann sich also ausmalen, wie die Write-Requests aussehen. Je nach Aufwand gehen bei @ZugMon in einer Minute gerne mal zwischen 2-5 Posts raus.

App.net klingt interessant und hat auch klare Ansagen zu den Rate Limitings. Auch der Ansatz, das Produkt an die Nutzer und nicht die Nutzer an die Werbetreibenden verkaufen zu wollen, kommt bei mir gut an. Allerdings ist der Developer-Zugang mit 100$ im Jahr eben nicht geschenkt und es fehlt tatsächlich noch die Marktdurchdringung, wie dies bei Twitter eben noch der Fall ist.

Eigene Website mit Stream bespielen. Über diesen Weg würde wohl noch am meisten gehen. Die Daten liegen im Prinzip ja eh schon vor und man könnte auch andere Dienste nachlagern/ankoppeln, z.B. Push-Notifications usw. Allerdings geht das auch erstmal deutlich über das eigentliche Ziel, kurz und kompakt Verspätungsinformationen abrufen zu können, hinaus.

Ich werde also mal die Augen offen halten, in welche Richtung es noch weiter gehen könnte. Wenn Ihr noch Ideen und Anregungen habt, höre ich die gerne – natürlich auch Kritik und Verbesserungsvorschläge.