Schlagwort-Archive: OpenTransit

Cleaning up the SWU GTFS feed with pygtfs and sqlite3

For a Top Secret Project™ we are currently using SWU’s official GTFS feed. Since we had to clean up the feed a bit and ran into some errors, I thought it best to document our workflow to save it for posterity – it might even help others ;

Step 1: Loading into sqlite

For me, the first step is always to load the feed into sqlite3, since it makes it easier to follow through with all the manipulations I have in mind for later.

My current tool of choice is pygtfs, which can be installed through pip. If you don’t have sqlite installed, you might want to do that now, too.

pip3 install pygtfs
apt install sqlite3

pygtfs brings along the handy gtfs2db tool, which allows for importing your feed into a database right from the command line:

gtfs2db append ~/Downloads/ gtfs.db 

This command will, however, fail after importing all the records and trying to write it to the database, because it can’t read a datetime (ValueError: time data “ does not match format ‚%Y%m%d‘). After some digging I found the missing feed_start_date and feed_end_date in feed_info.txt to be the culprit. According to spec, they are merely optional, but the gtfs2db script seems to depend on it. Nothing a quick edit in the text editor of your choice can’t fix. All there is left to do is to retry the import, and open a sqlite3 session with the newly created database. I am in the habit of switching on the headers and into column mode right from the get-go.

sqlite3 -header -column gtfs.db 

Step 2: Exploring the stops table

For our project, we wanted to clean up the stops table a bit. First of all, in violation of the spec, in the SWU feed the stop_id is multiply assigned to every stop point („Haltepunkt“) within a stop („Haltestelle“). We can find this rather easily:

SELECT stop_name, count(stop_code) FROM stops GROUP BY stop_code ORDER BY count(stop_code) DESC limit 15;
stop_name count(stop_code)
---------- ----------------
ZOB Ost 9
Staufenrin 9
Universit 8
Donaustadi 6
Egertweg 6
Römerplat 6
Gewerbesch 6
Stadtwerke 5
Eselsberg 5
Sonnenstra 5
Theodor-He 5
Kuhberg Sc 5
Hauptbahnh 4
Theater 4

Furthermore, some stop points (i.e., the platforms within one stop) are assigned doubly or even thrice with the same coordinates. This happens if one stop point is being served by different operational branches. In the case of the SWU feed, the internal data format distinguishes between bus, tram and night bus service. This means that if a stop point is being served by all three of those branches, it will appear thrice in the data set:

SELECT stop_id, stop_code, stop_name, stop_lat, stop_lon, COUNT(distinct stop_lon) FROM stops GROUP BY stop_code HAVING count(distinct stop_lon) > 1 ORDER BY count(distinct stop_lon) DESC limit 20;
stop_id stop_code stop_name stop_lat stop_lon COUNT(distinct stop_lon)
---------- ---------- ----------------- ---------- ---------- ------------------------
3579 1240 Universität Süd 48.421839 9.956403 6
3559 1383 Gewerbeschulen K� 48.384625 9.959908 6
1869 1700 ZUP 48.39179 10.0032 6
117 1050 Staufenring 48.403521 10.004344 5
3745 1200 Eselsberg Hasenko 48.414326 9.962903 5
3557 1390 Kuhberg Schulzent 48.383775 9.955289 5
1235 1052 Donaustadion 48.405101 10.006927 4
145 1072 Mecklenburgweg 48.43453 10.024493 4
147 1073 Thüringenweg 48.433379 10.020177 4
149 1074 Haslacher Weg 48.429919 10.013786 4
3260 1087 Egertweg 48.42583 10.01243 4
217 1171 Manfred-Börner-S 48.41967 9.942766 4
3581 1241 Botanischer Garte 48.424912 9.956829 4
3584 1245 Kliniken Wissensc 48.424331 9.952453 4
3586 1246 Universität West 48.422234 9.947201 4
3565 1360 Römerplatz 48.39077 9.975428 4
3561 1393 Grimmelfinger Weg 48.38564 9.965312 4
774 1506 Benzstraße 48.365706 9.941817 4
75 1008 Hauptbahnhof 48.39983 9.98404 3
3571 1020 Stadtwerke 48.4031 9.986038 3

I hacked together the following python script that will unify these stop points so that each coordinate will appear exactly once. That is, it will output SQL statements to be pasted into sqlite which should do the trick. Hacky and crappy, but there we go. Note that I have uncommented (and did not test) the transfers bit, since the SWU feed does not use transfers. Note that this leaves the multiply assigned stop_ids untreated, as of now.

sched = pygtfs.Schedule("gtfs.db")
sq = sched.stops_query
d = {}
for each in sq.all():
if each.stop_code in d:
for existing in d[each.stop_code]:
if (d[each.stop_code][existing].stop_lat == each.stop_lat) and (d[each.stop_code][existing].stop_lon == each.stop_lon):
print('UPDATE stop_times SET stop_id = ' + d[each.stop_code][existing].stop_id + ' WHERE stop_id = ' + each.stop_id + ';')
#print('UPDATE transfers SET from_stop_id = '+ d[each.stop_code][existing].stop_id + ' WHERE from_stop_id = ' + each.stop_id + ';')
#print('UPDATE transfers SET to_stop_id = '+ d[each.stop_code][existing].stop_id + ' WHERE to_stop_id = ' + each.stop_id + ';')
print('DELETE FROM stops WHERE stop_id = ' + each.stop_id + ';')
d[each.stop_code][each.stop_id] = each;
d[each.stop_code] = {};
d[each.stop_code][each.stop_id] = each

Step 3: Removing Deadheads

One bug in the current SWU feed is that it includes trips that should not be facing towards the customer. Namely, all the trips between the bus depot and the first stop on one vehicle’s Umlauf, and the return trips towards the depot. This might result in strange routing results and will definitely make the transitfeed validator complain. The following SQL statements will delete both the stop_times and the trips for those deadheads:

DELETE FROM trips WHERE trip_id IN (SELECT DISTINCT trip_id FROM stop_times WHERE stop_id IN ("170", "171"));
DELETE FROM stop_times WHERE trip_id IN (SELECT DISTINCT trip_id FROM stop_times WHERE stop_id IN ("170", "171");

Step 4: Re-Exporting the data, casting times past 24:00:00 without using strftime

This was one part which kept me scratching my head for way too long. Simple full-table dumps are not a big issue:

sqlite3 -header -csv gtfs.db 'SELECT * FROM trips'  > trips.txt

After some successfull exports, I hit a bump in the road with the stop_times table because of the way GTFS and sqlite each store times. A vehicle departing one minute before midnight from one stop and arriving two minutes past midnight at the next stop will be modeled with the textual entries of „23:59:00“ and „24:02:00“, respectively. Since the operational day ends somewhen between midnight and the wee hours of the next day, it is not unusual to encounter departure/arrival times that read something like „27:35:00“ – at 03:35 a.m. of the following day, but still within the validity period of the previous/current day (I am getting mixed up with terminology myself, I guess)

However, pygtfs will convert all those textual time entries into DateTime objects, which means that the two times above would be stored as 1970-01-01 23:59:00.000000 and 1970-01-02 00:02:00.000000. And any manipulation with strftime and other functions to manipulate Date and Time didn’t get me anywhere – or, to put it differently, all the usual functions correctly and stubbornly refused to return non-standard times that use funny hours like 24 or anything above.

In the end, the statement to get GTFS compliant times was not that hard, after all. If you ever want to calculate hours, minutes and seconds past a date, this is the way to go:

SELECT trip_id, printf("%02d",((strftime("%s", "arrival_time") - strftime("%s", "1970-01-01 00:00:00.00000")) / (60*60))) || ":" || printf("%02d",(((strftime("%s", "arrival_time") - strftime("%s", "1970-01-01 00:00:00.00000")) % (60*60)) / 60)) || ":" || printf("%02d",(((strftime("%s", "arrival_time") - strftime("%s", "1970-01-01 00:00:00.00000")) % 60) % 60)) AS arrival_time, printf("%02d",((strftime("%s", "departure_time") - strftime("%s", "1970-01-01 00:00:00.00000")) / (60*60))) || ":" || printf("%02d",(((strftime("%s", "departure_time") - strftime("%s", "1970-01-01 00:00:00.00000")) % (60*60)) / 60)) || ":" || printf("%02d",(((strftime("%s", "departure_time") - strftime("%s", "1970-01-01 00:00:00.00000")) % 60) % 60)) AS departure_time, stop_id, stop_sequence, stop_headsign, pickup_type, drop_off_type, shape_dist_traveled, timepoint FROM stop_times

But, as @LucasWerkmeistr pointed out, in this case we are always subtracting 1970-01-01 00:00:00.00000 – which is zero. The simplified version for exporting the tables is as follows:

sqlite3 -header -csv gtfs.db 'SELECT trip_id, printf("%02d",(strftime("%s", "arrival_time") / (60*60))) || ":" || printf("%02d",(strftime("%s", "arrival_time") % (60*60)) / 60) || ":" || printf("%02d",(strftime("%s", "arrival_time") % 60) % 60) AS arrival_time, printf("%02d",(strftime("%s", "departure_time")) / (60*60)) || ":" || printf("%02d",(strftime("%s", "departure_time")  % (60*60)) / 60) || ":" || printf("%02d",(strftime("%s", "departure_time") % 60) % 60) AS departure_time, stop_id, stop_sequence, stop_headsign, pickup_type, drop_off_type, shape_dist_traveled, timepoint FROM stop_times'  > stop_times.txt

Note that the export mentions the shape_dist_traveled and timepoint columns. This is because this iteration was not made on a squeaky clean SWU feed, but after some massaging with Conveyal’s GTFS Editor. But that will be a topic for another time 😉

edited on 2019-03-16 to fix errors in the last two scripts and to clarify stuff

Offene Schnittstellen fuer intermodale Mobilitaet

Die Konsequenz des obigen Zitats finde ich sehr spannend. Mobilitaet in der beschriebenen Form eines gemeinsam gedachten und funktionierenden Systems kann also nur funktionieren, wenn a) ein Anbieter alles aus einer Hand anbietet. Das scheint das Modell zu sein, das einige Verkehrsverbuende fuer sich zu beanspruchen scheinen: Alles soll in ihre App. Und auch einige privatwirtschaftliche Anbieter wollen jeweils marktbeherrschender Platzhirsch werden – denn wenn ihnen die Paymentfunktion gehoert, haben sie den Markt gecornert.

Modell b) waere dagegen, die einzelnen Komponenten fuer Mobilitaet nach den Modellen der Unix-Philosophie oder des Internets zu betrachten: Jede Komponente macht ihren Teil wirklich richtig gut, und laesst sich ueber definierte Schnittstellen zu einem groesseren Ganzen zusammenfuegen.

Die grosse Frage ist in Deutschland seit Jahren, wie man die Schnittstellen in diese Mobilitaet hineinbekommt. Selbst Soll-Fahrplandaten für den ÖPNV sind in Deutschland immer noch Mangelware, und Verbünde preisen ihre architektonischen Inselloesungen zu Echtzeit-Fahrplanauskuenften mit der Marketingluege „Open Services“ an, obwohl sie weder Open noch ein sich in ein Gesamtsystem einbetten lassender Service sind. Und private Mobilitaetsdienstleister nutzen zwar gerne oeffentlichen Raum im Sinne des Gemeingebrauchs fuer ihre Dienste, geben aber im Gegenzug enorm ungern Daten wieder preis.

Max und Consti haben dieser Tage einen laengeren Artikel darueber geschrieben, wie die City of Los Angeles per kommunaler Satzung an dieser Stelle mitbestimmt und den Markt im Sinne des Gemeinwohls steuert. Die Stadt hat sowohl eine Satzung als auch gleich einen passenden Datenstandard verabschiedet, an den sich alle halten muessen, die innerhalb der staedtischen Jurisdiktion Dienste anbieten wollen. Das Motto: Wer hier Geschaefte machen will, muss das auch sozialvertraeglich tun und dafuer Sorge tragen, dass das eigene System sich in das groessere Mobilitaetssystem einbetten laesst.

Im Artikel wird darauf verwiesen, dass Elektrokleinroller jetzt bald auch in Deutschland legal im Strassenverkehr einsetzbar sein werden, und dadurch bald auch Scooter-Sharinganbieter wie Lime und Bird auf den deutschen Markt vordringen werden. Das sei eigentlich der ideale Zeitpunkt, auch in Deutschland kommunale Satzungen zu verabschieden, die sich an der von Los Angeles orientieren.

Mehr Lektuere dazu gibt es im API-Policy-Paper der Transit App, mit einer Menge von Links, die sich zu lesen lohnen.

Mal grafisch aufbereitet: Der Status Quo zu Open Data im OPNV

Dreieinhalb Jahre ist es jetzt her, dass die kleinen SWU den bundesweit zweiten GTFS-Fahrplandatensatz veroeffentlichten. Und was sind wir in der Zwischenzeit alles rumgeturnt durch Deutschland, um Bruecken zu schlagen zwischen Civic-Tech-Szene und Verkehrsunternehmen: Auf der rp15, beim Verkehrscamp des VDV in Essen, und im letzten Jahr auch immer wieder bei der Bahn.

Hinter den Kulissen bewegt sich in der Tat sehr viel, was mich dieses Jahr auf der re:publica auch verhalten optimistisch gestimmt hat. Vorne ist davon aber nur maessig viel zu sehen. Ein aktueller Realitaetscheck: Die Verbundkarte, die ich auf dem letzten DB-Hackathon angefangen hatte, aber nun deutlich besser von Alexey umgesetzt wurde:

Ich wuerde sagen: Da geht noch was.

Vier Wochenenden voller Open Data

Es gibt ja so Veranstaltungen, nach denen geht man voller Motivation nach Hause. Bei mir sind es gerade fuenf Open-Data-Veranstaltungen in fuenf verschiedenen Staedten an den letzten vier Wochenenden gewesen, und sollte jetzt noch irgendwas kommen fallen mir vermutlich vor lauter Grinsen die Ohren ab.

Aber der Reihe nach.

Berlin: Bahn, die erste


Beste Aussichten hatte am ersten Märzwochenende der Workshop, den die OKF fuer die DB Station&Service in Berlin ausrichtete – buchstaeblich wie metaphorisch. Die Station&Service moechte naemlich sich und ihre Daten oeffnen, wie das die SNCF in Frankreich bereits getan hatte. Die Personenzusammensetzung war genau richtig, und ich am Ende ganz schoen geschlaucht vom Brainstormen und reden. Ich bin sehr gespannt, wie es hier weitergeht, und hatte mir den gesamten Abend danach und die Heimfahrt noch ueberlegt, welche Community-Teile zum Beispiel aus der OpenStreetMap sich hier noch verknuepfen lassen.

Freiburg: Hackathon unterm Sternenbanner

Ganz ohne Getoese hat sich auch Freiburg einen festen Platz auf der Landkarte der innovationsbereiten Staedte verschafft. Das liegt auch an Ivan Acimovic, der in seiner Stadtverwaltung auf ueberraschend viele Open-Data-Vorantreiber_innen bauen kann – und gleich mit einer halben Armee von Mitstreiter_innen einen Open-Data-Hackathon im Carl-Schurz-Haus aus dem Boden stampfte.

Mit der Stadt alleine war es naemlich nicht getan – bwcon Suedwest, das Carl-Schurz-Haus und Profs der Hochschulen Offenburg und Furtwangen warfen sich mit ins Zeug, um diese Veranstaltung durchzufuehren. Dass alle Ergebnisse im Rathaus ausgestellt werden, ist da nur konsequent.

Neben den zu erwartenden Wiederkehrern auf allen Open-Data-Hackathons (natuerlich gab es eine neu erfundene Issue-Tracking-App, die nicht bestehende Loesungen wie Mark-A-Spot verwendet :D) stach fuer mich „Frieda“ besonders hervor: Eine benutzerfreundlichere Neuinterpretation des Freiburger Datenportals FR.ITZ, das bei der Usability noch… Potenzial hat.

Ein wenig schade, dass dieses Projekt bei der Preisvergabe nicht mehr gewuerdigt wurde – zusammen mit dem Projekt „Data Canvas“, das Datenangebot und Bedarfe anhand von Problemstellungen analysieren wollte, haette ich „Frieda“ deutlich hoeher gerankt. Ich bin gespannt, wie viele der Projekte noch weiter entwickelt werden – und wie viele der enthusiastischen Teilnehmer_innen beim kommenden OK Lab Freiburg zu sehen sein werden, das ich leider ganz alleine vertreten musste 🙂

Frankfurt: Die Bahn bewegt (sich) doch!

Und eine Woche spaeter verstummten die Voegel, und der Mond verdunkelte die Sonne, und das scheinbar undenkbare geschah: Die Deutsche Bahn lud zu einem Datenhackathon!

Gerade mal zwei Wochen vorher hatte ich ueberhaupt davon erfahren – ironischerweise auf dem Rueckweg vom DB-Workshop in Berlin, auf dem wir uns fragten, wann sich denn die DB Fernverkehr endlich bewegen wuerde. Der Hackathon war wohl binnen weniger Wochen auf die Beine gestellt worden und war fuer mich eine ausgezeichnete Gelegenheit, einmal mit den Leuten im Konzern zu sprechen, die gerne viel mehr Daten freigeben wuerden – die aber nicht einfach machen duerfen, wie sie gerne wuerden.

In gigantischer 1970er-Jahre-James-BondSuperschurken-Hauptquartier-Atmosphaere hackten immerhin rund 50 Teilnehmer_innen an den noch-nicht-wirklich-offenen Daten der Bahn – Daten, an die in einigen Faellen wohl bislang selbst die Bahn-Leute konzernintern noch nie herangekommen waren, und die es nur durch diesen Hackathon erstmals aus ihrem jeweiligen Silo herausgeschafft haben. Ausgangszustand: Dass die Teilnehmer_innen „nur“ ein einseitiges NDA-Dokument unterzeichnen mussten, ist bereits ein grosser Fortschritt.

Ich musste leider noch am selben Abend weiter, um rechtzeitig nach Moers zu kommen, aber Falco aus der Ulmer Arbeitsgruppe hatte sich spontan mit drei anderen zusammengetan und mit seiner Gruppe mal eben eine bessererere™ Reiseauskunft gestrickt, die historische Verspaetungen beruecksichtigt und die Wahrscheinlichkeit angibt, einen bestimmten Anschluss zu erreichen. Hut ab! Mehr Eindruecke gibt es in einem Youtube-Video der Veranstalter.

Ich warte jetzt jedenfalls ganz gespannt, dass die Ergebnisse des Hackathons konzernintern durch die Entscheiderpositionen sickern – und hoffe instaendig, dass wir demnaechst einmal ein Transit-Camp auf die Beine stellen koennen, bei dem Vortraege, Austausch und Coding Hand in Hand gehen. Idealerweise mit einem Augenmerk auf moeglichst hohe Diversitaet – Fahrtkostenbezuschussungen und eine inklusivere Ansprache koennten viel dazu beitragen, nicht nur die ueblichen Verdaechtigen bzw. die Leute aus dem direkten Umland anzulocken 😉

Moers: Die heimliche Open-Data-Hauptstadt im Nirgendwo

Solcherlei Inklusivitaetsfoerderung war fuer Moers dagegen gar kein Problem – Dank Reisekostenbezuschussung waren „die Ulmer_innen“ gleich zu zweit beim dortigen Hackday, und auch aus Berlin kamen Abordnungen an den Niederrhein.

Claus Arndt
tut sich schon seit einiger Zeit damit hervor, am Rande der Einoede zwischen Pott und den Niederlanden in seiner Kommune das Thema voranzubringen — und kann in seiner Position hierzu auch einiges bewegen. Zum Beispiel diesen Hackday zu veranstalten, bei dem sich auch gleich Interessierte aus dem gesamten Umland fanden, um auch gleich ueber eine Gruendung von „Code for Niederrhein“ nachzudenken.

Moers zeigt fuer mich vor allem, dass Erfolg bei Open Data momentan weniger das Ergebnis grossangelegter Strategiepapiere ist, sondern vom Aufeinandertreffen einer aktiven Community auf engagierte Einzelpersonen mit Gestaltungsspielraum in der Verwaltung lebt. Die besten Absichtserklaerungen, die tollsten Forschungsprojekte nuetzen nichts, wenn die Verwaltung nicht dafuer sorgen kann, dass die freiwilligen Datenveredler ihren Spass nicht verlieren. Indem sie zum Beispiel die Rahmenbedingungen schafft, dass 1.) Daten reibungsarm beschafft werden und 2.) Ergebnisse reibungsarm den Weg zurueck in die Verwaltung finden koennen. In Moers klappt das.

Mehr nachzulesen gibt es auf Wegweiser-Kommune [2], im Government-2.0-Netzwerk, bei Habbel, und in einem Flickr-Fotoset von @mrtopf. Und im Blog von Anke Knopp wird auch erklaert, was es mit der Feuerwehr auf sich hatte 😉

Im Video klingt es auch ein wenig an: Neben Redeployment-Auslotung hatten Juka und ich auch inhaltlich was gemacht, Verkehrszaehlungsdatenauswertung naemlich. Dazu kommt aber noch spaeter mehr 🙂

Leipzig: Code for Germany meets again

Etwas ueber ein Jahr nach dem Auftakt von Code for Germany waren Rens und ich zum gemeinsamen Workshop in Leipzig — um eine grossartig gewachsene Familie von OK Labs zu treffen, die sich mittlerweile auf verschiedenste Themengebiete verteilt hat, von Spielplatzkarten bis zu Feinstaubsensoren fuer jede_n zum Selbst-aufstellen.

Dementsprechend werden mittlerweile auch die Herausforderungen umfangreicher. Ging es anfangs um die Vernetzung an sich, Sichtbarkeit und Austausch, geraten wir als Gemeinschaft nun an die etwas knackigeren Probleme — offenbar genauso, wie das schon beim Vorbild Code for America der Fall war. Redeploying, also das Ausrollen bereits anderswo erprobter Loesungen mit den Daten der eigenen Kommune, scheitert allzu haeufig an der Vielfalt der Datenformate, die aus den Fachverfahren fallen, Standardisierung ist weit weit weg, und akademische Ideen wie die Semantifizierung aller Daten sind momentan leider noch wenig praxistauglich. Zudem sind vielfach Interessierte zu einem Thema bei sich eher alleine, und andere Interessierte anderswo muessen erst einmal gefunden werden.

Umso dankbarer bin ich mittlerweile fuer die verbindende Klammer, die CfG mittlerweile bildet, und bin gespannt auf das, was da noch kommt. Ich bin unglaublich froh darueber, dass schon sehr frueh Diskussionen ueber einen Code of Conduct begonnen hatten — aus Fehlern anderer lernen, ganz angewandt. Und ich moechte mal ganz ausdruecklich ein Dankeschoen an Fiona und Julia aussprechen, die sich nun ueber ein Jahr lang um Vernetzung, Bereitstellung passender Werkzeuge, und das Ruehren der Werbetrommel gekuemmert haben.

Auf das naechste Jahr! Und noch viele kommende Open-Data-Wochenenden 😉

Free and Open Source your Transit System, Now!


Yesterday, I came across two pieces on how Baltimore’s transit systems got accidentally opened – saving development costs quoted by Baltimore MTA as 600,000 USD:

If you’ve ever taken a bus, you know just how fun it is to be stuck outside in the cold wondering when the next one will come. That’s why the state of Maryland spent $2.7 million dollars developing a real-time bus tracking system for Baltimore, so that riders would finally be able to overcome the city’s “notoriously unpredictable” bus service.


When reporters asked the MTA why they opted to only show the info on their mobile webpage instead of developing an app (or better yet, formatting the data for third parties like us), the MTA responded that it would have been too expensive.

We know in many cases, the information needed to create an application is made public so private firms can attempt to develop an application at their own expense. However, it would cost approximately $600,000 more to be able to format the data from our 25-yr-old CAD/AVL system into GTFS for use by outside developers.

You read that right. Baltimore’s MTA rolled out real-time bus tracking and neglected to provide it via an Open API, because it would have cost them another 600k USD. Luckily, transitapp came to the rescue, parsed the data and re-formatted it into GTFS-realtime, so that other App developers could make use of it. The code is on Github, of course 😉

Now, the US is not really public transit heaven. If there even is such a thing, it might be somewhere in Europe, D-A-CH specifically, where Verkehrsverbuende are plentiful and real-time data is the norm for urban areas rather than the exception. Still, transit agencies hold on to their data like dragons hoard their treasures – the only means of getting onto those sweet, sweet real-time data is their official APIs, which are one-size-not-really-fits-all-solutions which they attempt to open-wash by calling them “Open Service”.

Even worse, real-time AVL data is mostly restricted to transit operators who can afford them – and thus mostly to urban areas. The suburban and rural areas of Germany seldom get any of the benefits stemming from on-board IBIS computers on their transit vehicles – in-vehicle stop information as announcements and visual displays, reliable outer displays and, of course, real time data, to name only a few. These additional features would make suburban and rural transit not only more reliable for riders in general[1], but also more accessible to handicapped riders.

As the situation presents itself now, though, only well-off operators usually found in urban centres can afford to deploy on-board information systems such as the German IBIS model on all their vehicles. And even if they do, their implementation often leave you shaking your head – just as the in-vehicle stop display at the top of this article, which still can’t correctly implement an encoding standard written in 1984(!).

Sneer as much as you want on Baltimore’s MTA, which (admittedly) deploys solutions on their customers which look and feel like it’s the 1990s again – Germany is not that much farther.

It is time, we took a cue from the effort made in Baltimore and took matters in our own hand. There are people out there willing and capable to re-engineer displays like the one shown at the top of this article in their own time, as a hobby – and who, I dare say, propably do a better job than the “official” vendors in doing so. What if, through a collaborative effort, we developed low-cost solutions to enable small pop-and-mom transit operators in Back of the Woods, Bavaria, to provide not only the in-vehicle information that is already standard in urban areas within Germany, but also with real-time arrival and connection information?

The pieces are already out there. And I can’t be the only one willing to invest time in making this come true. Thing is, on my own, I can’t. If you’re into this kind of thing, please ping me. Please.


[1] for positive effects of real-time transit information on perceived service quality, see Dziekan, K., & Kottenhoff, K. (2007). Dynamic at-stop real-time information displays for public transport: effects on customers. Transportation Research Part A: Policy and Practice, 41(6), 489-501.

Linkliste vom 2015-01-18


On Tone Policing Linus Torvalds, or Linus Torvalds is a Shit-Eating Pig (via)

Linus Torvalds is a shit-eating pig. The man’s default mode of interacting with his own community is to crash into discussions like the Kool-Aid Man and harangue and insult people for having technical opinions different from his own, regardless of whether he’s right or wrong. This is moronic […]

Did I do that right? Did my use of strongly-worded invective demonstrate my enthusiasm for the subject I’m discussing, as well as my mastery of the facts? Linus Torvalds seems to think so.

Verwandt: there’s no merit in meritocracy – bezieht sich auch auf Torvalds, laesst sich aber auf beliebige Hacker-/Nerd-Culture-Gruppen anwenden. Beispielsweise CCC-Erfa-Kreise.

The problem is that in practise, the ones who define merit are those already in power, and in both these communities as well as society at large, the ones in power are white, cisgendered, heterosexual men, and as long as these people get to define what merit is, meritocracy will merely reinforce existing power structures. It’s nothing radical, really. It’s the exact opposite, a reactionary, conservative rhetoric that’s used to subdue criticism.

Opt-Out Citizenship: End-to-End Encryption and Constitutional Governance

Let’s suppose for the moment that perfect end-to-end encryption is possible—that it becomes possible for individuals to hide everything they say and everything they write and every document they create and every transaction they perform from any surveillance, ever. This is clearly the goal advocates aim toward, without hesitation. This is to some extent what a service like Tor already provides.

On what legal or ethical basis do advocates assert that they have the right to do this?

Unter demselben Gesichtspunkt beleuchtet tante die aktuelle Kryptodiskussion in GB.

The NY Police vs. the Mayor

After Officer Ramos’s funeral, I asked a group of cops who had gathered in one of the neighborhood bars why they aimed their anger so exclusively at Mayor de Blasio. […]

Drinks flowed. A retired detective from Yonkers reminisced in great detail about the various suspects—or “mutts”—he’d clobbered and left for dead. When he saw me listening and obviously suspected I wasn’t “one of us,” he said, with an unconvincing smile, “None of those stories are true, understand?”

Contempt in the bar expanded from de Blasio to politicians in general. There was the sense that, as police, they believed themselves to hold an unquantifiable power over elected officials. The idea seemed to be that there was a pact between law enforcement and politicians. Cops did the dirty work, they waded in the muck, keeping the poor and violent in check and monitoring the human detritus that is the result of inequities they’d had no hand in creating. In return, politicians turned a blind eye to the excessive use of force. On the beat, cops could have their way.


Paper der Woche

An Efficiency Comparison of Document Preparation Systems Used in Academic Research and Development

To assist the research community, we report a software usability study in which 40 researchers across different disciplines prepared scholarly texts with either Microsoft Word or LaTeX. The probe texts included simple continuous text, text with tables and subheadings, and complex text with several mathematical equations. We show that LaTeX users were slower than Word users, wrote less text in the same amount of time, and produced more typesetting, orthographical, grammatical, and formatting errors. On most measures, expert LaTeX users performed even worse than novice Word users. LaTeX users, however, more often report enjoying using their respective software. We conclude that even experienced LaTeX users may suffer a loss in productivity when LaTeX is used, relative to other document preparation systems.

Open Data, Open Transit

Wie nachhaltig ist eigentlich Open Data? – Ernesto Ruge stellt diese wichtige Frage angesichts verwaister Projekte, die nach einigen Jahren nicht mehr weiter gepflegt werden (koennen). Diskussionsbeteiligung in den Kommentaren gerne gesehen!

Developing a Prepared Mindset – Transit sketch planning – Wie geht eigentlich Nahverkehrsplanung? Schoenes Format, von CfA

Eine etwas andere Transit-Karte

Von Transit-Livemaps hatte ich es hier ja schon haeufiger, das hier ist aber ein schicker und etwas anderer Ansatz: Christoph Doeberl hat den Linzer Nahverkehr auf eine Hardware-Karte gepackt.

Bild von Christoph Doeberl, CC-BY

Bild von Christoph Doeberl, CC-BY

Ein Rechner fragt die EFA-Daten der Linz Linien AG periodisch ab, und mittels Arduino werden dann RGB-LEDs angesteuert, um die jeweiligen Linienfarben an den passenden Haltestellen aufleuchten zu lassen.

Mir ist noch nicht ganz klar, ob da dann auch „Interims-LEDs“ fuer die Streckenabschnitte zwischen den Haltepunkten geplant sind, oder ob die Position immer „nur“ an den Haltestellen angezeigt werden kann; schick sieht’s allemal aus. Der Code steht auf Github einsehbar bereit.

Spassfakt zwischendurch: Etwa so funktionierten auch die Perlschnuranzeigen in Bussen und Bahnen: Ueber den mittlerweile ueber 30 Jahre alten IBIS-Wagenbus nach VDV-300 wurde die kommende Haltestelle und die Fahrtrichtung uebertragen, und im Fahrzeug mittels Laempchen hinter einer Durchlichtanzeige angezeigt. Bei manchen Verkehrsbetrieben sieht man solche Anzeigen gelegentlich noch – wenn ich mich richtig erinnere, z.B. in Stuttgart

An diesem Anwendungsfall zeigen sich auch die Probleme des leider von vielen Verkehrsverbuenden und dem VDV propagierten Modells, Fahrplandaten nicht als Open Data, sondern als „Open Service“ (also nur ueber Schnittstellen wie die EFA) bereitzustellen:

Leider ist ein Dauerbetrieb der Echtzeit-Abfrage von Daten sehr Bandbreiten intensiv, weshalb diese zeitweise ausgesetzt wird.

Deutlich sinnvoller erscheint an dieser Stelle der GTFS-Ansatz: Es gibt einen statischen Soll-Fahrplan, und Abweichungen von diesem werden als Realtime-Updates veroeffentlicht. Anstatt alle Fahrten bzw. Haltestellen periodisch komplett abfragen zu muessen, kann so der Soll-Fahrplan als Basis verwendet werden, und nur die Abweichungen muessen aus dem Internet bezogen werden. Das scheint man beim VDV vor lauter Angst vor Fremdnutzung aber nicht verstehen zu wollen.


Wer hier mitliest, koennte meinen, ich existiere gar nicht mehr – ich kann wahlweise beruhigen oder enttaeuschen, dem ist nicht so.

Die letzten Monate waren ein wenig turbulent: Diplomarbeitsendspurt und -abschlussvortrag, nahtloser Uebergang in SoNaFe-Hilfsorganisatortaetigkeit wider Willen, parallel Arbeit im Mobilitaetsreferat, der datalove-Arbeitsgruppe, ein Open-Data-Workshop beim SWR in Stuttgart… was man eben so tut 😉

Die kommenden Wochen bleiben voller spannender Projekte: Ab Freitag abend bin ich in Berlin zum offiziellen Start von Code for Germany, ausserdem habe ich einige Texte zu Open Data und Nahverkehr auf dem Backburner, und Dominik und ich prototypen gerade Libraries fuer neue Busabfahrtsdisplays auf GTFS-Basis. Da Farnell element 14 uns hier freundlicherweise mit Hardware unterstuetzt, gibt’s bald auch eine Variante zum einfach-nur-installieren-und-verwenden – aber erstmal klinke ich mich nun in Richtung Berlin aus 🙂

Bis dahin ein Sneak Peak:

Roll your own transit display

@Lotterleben pointed out a hackaday project by Karlsruhe students today: Upcycling an old LED dot-matrix display, they outfitted their dorm with a real time bus departure monitor. Of course, there is a German word for that: Dynamische Fahrgastinformationsanzeige, or DFI 🙂

Apart from the cool technical solution the two came up with, this monitor is also interesting from yet another perspective. KVV, Karlsruhe’s integrated transit system, uses EFA by mentzDV for their online journey planner, which is in turn parsed for the display hack. EFA can output XML or JSON (depending on the installation), and the datalove working group used the EFA XML output for their own transit displays at ulm university (see below) – or for your own desktop, or for your smartphone.



Now, neither the departure monitor, nor the smartphone version, are works of art. They have severe usability and UI issues, and the EFA wrapper, while a cool hack by @taxilof, is tailored towards DING, our integrated transit system. Also, all of the systems completely rely on EFA – thus, whenever EFA fails or has scheduled downtimes, all displays fail.

I would love to bring together all interested parties who have hitherto put some efforts into any wrappers, libraries or solutions for EFA and create a unified and good library for EFA that is interchangeable to whatever version your local authority is running – just insert the API endpoint, choose whether it can output JSON or XML, and be a happy camper. Bonus points for also integrating GTFS as a fallback solution[1]!

The code for the mobile departure site is on Github; Documentation on the EFA interface is collected in the UlmAPI wiki. Interested? Get in touch!

[1] Yes, your transit system most likely does not provide GTFS yet. I am working on this as part of my thesis.

Update: @Natanji and @Feuerrot pointed me towards the projects site of Daniel Friesel, which includes command-line interfaces to – among others – EFA and Deutsche Bahn departure monitors. Front ends are available in the style of Deutsche Bahn and VRR.

Update2: There is another site serving as a entry point into creating your own Deutsche Bahn departure monitors.

Selbstgemachte Haltestellen-Umgebungsplaene

Es gibt ja so Momente, in denen moechte man ein Problem loesen, und dann schliesst man sich so lange ein, bis man hinreichend nahe an eine Loesung gekommen ist. So in der Art erging es mir am Schwoerwochenende, eigentlich wegen einer ganz trivialen Sache: Ich haette gerne Umgebungsplaene fuer die Bushaltestellen rund um die Uni.

Ein Grund, warum ich hier im Blog nicht mehr so viel schreibe ist naemlich, dass ich seit gut einem Jahr der Mobilitaetsreferent der Uni-Studierendenvertretung bin und in dieser Eigenschaft umso mehr anderswo schreibe. Und ein Problem, auf das ich in diesem Rahmen stiess, war der Umstand, dass es an vielen Haltestellen in der Stadt mittlerweile Orientierungsplaene fuer die naehere Umgebung gibt – es so etwas aber ausgerechnet an der Uni, an die immer wieder Konferenzteilnehmer*innen und sonstige Externe anreisen, ausschliesslich an der Haltestelle Kliniken Eselsberg gibt.

In einer Besprechung hatten die Stadtwerke zugesagt, Plaene nachzuruesten, sofern die Haltestellen dafuer noch freie Plaetze haben – und wir sagten zu, die dazugehoerigen Plaene zu bauen. Und nachdem Stefan Wehrmeyer mir beim occ13 noch einige Funktionen von TileMill naeher brachte, die ich bis dato nicht kannte, war der Weg schon einmal vorgezeichnet 🙂

Die Idee

Lokalen OpenStreetMap-Auszug von Ulm und Umgebung (genauer: Regierungsbezirk Tuebingen) downloaden, mit TileMill stylen, exportieren und aufbereiten


Die Umsetzung

Vorbereitung: TileMill und PostGIS installieren

(Siehe hierzu auch und

 sudo apt-get install tilemill postgresql postgresql-contrib postgis osm2pgsql
 sudo -u postgres createuser stk # as superuser
 sudo -u postgres createdb --encoding=UTF-8 --owner=stk tuebingen
 sudo -u postgres createlang plpgsql tuebingen

PostGIS einrichten, Karte laden und importieren

 sudo -u postgres psql -d tuebingen -f /usr/share/postgresql/9.1/contrib/postgis-1.5/postgis.sql
 sudo -u postgres psql -d tuebingen -f /usr/share/postgresql/9.1/contrib/postgis-1.5/spatial_ref_sys.sql
 sudo -u postgres psql -d tuebingen -f /usr/share/postgresql/9.1/contrib/postgis_comments.sql
 sudo -u postgres psql -d tuebingen -c "ALTER TABLE geometry_columns OWNER TO stk;"
 sudo -u postgres psql -d tuebingen -c "ALTER TABLE spatial_ref_sys OWNER TO stk;"
 osm2pgsql -c -G -d tuebingen tuebingen-regbez-latest.osm.pbf

osm-bright laden und anpassen

 git clone
 cd osm-bright
 # edit according to readme

Projekteinstellungen in project.mml:

"bounds": [
"center": [

POIs hinzufuegen

Icons: (SJJB)

sudo apt-get install librsvg2-bin

Waehrend die PNGs gerendert werden, Layer in Tilemill hinzufuegen:

      "geometry": "point",
      "extent": [
      "Datasource": {
        "type": "postgis",
        "table": "( SELECT name, highway, way\n  FROM planet_osm_point\n  WHERE building IS NULL AND highway IN ('bus_stop')\n  ORDER BY z_order ASC NULLS LAST\n) AS data",
        "key_field": "",
        "geometry_field": "way",
        "extent_cache": "auto",
        "extent": "918615.673665123,5965570.29255198,1144944.3842703,6260261.61701241",
        "dbname": "tuebingen",
        "user": "stk"
      "id": "transit",
      "class": "",
      "srs-name": "900913",
      "srs": "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0.0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs +over",
      "advanced": {},
      "name": "transit"
      "geometry": "point",
      "extent": [
      "Datasource": {
        "type": "postgis",
        "table": "( SELECT name, way, highway\n  FROM planet_osm_point\n  WHERE building IS NULL AND highway IN ('bus_stop')\n  ORDER BY z_order ASC NULLS LAST\n) AS data",
        "key_field": "",
        "geometry_field": "way",
        "extent_cache": "auto",
        "extent": "918615.673665123,5965570.29255198,1144944.3842703,6260261.61701241",
        "dbname": "tuebingen",
        "user": "stk"
      "id": "transitlabel",
      "class": "",
      "srs-name": "900913",
      "srs": "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0.0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs +over",
      "advanced": {},
      "name": "transitlabel"
      "geometry": "point",
      "extent": [
      "Datasource": {
        "type": "postgis",
        "table": "( SELECT *\n  FROM planet_osm_point\n  WHERE building IS NULL AND amenity IN ('biergarten', 'cafe', 'restaurant', 'bicycle_parking', 'charging_station', 'parking', 'atm') \n ORDER BY z_order ASC NULLS LAST\n) AS data",
        "key_field": "",
        "geometry_field": "",
        "extent_cache": "auto",
        "extent": "918615.673665123,5965570.29255198,1144944.3842703,6260261.61701241",
        "dbname": "tuebingen",
        "user": "stk"
      "id": "uulmpoi",
      "class": "",
      "srs-name": "900913",
      "srs": "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0.0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs +over",
      "advanced": {},
      "name": "uulmpoi"

und dann folgendes Styling in uulm.mss:

/* ****************************************************************** */

 #transitlabel[zoom >= 16] {
  text-name: [name];
  text-face-name: @sans;
  text-placement: point;
  text-fill: @poi_text;
  text-halo-radius: 2;
  text-halo-fill: @road_halo;
  text-min-distance: 2;
  text-placement-type: simple;
  text-allow-overlap: true;
  text-placements: "S,E,N,W,NE,SE,NW,SW,14,12,10";
  text-dx: 10;
  text-dy: 20;

 #transit[zoom = 16] {point-file: url(img/sjjb/transport_bus_station.glow.999999.12.png); }
 #transit[zoom >= 17] {point-file: url(img/sjjb/transport_bus_station.glow.999999.20.png); }
 #transit[zoom >= 19] {point-file: url(img/sjjb/transport_bus_station.glow.999999.24.png); }

 #uulmpoi [amenity='cafe'][zoom <= 16] {point-file: url(img/icon/cafe-12.png); }
 #uulmpoi [amenity='cafe'][zoom >= 17] {point-file: url(img/icon/cafe-18.png); }
 #uulmpoi [amenity='cafe'][zoom >= 19] {point-file: url(img/icon/cafe-24.png); }

 #uulmpoi [amenity='restaurant'][zoom <= 16] {point-file: url(img/sjjb/food_restaurant.glow.8E7409.12.png); }
 #uulmpoi [amenity='restaurant'][zoom >= 17] {point-file: url(img/sjjb/food_restaurant.glow.8E7409.20.png); }
 #uulmpoi [amenity='restaurant'][zoom >= 19] {point-file: url(img/sjjb/food_restaurant.glow.8E7409.24.png); }

 #uulmpoi [amenity='bicycle_parking'][zoom <= 16] {point-file: url(img/sjjb/transport_parking_bicycle.n.0092DA.12.png); }
 #uulmpoi [amenity='bicycle_parking'][zoom >= 17] {point-file: url(img/sjjb/transport_parking_bicycle.n.0092DA.20.png); }
 #uulmpoi [amenity='bicycle_parking'][zoom >= 19] {point-file: url(img/sjjb/transport_parking_bicycle.n.0092DA.24.png); }

 #uulmpoi[amenity='restaurant'][zoom >= 16] {
  text-name: [name];
  text-face-name: @sans;
  text-placement: point;
  text-fill: @poi_text;
  text-halo-radius: 2;
  text-halo-fill: @road_halo;
  text-min-distance: 2;
  text-placement-type: simple;
  text-allow-overlap: true;
  text-placements: "S,E,N,W,NE,SE,NW,SW,14,12,10";
  text-dx: 10;
  text-dy: 10;

FIXME die Marker sollten SVG sein, das ist noch TODO


Beim Rendern nach SVG oder PDF sehen die Labels (Strassennamen etc) seltsam aus: Buchstaben und Halos werden jeweils einzeln gerendert, so dass die Halos jeweils den naechsten Buchstaben ueberdecken. Das Problem scheint bekannt, siehe, bleibt wohl nur die manuelle Beschriftung. Ich habe einfach die Labels in einem separaten Layer exportiert, der eingeblendet werden kann (oder auch nicht)


Die Idealvorstellung war ja, dass sich der Prozess irgendwie automatisieren lassen wuerde, insbesondere wegen der Labels ging das aber nicht so einfach. Deswegen ging ich den folgenden Weg:

  • Einzelne Layer nacheinander exportieren, Breite 4000, Zoomlevel 17, Ausgabeformat PDF
    • Baselayer (Geometrien)
    • Strassenlabels
    • Transitmarker
    • POIs
  • Alle Layer in Illustrator (ich weiss, keine freie Software, gibts aber im PC-Pool an der Uni) zu einem Composite zusammenfuegen
  • Haendisch Beschriftungen hinzufuegen, einmal detailliert und einmal fuer den Uebersichtsplan
  • Alles in InDesign fuer den Druck anpassen

  • Optional: Versehentlich Schriftfarbe auf Passermarken setzen und sich wundern, warum die Glyphen pixelig rauskommen, bis man den Fehler bemerkt

Eine bessere Variante waere es, die Beschriftungen nochmals als eigene Datenquelle vorzuhalten und einzublenden, dann liesse sich das auch als SlippyMap exportieren, haette aber genau wieder dasselbe Problem, wenn man PDFs fuer den Druck exportieren moechte. Den derzeitigen Weg halte ich fuer einen gangbaren Kompromiss aus Aufwand/Ergebnis.