Schlagwort-Archive: SWU

Langsam laeufts an

Seit eineinhalb Wochen gibt es nun offiziell die Soll-Fahrplandaten von den Stadtwerken unter freier Lizenz, und langsam faengt auch die Adaption und Integration in anderer Leute Werkzeuge an. Stefan Wehrmeyer hatte ja noch am Abend des VBB-EntwicklerInnen-Nachtreffens den Datensatz beantragt und Mapnificent entsprechend erweitert; mittlerweile hat auch Knut aus Berlin sein Werkzeug umgebaut, mit dem er die Haltepunkte aus dem GTFS-Feed mit den Haltepunkten in der OpenStreetMap vergleicht. Damit einhergehend kam auch gleich der erste Bug Report zum Feed, den ich heute mittag auch gleich loesen koennte — der bisherige Transformationswerkzeugkasten ist ein wenig codierungsagnostisch, so dass versehentlich UTF-8-codierte Zeichen in ASCII-Textdateien landeten.

Ein weiteres kleines Werkzeug habe ich aus der Ergebnispraesentation des VBB-EntwicklerInnen-Nachtreffens mitgenommen, das auch schnell auf Ulm adaptiert war: Analog zu Mapnificent eine Erreichbarkeitskarte, die Kreise mit waehlbarem Radius um Haltepunkte zeichnet und so anzeigt, wie „erreichbar“ der Nahverkehr in der Stadt ist. 800 Meter (der vorgegebene Wert aus Berlin) umfassen gleich quasi ganz Ulm, interessanter waere da die Abbildung des ganzen DING-Verbunds — die Daten hab ich zwar schon lange, aber leider nicht unter freier Lizenz 😉

Ein weiterer Kritikpunkt sowohl von Mapnificent als auch dieser Erreichbarkeitskarte ist ihre… begrenzte Aussagefaehigkeit (um den Begriff „Unsinnigkeit“ zu vermeiden :D). Konzentrische Kreise bilden quasi nie die Gehdistanz von/zu einem Haltepunkt ab. In einer typischen US-amerikanischen Planstadt waeren Rauten passender, in typischen europaeischen Staedten sieht es meist von Haltepunkt zu Haltepunkt anders aus. Hier mal eine Karte mit tatsaechlichem Fussgang-Routing zu bauen, das waer mal was 😉

Ein ereignisreiches Open-Transit-Wochenende

tl;dr vorneweg: Wir waren am Donnerstag beim DING-Verbund, am Freitag war ich beim VBB in Berlin, und die SWU geben ihre Fahrplaene als GTFS frei. Hurra!

DIVA-Allueren

Auf Einladung von Martin Schiller vom DING waren Fox und ich am Donnerstag beim DING als „unserem“ Nahverkehrsverbund zu Besuch und haben uns deren Software zeigen lassen. In Deutschland gibt es nur wenige grosse Player auf dem Markt fuer Fahrplanungs- und Auskunftssysteme, beispielsweise HaCon (HAFAS) und MentzDV (DIVA und EFA), wobei in BaWue hauptsaechlich DIVA fuer die Fahr-, Dienst- und Umlaufplanung und EFA fuer die elektronische Fahrplanauskunft zum Einsatz kommen.

Und wie das in einem kleinen Markt so ist, reissen die dazu gehoerenden Softwareloesungen nicht gerade vom Hocker. DIVA verwendet in Version 3 als Datenbackend nicht etwa einen Standard wie VDV-45X, sondern ein eigenes Textdateiformat, das ich auch nach laengerem Betrachten noch nicht so recht umrissen habe. In DIVA 4 soll wenigstens eine Datenbank im Hintergrund laufen, auf die neue Version seien bislang aber wohl nur wenige Verkehrsverbuende und -betriebe umgestiegen.

Verkehrsbetriebe benutzen solche Planungssoftware ohnehin erst ab einer bestimmten kritischen Groesse ihres Betriebs. Viele der kleineren Dienstleister verwenden entweder ganz andere Umlaufplanungssoftware, oder machen das gar von Hand oder in Excel. Der „einfache“ Transfer von DIVA zu DIVA kommt hier bei uns nur zwischen Stadtwerken und DING zustande, kleinere Anbieter auf dem Land schicken ihre Plaene im besten Fall per XLS, im schlimmsten in sonstigen semistrukturierten Formaten.

Eine weitere Hoffnung fuer den Export der Fahrplaene nach GTFS war, die Daten aus der Datenhaltung der Elektronischen Fahrplanauskunft (EFA) herauszubekommen. Die ist aber nicht minder… spannend. Die Dateien sehen wie Binaerblobs aus, und die EFA selbst ist ein Konglomerat zusammengeflanschter Module, die sehr nach historischem Wachstum aussehen. Die Echtzeitauswertung heisst beispielsweise „rud“ und lehnt sich damit noch ans Projekt RUDY an, das 2004 zu Ende ging. Und zwischendrin poppen auf dem Windows-Server-Desktop, auf dem die EFA laeuft, Adobe-Distiller-Fenster auf, wenn irgendjemand einen PDF-Fahrplan erstellt.

Spaetestens an der Stelle stellte ich mir dann schon die Frage, ob man mit geeigneten freien Software-Werkzeugkaesten nicht viel reissen koennte in diesem Orchideensektor 😀

Nichtsdestoweniger, der Ausflug war interessant, und zeigte auch, dass die CSV-Dateien, die wir von den Stadtwerken bekamen, genauso fuer den gesamten Verbund (und einigem haendischen Aufwand) aus DIVA exportiert werden koennten. Das waere aber tatsaechlich nicht unbedingt die Loesung, sondern vermutlich erst der Anfang weiterer Probleme, angefangen vom Unterschied zwischen Planungs- und Repraesentationsliniendarstellungen bis hin zu eindeutigen Schluesseln fuer Haltepunkte.

Ausflug zum VBB und endlich Ulmer GTFS-Daten 🙂

gtfs

Tags darauf hatte die Open Knowledge Foundation zusammen mit dem Verkehrsverbund Berlin/Brandenburg (VBB) zur Projektvorstellung und Nachbesprechung des Hackdays im November 2012 eingeladen. Da unsere Arbeitsgruppe nach wie vor kein Reisebudget oder ueberhaupt irgendwelche Finanziers hat, hiess das also, um 0600 Uhr aufzustehen und mit dem Daumen nach Berlin zu reisen :>

Aufgrund meiner etwas unguenstigen Anreise (siehe Trampbericht unten) kam ich leider erst nach der ersten Projektvorstellungsrunde in den VBB-Raeumen am Bahnhof Zoo an, war aber sehr angetan vom grossen Andrang dort. Neben OKFN und VBB sassen dort Leute von der BVG, jemand von HaCon war eigens angereist, und ich konnte neben „alten Bekannten“ auch endlich mal Michael Kreil und anderen persoenlich die Hand schuetteln.

Eine ganz persoenliche Freude war mir, dort spontan eine Botschaft verkuenden zu koennen, auf die ich lange gewartet hatte: Auf der Anreise bekam ich den Link zum Datenauskunftformular der Stadtwerke Ulm zugeschickt, die wir nun ueber mehrere Monate lang begleitet haben, um ihre Soll-Fahrplaene nach GTFS zu exportieren. Leider mit einem Formular zum verpflichtenden Ausfuellen, aber das war ich dann doch durchaus bereit in Kauf zu nehmen, nachdem im Gegenzug die ODbL als Lizenz gewaehlt wurde 🙂

okfbuero

 

Es werden sich jetzt sicherlich nicht auf einmal™ tausende EntwicklerInnen auf den Ulmer Fahrplan stuerzen. Auch in Berlin passierten seit der Veroeffentlichung des VBB keine Instant-Wunder. Aber das ist meines Erachtens ein bedeutender Schritt und hoffentlich positive Signalwirkung fuer andere Verkehrsbetriebe, ebenfalls die Daten bereitzustellen.

Dementsprechend haben wir nach der Vorstellung das Ganze noch im OKF-Buero (siehe Bild) mit Mate und spaeter Bier begossen und uns noch solange darueber unterhalten, wie man das Thema weiter beackern koennte (wissenschaftliche Aufarbeitung, Hinweis auf das Kundenbindungspotenzial unabhaengiger Apps), bis ich endgueltig koerperlich so fertig war, dass ich mich endlich mit Gastgeber @_HeBu treffen musste, um unfallfrei ins Bett zu kommen.

(Das wurde dann durch einen Spaetibesuch und tags darauf durch einen Doener- und Spaeti-Besuch erfolgreich unterbunden. Trotzdem Danke, HeBu, fuer die neuerliche Gastfreundschaft und den ausgezeichneten Vanillequark von Butter-Lindner :D)

Trampstatistik

Hinweg:

  • Abfahrt Rosengasse mit der Linie 4 um 0706 Uhr(?), Ankunft Eichenplatz 0716 Uhr, wo nix los war.
  • Eichenplatz ab 0742 Uhr (26 Minuten) mit Margarete ehemals aus der Nachbar-WG, die anbot, mich generell unter der Woche immer um die Zeit auf die Lonetal nehmen zu koennen. Cool.
  • Ankunft auf einer total verlassenen Lonetal Ost um 0759 Uhr. Erst an der Ausfahrt gestanden, dann angequatscht, trotzdem erst um 0900 Uhr weiter (61 Minuten). Dafuer im Geschaeftsauto im Tiefflug, 137 km in 67 Minuten.
  • Kammersteiner Land Sued an 1007 Uhr, wenig los, angequatscht, 1047 mit 120 km/h und haeufigen Raucherpausen weiter (40 Minuten)
  • Taktischen Fehler begangen, nicht waehrend der Mittagessenspause meiner Fahrerin in Frankenwald Ost einen neuen Lift zu suchen.
  • Michendorf Süd an 1605 Uhr, machte mal eben 5:18h fuer 408 km. Trotz guter Unterhaltung etwas schade.
  • Weiter um 1620 (15 Minuten) bis zur U Kurfuerstenstrasse um 1710 Uhr, Fussmarsch bis zum Bf Zoo/VBB.

Rueckweg:

  • Aufbruch bei HeBu mit der S1 ab Wollankstrasse um 1313, S Johannissee an 1400 Uhr. An der Grunewald erst ein wenig rumgeschaut und angequatscht, das lief aber nicht. Also um 1430 mit Schild „Muenchen A9“ ab auf die Rampe, 1440 Lift bekommen 🙂
  • Fraenkische Schweiz/Pegnitz West an 1730 Uhr, d.h. 362 km in 2:50 Minuten und hervorragender Unterhaltung waehrend der Fahrt ueber die Unterschiede zwischen PaedagogInnen und ErzieherInnen 😀
    Sanifair-Gutscheine gegen Burger getauscht, 1750 mit Schild „Ulm“ an die Ausfahrt gestellt, 1804 Lift bis Bahnhof Heidenheim angeboten bekommen. Da sagt man nicht nein 🙂
  • Bf Heidenheim an 1942, 197 km in 1:38h. Das waren rekordverdaechtige 5:12h von Grunewald bis Heidenheim, und selbst mit S-Bahn vorneweg und den 50 Minuten Regionalexpress nach Ulm am Ende gerade mal 45 Minuten langsamer als ein ICE gewesen waere 😀

Erste Schritte in QGIS

Ich schlage mich nun seit einigen Tagen bzw. Wochen damit herum, aus diversen Zwischenprodukten von DIVA einen funktionierenden GTFS-Datensatz zu bauen — beziehungsweise, einen Prozess zu bauen, mittels dessen die Stadtwerke das zukuenftig selber tun koennten, wenn sie das wollten. Die Fahrplaene sind dabei momentan das kleinste Problem, die koennen gemaess der Vorlage per rudimentaerem Hacktool automatisch aus den TSV-Dateien ueberfuehrt werden, die die SWU fuer den Satz ihrer Pocketfahrplaene verwendet.

Mehr Probleme machen derweil die scheinbaren Kleinigkeiten, die es in sich haben. Die Haltestellenorte hat einfach mal jemand irgendwo vom Server des Nahverkehrsverbund geparst. Die koennte man nehmen — dann waer’s aber nicht mehr sauber, weil die Datenquelle einer Nutzung unter freier Lizenz bislang nicht zugestimmt hat. Dasselbe gilt fuer die Fahrwege der Busse — die holt swu2gtfs bislang auch einfach aus der elektronischen Fahrplanauskunft des Verbunds.

Fuer beides habe ich testweise auch die Daten der Stadtwerke zur Verfuegung gestellt bekommen, die aber nur noch mehr Folgefragen aufwerfen. Eine Linie kann im Tages- und Wochenverlauf zig verschiedene Fahrwege haben, je nachdem, wo sie anfaengt, wo sie endet und welche Haltestellenreihung sie nimmt. Die haendisch zuzuordnen ist… aufwaendig. Noch umstaendlicher wird es bei den Haltepunkten: Die sind zentimetergenau vermessen — und zwar pro Haltepunkt, derer es pro Haltestelle gleich mehrere geben kann. Klar: Die meisten werden ja in zwei Richtungen bedient, und kompliziertere Halte wie der am Theater haben auch mal vier Steige, zwischen denen bis zu 50 Meter liegen.

Ich habe die KML-Dateien dann einfach mal in QGIS geladen und war ganz angetan, das auch mal im Ueberblick sehen zu koennen. Wunderbare freie Software, die per OpenLayers-Plugin auch gleich eine passende OpenStreetMaps-Hintergrundkarte einbinden koennen und vieles mehr.

Ich bin mir momentan noch nicht ganz sicher, wie ich hier weitermachen soll. Mehr oder minder ideal waere es, pro Haltestelle die mittlere Koordinate aller Haltepunkte zu berechnen, die dann als „virtuelle“ Oberhaltestelle aller Haltepunkte dient (Beispielsweise OLIF 9001010 fuer das Theater). Das ist eine eher krude Approximation und wird vor allem dann haesslich, wenn (wie aktuell) die Fahrplaene nicht den Steig angeben, von dem sie abfahren (z.B. 90010103 fuer die 6 in Richtung Uni, die am Theater-Steig 3 abfaehrt). Die Alternative ist, einfach immer den ersten Steig zu kopieren und als Oberhaltestelle zu definieren, um dann ggf. mit noch kruderen Abweichungen zu leben — aber hey, wenigstens eine Fahrtrichtung stimmt dann immer exakt. Naja.

tl;dr: QGIS scheint toll zu sein, es laesst einen Karten wie die obige machen. Geoinformationshackerei kann Leute in den Wahnsinn treiben.

Wie schwer es fallen kann, Fahrplaene zu oeffnen

Wer die letzten Tage halbwegs aufmerksam im Netz unterwegs war, hat vermutlich diese Schlagzeile gesehen: OpenPlanB hat mal eben saemtliche deutschen Fahrplandaten gezogen und als Torrent verteilt. Deswegen mal ein kurzer Statusbericht zum Thema aus Ulm.

Klar, in Sueddeutschland dauert alles ein wenig laenger. Seit einigen Jahren versuchen hier einige StreiterInnen, an die Echtzeitdaten der Busse und Strassenbahnen zu kommen, um damit tolle Dinge™ bauen zu koennen. Anfangs hatte Fox einen Parser Pseudo-Anfragen an die Fahrplanauskunft stellen lassen, spaeter gab es dann sogar ein Frontend dafuer, und irgendwann wurde auch klar, dass der Nahverkehrsverbund DING die EFA von mentzdv laufen hatte, zu der es auch eine schoene Schnittstellendokumentation aus Linz gibt.

open Data im ÖPV from c-base on Vimeo.

Darueberhinaus hatten wir aber so etwa das im obigen (leider sehr zerhackstueckelten) Video von Michael Kreil umrissene Problem: Wir kamen nicht an die Referenz-Plandaten heran. Der Verkehrsverbund erzaehlte uns, dass wir keinesfalls einfach so Zugriff darauf bekommen koennten, und generell hielt man uns wohl fuer ahnungslose Irre.

Als Tueroeffner fuer die Kommunikation zumindest mit den Ulmer Stadtwerken bot sich unsere in einem Wochenende zusammengehackte Pseudo-Livemap samt der an einigen Stellen der Uni haengenden Live-Busanzeige an, ueber die wir tatsaechlich innerhalb kuerzester Zeit Kontakt zum Verantwortlichen fuer die Datenhaltung bekamen.

(Anekdoteneinschub: Besonders beeindruckt waren die Verantwortlichen den Erzaehlungen nach davon, dass Fox fuer seine Auskunftsseiten die XML-Schnittstelle benutzt hatte, von deren Existenz offenbar niemand oder kaum jemand beim Verbund ueberhaupt wusste)

Wir dachten nun jedenfalls, dass mit dem direkten Draht zu den Stadtwerken in kuerzester Zeit ein GTFS-Satz fuer die Ulmer Linien gebaut werden koennte, womit Ulm als womoeglich erste deutsche Stadt beispielsweise in Google Transit auftauchen koennte.

So einfach war das aber nicht.

Und das ist auch die groesste Huerde ueberhaupt, wenn man an solcherlei Daten herankommen moechte. Die gesamten Plandaten liegen auf irgendwelchen Betriebsleitrechnern in irgendeiner Planungs- und Betriebsleitsoftware. Da gibt es einige wenige Haeuser, die so etwas herstellen, und es handelt sich soweit wir das sehen koennen um proprietaere Pest. Schnittstellen gibt es, die folgen der VDV-454, und ich weiss auch nach intensiver Lektuere der besagten Schrift noch nicht so recht, wie man daraus irgendetwas stricken sollte, das auch wirklich sinnvoll ist. Michael Kreil bzw OpenPlanB haben wohl in grossem Umfang Hafas-Dumps und reihenweise Fahrplanauskunftdaten gezogen, um sich daraus eine deutschlandweite Datenbank zu stricken. So etwas dachten wir uns anfangs auch, erkannten aber relativ schnell, dass wir selbst fuer den relativ kleinen DING-Verbund zigtausende Abfragen stellen muessten, um hinterher auch ein reales Abbild der Soll-Fahrplaene ueber das Jahr hinweg zu bekommen.

Um ein Gefuehl dafuer zu bekommen, was mit den Daten moeglich waere und somit Tueroeffner zu spielen, taugt dieses Prinzip aber, und die Visualisierungen sind schon wunderbar anzusehen. Uns stand aber der Sinn nach einer Moeglichkeit fuer die Stadtwerke, damit diese zukuenftig selber ein valides GTFS-Set unter Beruecksichtigung aller Sonderfahrplaene ins Netz stellen koennten.

Der Weg, den wir momentan dabei beschreiten, ist ein relativ absurder: Es gibt offenbar irgendeine Schnittstelle, an deren Ende CSV-Tabellen fuer eine Person herauskommen, die diese dann in die gedruckten Fahrplaene giessen darf. Da diese Plaene einem bestimmten Muster folgen, kann man sie mit einem sehr kruden Parser nach GTFS umschreiben und dabei gleich per EFA-Schnittstelle die Fahrwege abfragen und mit einbinden. Leider fehlen hier am Ende immer noch viele Daten, die mit an Sicherheit grenzender Wahrscheinlichkeit irgendwo im DING- bzw. SWU-System abgebildet sind: Gefahrene Distanz an einer Haltestelle, Tarifstrukturen und vieles mehr. Ausserdem muessen auch alle Kalenderbesonderheiten nochmals von Hand nachgetragen werden.

Wenigstens sind wir aber so weit, seit dem Fruehjahr ein grundliegendes GTFS-Set exportieren zu koennen, und nachdem ich mich vor einigen Tagen noch einmal daran gesetzt habe, auch die Fahrwege darin abgebildet zu haben, so dass Ulm nun wohl die zweite deutsche Stadt mit einer Mapnificent-Karte ist und wir hoffentlich demnaechst einmal mit den Stadtwerken besprechen werden, ob und wie wir zum Fahrplanwechsel 2012 tatsaechlich auch ein „offizielles“ Ulmer GTFS-Set veroeffentlichen koennen.

Vielleicht hilft das manchen enthusiastischen OePNV-Fans zu verstehen, warum nicht immer alles so schnell geht, selbst wenn alle beteiligten Stellen eigentlich so etwas wollen. MentzDV bietet anscheinend sogar mittlerweile einen GTFS-Export an — man darf sich aber ausrechnen, dass das hierfuer zuzukaufende Modul nicht kostenlos sein wird.

PS: Wir sind hier in Ulm in der etwas einmaligen und manchmal etwas peinlichen Situation, den umgekehrten Zustand wie in Berlin zu haben. Plakativ geschrieben rennen wir offene Tueren ein und werden mit Daten ueberhaeuft, haben aber zu wenige MitstreiterInnen, um mit all diesen Daten auch etwas anfangen zu koennen. Wir haben hier keine c-base und keine re:publica, aber es gibt Mate und ne Donau und ab und zu ein OpenCityCamp. Falls ihr also schon immer mal die Welt veraendern wolltet: Das geht auch hier. Und man muss sich bei den Buffetts nicht immer mit @mspro um die Schnittchen pruegeln. Kombt alle forbei, es gibt einen noch zu visualisierenden Haushalt, eine zu verbessernde mobile Nahverkehrs-Liveabfrage, Entsorgungsdaten und noch viele andere Kleinigkeiten.¹

(¹ Auf Anregung von @plomlompom soll ich schreiben, dass Berlin eine „HipsterHölle [ist], wo man nix mehr produzieren muss, um Anerkennung zu kriegen. Hier unten dagegen beweisen sich die wahren Hacker!“)

Die Stadtwerke machen Social Media

Ausnahmelagen sind die Momente, in denen das Echtzeitnetz brillieren kann. Heute streikten die BusfahrerInnen der Stadtwerke Ulm bis etwa 1430 Uhr, was auch bereits in den grossen Medien der Region angekuendigt wurde.

Von einer tatsaechlichen medialen Begleitung des Ausstands hatte ich wenig mitbekommen — tatsaechlich war es hauptsaechlich Selbsthilfe der Betroffenen auf Twitter, beispielsweise durch das von @taxilof schnell auf die Lage angepasste Haltestellenscript, mit dessen Hilfe man herausfinden konnte, wann der naechste von der (nicht streikenden) RBA betriebene Bus des Umlaufs 3/5 kommen wuerde, der einen an die Uni bringt. Das wurde dann noch ein wenig untereinander verteilt, und ueber @ulmapi twitterte ich, als auf einmal wieder Ist-Daten der rollenden Busse eintrafen, ansonsten schien es aber ruhig an der Social-Media-Front.

Erst gerade vorhin sah ich durch Zufall, dass die Stadtwerke eine ansehlich gepflegte Facebook-Praesenz haben — auf der sich nicht viel zum Streik fand, aber immerhin alle Rahmendaten und die Information, als es wieder weiterging. Und Videos, die es zwar auch dilettieren, dafuer aber menscheln liessen.

Man kann sich jetzt wieder fragen, ob das so toll ist, wenn diese Informationen auf der Facebook-Seite mit wenigen hundert Fans, aber nicht auf der offiziellen Unternehmensseite zu finden ist. Halt, ich nehme das zurueck: Das ist eigentlich ziemlich beschissen. Dass dort aber etwas geht, und vor allem dass auf jeden einzelnen Kommentar reagiert wird, finde ich respektabel.

Da koennte sich manch andere Instanz eine dicke Scheibe abschneiden.

Bleisatz und Untergrundparty

Letztes Jahr hatte ich die Schnauze von der Ulmer Kulturnacht ziemlich voll. Wlada war zu Besuch und wir hatten es geschafft, fast ausschliesslich „Kunst“ auf niedrigstem Niveau zu besuchen. Teilweise hatte das Kerkelingsche Zuege, wenn eine Autorin grottenschlechte Prosa vortrug, und das Publikum sichtbar pflichtergriffen war, weil das ja Kunst sein musste. Stand ja im Programm. HURZ!

Ich bin immer noch nicht wieder ganz warm mit der Kulturnacht — auch 2011 bekommt man immer noch keine benutzbare Website hin, und die Regeln fuer Veranstalter haben einige Aktionskuenstler in meinem Bekanntenkreis davon abgehalten, selbst teilzunehmen. Wurscht: Dieses Jahr bin ic hnaemlich bei drei wunderbaren Sachen gelandet.

Die Autos aus Langenau hatten eine der alten Ulmer GT4-Strassenbahnen fuer sich, in der sie batterieverstaerkt Livemusik spielten und (leicht unterstuetzt von der huepfenden Mitfahrbesatzung) pro Rundfahrt fuenf Kisten Bier leerten.

Mit bunten Lichtern an der Decke. Und geiler Atmosphaere. Ich will sowas oefter haben! Gerne auch mal einen Poetry Slam, oder ein Wohnzimmerkonzert einer schicken Band, die sonst im Sauschdall spielen wuerde… warum eigentlich nicht?

Zweiter Stopp war in der Pionierkaserne, wo ich endlich einmal die dortige Druckwerkstatt besichtigen konnte. Ich bin verliebt. Die haben dort Heidelberger Tiegel, koennen Lithographieren und haben zig Setzkaesten voller Bleilettern — auch in meiner Lieblingsschrift <3

Man sagte mir, dass man dort auch gerne mal Plakate drucken koennte. Reizt mich schon irgendwie, noch einmal ein Plakat fuer eine Uniparty aufzulegen… im klassischen Bleisatz auf einem Tiegel… rawr 🙂

Zum Abschluss waren wir dann wieder mal in einem Luftschutzraum. Dieses Mal der Haus-LSR eines WG-Hauses, der zum Partykeller umgemodelt wurde und nun eben auch zur Kulturnacht offen hatte. Das ist der sagenumwobene Keller, in dem immer mal wieder Goa-Partys stattfanden, fuer die man eben „Leute kennen musste“, oder eben zum richtigen Zeitpunkt an der Tuer vorbeikommen und eingeladen werden. Dort treiben sich mittlerweile zu meiner Belustigung auch ganz viele Leute aus meinem Heimatdorf herum, von denen die meisten irgendwie nach Berlin migriert waren oder so aehnlich.

Ich fuer meinen Teil bin mit der Kulturnacht wieder ein wenig versoehnt. Das fuehlte sich naemlich ganz vernuenftig nach Berlin an, an dem Abend.

Jetzt sollte das nur mal oefter so sein…

Mein erster Hackathon

Nach der Idee von Benjamin habe ich am vergangenen Wochenende tatsaechlich an meinem ersten Hackathon teilgenommen. Das ist tatsaechlich in etwa so, wie man sich das klischeeweise vorstellt: Man verbringt beinahe 48 Stunden mit seinem Team und stellt in der Zeit etwas auf die Beine.

In unserem Fall eine Livekarte der Stadt Ulm mit den Nahverkehrslinien 1, 3/5 und N1–N8. Auf denen sich die Busse live bewegen. Awesome.

Unser Team bestand aus Benjamin, cmichi, Fox und mir, musste gemaess der Regeln des Nodeknockout-Wettbewerbs node.js verwenden und hatte genau 48 Stunden Zeit, etwas auf die Beine zu stellen. Klar, dass wir vor unserem ulmapi-Hintergrund irgendetwas in der Richtung offene Daten und Nahverkehr machen wollten 😉

 

„Tatort“ war das Students‘ Lab der Fachschaft Elektrotechnik, wo wir dankenswerterweise von Samstag frueh bis Montag frueh arbeiten und zum Teil auch schlafen durften.

Aber von Anfang an.

Livevisualisierungen sind jetzt keine bahnbrechende, neue und revolutionaere Sache (mehr), das gibt es schon eine ganze Weile. Wir hatten uns aus zwei Gruenden trotzdem dazu entschlossen, so etwas umzusetzen:

  1. Es ging beim Contest um node.js, was insbesondere fuer Benni und Michi eine ziemlich erotisierende Wirkung hat aktuell sowas wie eine Lieblingssprache ist. Zudem baut die Loesung auf freien(!) Frameworks auf, im Gegensatz zum Beispiel zu Google Maps, was man hier ja immer mal wieder sieht
  2. Wir wollten uns einmal selbst „so richtig“ mit der General Transit Feed Specification (GTFS), dem Quasi-Standard fuer maschinenlesbare Nahverkehrsdaten, auseinandersetzen. Ich hatte mich schon vorab immer mal wieder in den Standard eingelesen, jetzt sollte es aber ans Eingemachte gehen.

Womit wir dann schon gleich beim grossen Problem waren.

I can haz GTFS feed, plz?

Unsere Nahverkehrsanbieter (DING fuers Umland, SWU fuer die staedtischen Linien) bieten einfach nichts dergleichen an. Waehrend das Frontend dank der freien Leaflet-Bibliothek und dazu passenden huebschen OpenStreetMap-Karten in kurzer Zeit aufgebaut war, mussten die notwendigen Betriebsdaten erstmal muehselig von Hand zusammengebaut werden.

(An dieser Stelle moechte ich noch einmal erwaehnen, wie toll ich Leaflet und auch die Cloudmade-OSM-Karten finde. Wie neulich hier schon geschrieben: Die freien Dienste muessen gut aussehen, und mit der Leaflet/Cloudmade-Kombination sieht OSM einfach rattenscharf aus und bedient sich erstklassig.)

Ja. Die Fahrplandaten. Das klingt jetzt wirklich archaisch, aber: Alles, was momentan auf der Livekarte zu sehen ist, ist datenseitig mit viel Handarbeit zusammengestueckelt worden. Mittels einiger Skripte konnten wir die Shapefiles der Busrelationen aus der DING-Fahrplanauskunft extrahieren, und die Relationen selbst (also der Plan, welche Fahrgastfahrt der Linie X um welche Zeit von A nach B faehrt und wo sie ueberall haelt) ist aus den PDF-Fahrplaenen der SWU zusammengebaut. Das ist haesslich, das war verdammt zeitaufwaendig, aber es ist zumindest halbwegs vollstaendig.

Wenigstens die Nachtbusse sind tatsaechlich zu 100% und auch korrekt nach GTFS ueberfuehrt. Immerhin. Dafuer fahren sie auf der Karte auch jede Nacht 🙂 (siehe unten)

Da stimmt aber noch irgendetwas nicht…

Ja:

  • GTFS sieht ziemlich genaue Unterscheidungen vor, welche Services wann fahren. Auf der aktuellen Karte fahren aber auch die Busse, die (korrekterweise) dem Service „university“ angehoeren, also eigentlich nur an Vorlesungstagen fahren. Unser Parser ignoriert das momentan und laesst alles fahren, was er an Daten vorliegen hat: Alles, was Montag bis Freitag an einem Vorlesungstag ausserhalb der Schulferien auf besagten Linien faehrt. Und die Nachtbusse 😉
  • Einige Sonderrelationen sind noch nicht abgebildet. Linien die spaet abends nur freitags fahren, oder nur freitags nicht, dafuer Montag bis Donnerstag. Sorry. Kuerze der Zeit. Die Rohdaten aus den Fahrplaenen sind aber mittlerweile halbwegs so aufbereitet, dass man sie fuer einen kompletten GTFS-Datensatz umparsen koennte. Stattdessen koennte man aber auch eine Datensammlung aus der DING-Onlinefahrplanauskunft machen.

Ich bin mir momentan nicht sicher, was die „beste“ Loesung ist, um endlich einen vollstaendigen GTFS-Datensatz fuer die SWU-Linien inklusive aller Sonderfaelle zu bekommen (im Dezember ist uebrigens wieder Fahrplanwechsel…), aber klar ist: Ideal waere eine vernuenftige Originalquelle direkt vom Verkehrsdienstleister. Vielleicht haben wir mit der Karte ja nun weiteres Interesse bei den Stadtwerken geweckt 🙂

Nachtrag am 31. August

Einige Dinge waren wohl trotz der „About“-Seite nicht so ganz klar, und andere habe ich vergessen zu erwaehnen:

  • Warum fahren da Busse, die da nicht fahren sollten? — Die GTFS-Scrapedaten unterscheiden zwar zwischen Nachtbusterminen und Wochentagen, der Parser diskriminiert hier aber nicht. Das heisst zum Beispiel, dass die Nachtbusse jede Nacht fahren, und auch trotz vorlesungsfreier Zeit die Sonderfahrten zwischen Science Park II und Ehinger Tor auf der Karte unterwegs sind
  • Warum fahren die Busse laenger, als sie sollten? — Der no.de-Server laeuft auf UTC, waehrend Ulm momentan auf UTC+2 liegt. Tatsaechlich sieht man also, was vor zwei Stunden los war. Das ist wegen der zyklischen Plaene tagsueber nicht so schlimm, schoen aber natuerlich auch nicht.
  • Warum macht der Bus beim Umlauf 3/5 keine Klinikpause? — GTFS sieht hier vor, fuer jeden Halt eine zurueckgelegte Strecke auf dem Streckenshape zu hinterlegen. Das auszurechnen war in den 48h nicht moeglich (zum Vergleich: Alleine die Linie 3 hat bei uns momentan fuenf verschiedene Shapes fuer alle moeglichen Start-Ziel-Kombinationen). Die Position wird momentan nur relativ krude ueber Start- und Zielort sowie vergangener Zeit approximiert.
  • Warum verwendet die Karte keine Echtzeitdaten? — Uns war es wichtig, hier auf den offenen Standard GTFS zu setzen. Was in den 48h herausgekommen ist, ist zwar keine wirklich saubere Loesung, kann aber noch so weit „gesaeubert“ werden, dass am Ende ein vollstaendiger GTFS-Datensatz verwendet wird, und eben keine Flickschusterei mit manipulierten Fahrauskunft-Anfragen, die man dann minuetlich fuer alle Relationen aktualisieren muesste.

    Es gibt mittlerweile die Erweiterung GTFS-Realtime, die mit Echtzeitdaten umgehen kann. Mit diesen Daten koennte man sogar soweit herunterbrechen, dass angezeigt wird, welcher Bus da jetzt gleich kommen wird (Kennzeichen, dadurch dann z.B. auch, ob es ein Gelenkbus, Standardbus, Viertuerer, Dreituerer, klimatisiert… ist). All das setzt aber erst einmal voraus, dass wir irgendwann einen GTFS-Volldatensatz von den SWU bekommen. Und darum geht’s jetzt erst einmal.

SWU-Daten: Es geht voran

SWU-01

Die Aktion mit den Gruenen-Mails hat offenbar doch noch einen positiven Nebeneffekt: Ich habe den Verschicker in seiner Eigenschaft als SWU-Beirat gebeten, doch nochmal nachzuhaken, ob es nicht doch irgendwann eine API fuer die RBL-Echtzeitdaten geben wuerde. Die Rueckfrage seitens der SWU, was so eine API denn kosten wuerde, konnte ich natuerlich nich tzufriedenstellend beantworten — ich freue mich aber, dass das Thema langsam Gehoer zu finden scheint.

Bis dahin gibt es die leider etwas ungenauen, aus der Fahrplanauskunft geparsten Daten ueber die Selbststrick-API von Taxilof, und als Beispiel-Mobilanwendung fuer Mobilgeraete die Auskunft von Claus.

Auf die Fahrgaeste hoeren kann man aber auch nicht

Interessant: Nachdem sich ein Student bei der SWP ueber die stets ueberfuellten SWU-Busse zur Ulmer Wissenschaftsstadt beschwert hat, zeigt man sich dort so, als mache man alles, was in der eigenen Macht stehe, um ja alle Studenten zeitig befoerdern zu koennen. Tatsaechlich sieht die Lage so aus, dass in den Morgenstunden insbesondere zu Beginn des Wintersemesters trotz Fuenf-Minuten-Takts schon am Theater beinahe kein Zustieg mehr moeglich ist. Anfangs lag das auch daran, dass einige Studenten zu doof waren, eben auch die „Zwischenbusse“ zu verwenden, und sicherlich koennte man auch den doppelt so langen Weg ueber den neuen Eselsberg mit der Linie 5 nehmen. Trotzdem ist die Argumentation ein wenig scheinheilig.

Wer beispielsweise frueher aus der Neu- oder Oststadt zum und vom Eselsberg fahren wollte, konnte das mit der Linie 14 tun, die zwar nur stuendlich fuhr, einem aber den Umstieg am Theater ersparte. Seitdem die Linie 1 bis Ulm-Boefingen faehrt, gibt es die 14 aber nicht mehr — nach Argumentation der SWU brauche man die ja nicht mehr, da alle Boefinger nun ueber die Linie 1 und 3/5 zum Science Park fahren koennen. Sich nun darueber zu wundern, dass Studenten aus Mitte/Neustadt und der Oststadt nun auf einmal mit zur Ueberfuellung eben dieser Linien beitragen, zeugt nicht gerade von vorausschauendem Denken — erst recht nicht, da der damalige Semesterticketreferent meines Wissens durchaus auf dem Erhalt der Linie insistierte. Als Ersatz wird einem von der SWU die E-Linie ueber Boefingen in die Oststadt angeboten, mit deutlich weniger Fahrten und einem viel viel laengerem Weg, wenn man denn irgendwo in Richtung des Willy-Brandt-Platzes will.

Mit dem Auto zur Uni fahren zu wollen wird indes auch immer mehr zum Abenteuer. Seitdem das Parkhaus in der Helmholtzstrasse von der PBW bewirtschaftet wird, die dafuer natuerlich Parkgebuehren haben moechte, steht es groesstenteils leer — waehrend nebenan alle Schotterparkplaetze schon fruehmorgens zum bersten voll sind und wild an den Strassenraendern oder in den Gruenflaechen geparkt wird. Aehnlich sieht es an der Klinik aus, wobei diese sich nach Fertigstellung des Klinikneubaus sowieso auf noch viel haertere Parkplatzsituationen vorbereiten muss.

Im Endeffekt werden also all die Autofahrer mehr oder weniger dazu gedraengt, doch mit dem OePNV zur Uni zu fahren, was ja an sich nicht schlecht ist. Alle Studenten dann aber in vollkommen ueberfuellte Busse zu stecken, kann auch keine Loesung sein. Und es ist ja keinesfalls so, dass diese Situation nicht schon vor dem Gespraech mit der SWP bekannt gewesen waere.

Ganz neu: Fernsehen!

Nachdem ich damals die CNN-Zentrale in Atlanta besucht hatte, schwirrte mir der Kopf vor lauter fixen Ideen. Die vielen Newsrooms mit ihrer Betriebsamkeit waren irgendwie ansteckend, und als ich auf den heissen Strassen einen der haesslichen Ami-Linienbusse sah, klickte es. Der Nachrichtenfix im Bus, das waere doch was. Kurz zuvor hatte man bei den SWU Doppelmonitore in einigen Bussen verbaut. Wenn man dort einfach eine Nachrichtenschleife wie die meines damaligen Lieblingssenders Euronews einbauen wuerde, mit groben Untertiteln und einem FM-Transmitter im Bus, so dass man auf Wunsch auch den Ton hoeren koennte… weitergesponnen wurde dann ein eigenes Lokalnachrichtenformat daraus, also etwa so wie bei RegioTV, nur nicht so amateurhaft, vielleicht sogar mit TU koproduziert…

Diese Idee hat mich dann tatsaechlich noch bestimmt vier Wochen verfolgt, und ich war schon ein wenig enttaeuscht, als sich die SWU irgendwann nach meiner Rueckkehr nach Ulm dazu entschlossen, „n-tv Der Tag“ als Slideshow einzubinden, was nur morgens aktualisiert wurde und abends inhaltlich schon wieder langweilte.

n-tv ist mittlerweile wieder von den Bildschirmen verschwunden, und es gibt hauptsaechlich veraltete Betriebsmeldungen und ein wenig Werbung im Bus zu lesen. Heute lese ich nun, dass die SWP auf den Zug^w Bus aufspringt und ein eigenes Nachrichtenformat in den Bussen auf die Beine stellt, mit ziemlich genau den Inhalten, die frueher von n-tv realisiert wurden. Plus, wie sich schoen zwischen den Zeilen lesen laesst, ordentlich Werbung. Meine Idee mit der immer wieder aktualisierten Nachrichtensendung greift wohl keiner mehr auf. Zugegebenermassen ist die aber auch schon von 2005 — mittlerweile holt man sich den Nachrichtenfix unterwegs schon lange nicht mehr von irgendwelchen zentralen „Nachrichtenanzeigestellen“, sondern per Netbook oder Mobiltelefon, UMTS und always-on sei Dank auch direkt auf die eigenen Interessen zugeschnitten. Die Monitore sind fuer mich jedenfalls inzwischen so interessant wie normales Fernsehen: Gar nicht mehr.