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.

9 Gedanken zu „Mein erster Hackathon

    1. Till

      Hm, Chrome geht bei mir genauso wie Firefox, sogar noch ein bissl besser, da die 5.0 mir noch einzelne Teile der Karte nicht angezeigt hat… aktuelle Chrome Version? (13.irgendwas)?

      Antworten
    2. stk Beitragsautor

      Chrome sollte eigentlich sogar am besten (== CPU-schonendsten) funktionieren. Die intensiveren Berechnungen leistet der Server vorab; bei no.de gibt’s aber anscheinend Probleme (die auch andere Projekte dort haben), da kann’s ab und zu mal sehr lahm werden.

      Antworten
  1. Kate

    hihihi.. echt cool… und sehr passend fĂŒr mich…da ich immer mit der 5 oder der 3 fahre. 🙂

    … ich benutze ĂŒbrigens auch chrome.. und das klappt einwandfrei!

    Antworten
  2. Harry

    Nettes Ding. sehr faszinierend.
    Aber sag mal, was darf ich denn unter live verstehen? Wenn ich mir die Bewegungen so ansehe, dann fĂ€llt mir auf, dass sich die Buse grĂ¶ĂŸtenteils gleichförmig bewegen, also wenn sie irgendwo stehen bleiben wird das auf der Karte nicht erfasst.
    Habt ihr die Bewegung also nur aus einigen Fixpunkten interpoliert?
    Und gestern Abend fuhr an der Uni West ein Bus vorbei der definitiv NICHT in der Karte auftauchte… Der macht aber auch an der Klinik ein paar Minuten Pause. Ist das evtl ein Problem oder hab ich mir das nur eingebildet?
    Ansonsten definitiv ne coole Sache

    Antworten
    1. Harry

      Nachtrag:
      Nachdem ich das ganze jetzt ein wenig durchgelesen habe, hab‘ ichs wohl verstanden…
      Also live ist da gar nix, sondern ihr habt nur die Fahrplandaten eben in graphische Bewegung umgesetzt….
      Und ich hatte unter live schon eine Echtzeitdarstellung der Buse via GPS oder Ă€hnliches erwartet. Ich hatte zumindest vermutet, dass die Ankunftszeiten (wie z.B. fĂŒr uni-ulm.de/bus verwendet) mit berĂŒcksichtigt wĂŒrden um eine Echtzeitkarte zu erstellen. Aber aktuell ist es doch „einfach nur“ ein animierter Fahrplan?!

      Antworten
  3. Andreas Krey

    Das sinnige ist ja, daß die Busse sogar IP-Connectivity nach außen haben, wenn man http://twitpic.com/62kqiw glauben mag. Echtzeitdaten wĂ€ren also kein grundsĂ€tzliches Problem. (’nen Google-Maps-Hack, der die Karte immer auf meine GPS-Position zentriert, habe ich vor ein paar Jahren mal gebastelt. Updates im Sekundentakt, solange GPRS mitspielt.)

    Antworten
  4. stk Beitragsautor

    @Harry, Erlaeuterung siehe oben in der Artikelergaenzung. Die Echtzeitdaten, die auf uni-ulm.de/bus verwendet werden, haette man theoretisch schon dafuer verwenden koennen, das waere aber vollkommen sinnbefreit — wuerde man auf die Tour tatsaechlich das gesamte SWU-Netz abbilden wollen, muesste man deren Server im Abstand weniger Sekunden mit Anfragen zu allen(!) Relationen ueberfluten. GTFS ist hier der Weg, den es zu begehen gilt — in der Grundstufe erstmal fuer die Auswertung der Soll-Plaene, danach irgendwann[tm] mit GTFS-Realtime.

    @Andreas, ja, daher kommen ja auch die RBL-Echtzeitdaten, die man sich schon jetzt (bzw. schon „ewig“) auf der DING-Seite und bei den SWU anzeigen lassen kann. Wir haetten halt gerne endlich mal die Daten in einem offen verwendbaren Format, und u.A. dafuer sollte auch diese Referenzimplementation dienen — zu zeigen, was grundsaetzlich moeglich ist.

    Antworten
    1. Andreas Krey

      Ich hĂ€tte nicht damit gerechnet, daß die fĂŒr die PositionsĂŒbermittlung tatsĂ€chlich GPRS/3G/whateverIP (und auch noch zumindest mit einem Gateway ins öffentliche Netz) benutzen und an Betriebsfunk oder SMS pro Haltestellenabfahrt gedacht. Die stationĂ€ren Anzeigen werden ja auch einigermaßen offensichtlich ĂŒber langsamen Modem-Datenfunk angesteuert (Antenne, Geschwindigkeit des Bildaufbaus).

      Antworten

Schreibe einen Kommentar zu stk Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert