Schlagwort-Archive: OpenTransit

Adding shapes to GTFS feeds with pfaedle

Headway frequency mapping in R. Requires shapes.txt

Three years ago, I wrote a little piece about how we cleaned up SWU’s GTFS feed.

I nonchalantly added that adding shapes and Conveyal’s GTFS editor would be a topic for another time, but never came around writing about that. I do not use the GTFS editor anymore, but Patrick Brosi’s pfaedle tool is still invaluable if your GTFS feed does not come equipped with a functional shapes.txt.

I had described the problem and where to find the proper tools back in early 2020 right at the intersection of my activism and public administration work. With the regional transit area spanning two Bundeslaender, there are some pitfalls left, however. Hence, a short primer.

Ingredients:

  • One Linux machine, whatever the flavor. Be it a VM or an old Laptop, it hardly matters. It shouldn’t be the slowest available machine, though, and it should come with a decent amount of RAM (the machine I’m using has 8 GiB). And if you go the germany-latest route (see below), about 100 GiB of hard disk space are required.
  • cmake, gcc (>4.9), git, wget, bzip2: sudo apt install cmake gcc git wget bzip2
  1. Get pfaedle, which is pretty much following the steps outlined in the github repo:
git clone --recurse-submodules https://github.com/ad-freiburg/pfaedle
mkdir build && cd build
cmake ..
make -j4
# optionally:
make install

2. Navigate to the folder where you store your unzipped(!) GTFS feed you want to add shapes to.

3. Get the proper OSM files. Since we are working with Ulm and Neu-Ulm, we’d either need a download of the metropolitan area of both cities, or download and merge the extracts for Bavaria and Baden-Wuerttemberg… or download and use the extract for the whole of Germany :shrug:

# Whole of Germany
wget https://download.geofabrik.de/europe/germany-latest.osm.bz2
bunzip2 germany-latest.osm.bz2

# Merge, requires osmium-tool: apt install osmium-tool
wget https://download.geofabrik.de/europe/germany/bayern-latest.osm.bz2
wget https://download.geofabrik.de/europe/germany/baden-wuerttemberg-latest.osm.bz2
bunzip2 bayern-latest.osm.bz2 && bunzip2 baden-wuerttemberg-latest.osm.bz2
osmium merge baden-wuerttemberg-latest.osm bayern-latest.osm -o merged.osm

Beware: Unzipping the GTFS feeds takes ages, especially the germany-latest. Expect a file exceeding 70 GiB and quite some decompression time. My laptop takes about 4–5 minutes for each Bundesland to unpack.

All that is left to do now is to let pfaedle do it’s work: pfaedle -D -x merged.osm .
After completion (and again, using it with germany-latest.osm takes quite a lot of time), a new folder gtfs-out is created. Test the results with your usual testing suites, ZIP it up, and off you go.

Fahrplandaten, Zwischenstand 2020

„Wissen nicht woher“: Apple greift VGN-Daten für Maps ab. #Nürnberg nordbayern.de/region/nuernbe… None

Seit September 2006 gibt es das GTFS-Format fuer Soll-Fahrplandaten des oeffentlichen Verkehrs, entstanden mehr als Zufalls-Seitenprojekt aus einer Kooperation zwischen einem Google-Maps-Entwickler und dem Portlander Verkehrsverbund. Gedacht war es als Standard-Austauschformat, um Fahrplandaten in verschiedene beliebige Verkehrsauskuenfte zu integrieren – auch Google Maps, aber eben auch viele andere Anwendungen.

In Deutschland dauerte es sehr lange, bis GTFS oder das sehr viel umfangreichere NeTEx-Format halbwegs breit als Grundlage fuer Open-Data-Fahrplaene angeboten wurde. Deutsche Verkehrsverbuende sind vielfach bis heute der Ueberzeugung, dass nur sie selbst „richtige“ Auskuenfte geben koennen. Das wuerde ich generell sowieso in Frage stellen, aber das ist gaengige Policy, und auch in der VDV-Schrift 7030 „Open Service“ in eine wirklich haarstraeubende Sammlung zurschaugestellter Ahnungslosigkeit und Falschdarstellungen zusammengefasst. Teile der Geschichte dazu lassen sich in meiner Diplomarbeit von 2014 (sic) nachlesen.

Sehr sehr langsam tat sich aber etwas in Deutschland – auch weil Anfang Dezember 2019 die Delegierte Verordnung (EU) 1926/2017 die Auslieferung aller(!) Soll-Fahrplandaten ueber einen Nationalen Accesspoint zur Pflicht machte. Die Verbuende, die sich lange Zeit wehrten, mussten also nun ihre Fahrplaene offenlegen, auch zur Nachnutzung durch Dritte. Die Open-Data-Landkarte, auf der 2013 nur der VBB und die vergleichsweise winzigen Stadtwerke Ulm zu finden waren, faerbte sich nach und nach:

Wenn auch viel zu spaet und sehr schleppend und weit entfernt von den skandinavischen Best-Practise-Beispielen, die hier meilenweit voraus sind: Es tat sich was.

Das schien nun also der Anlass fuer diverse Diensteanbieter zu sein, nun auch die notorisch verspaeteten deutschen Verbuende in ihre Auskuenfte einzubinden. So auch Apple Maps, die offenbar nun einige Regionen mehr in ihre Auskunft aufnahmen – was zu diesem denkwuerdigen Artikel auf nordbayern.de fuehrte, der einem nochmal plakativ vor Augen fuehrt, auf welchem unterirdischen Niveau wir 2020 noch ueber intermodale Verkehrsauskuenfte reden. Beste Zitate:

Die Daten stammen, so behauptet es Apple in der App, von der Verkehrs-Aktiengesellschaft Nürnberg (VAG) und dem Verkehrsverbund Großraum Nürnberg (VGN). Dort allerdings wundert man sich. „Es gibt keine vertragliche Vereinbarung (…) zu einer Überlassung von Fahrplandaten“, sagt VGN-Sprecher Manfred Rupp. „Wir wissen auch nicht, woher Apple die Fahrplandaten zu den VGN-Linien hat.“ Man könne, sagt Rupp, nur spekulieren – und sei dabei, die technischen Vorgänge aufzuarbeiten.

Das ist wirklich bemerkenswert, denn auf der Website des VGN selber findet sich ein Punkt „Soll-Fahrplaene im GTFS-Format“, und ueber den Standardvertrag der Creative-Commons-Lizenz ist auch die vertragliche Ueberlassung von Fahrplandaten ganz klar geregelt (Ueberlegungen, ob es sich bei Fahrplandaten ueberhaupt um ein urheberrechtlich geschuetztes Werk handelt, auf das auf dem UrhG basierende Lizenzen anzuwenden sein koennen, seien mal aussen vor gelassen).

Im weiteren Text wird zunaechst behauptet, Apple erwecke den Eindruck, dass es sich um Echtzeitdaten (also unter Einberechnung von Verspaetungen) handle. „Das könne aber gar nicht sein […] Die liegen nicht einmal mehr auf unseren Servern“ wird der VGN zitiert. Einen Absatz weiter wird jedoch zurueckgerudert, dass es sich um „aeltere“ Soll-Fahrplandaten unklaren Alters handelt.

Diese Reaktion ist fuer mich wirklich erschreckend. Ziel des VGN muesste es sein, eine stabile Quelle tagesaktueller Soll-Fahrplaene bereitzustellen. Sollte Apple wirklich den GTFS-Feed des VGN vom Dezember 2019 benutzen und dieser nicht aktuell sein, liegt das Problem glasklar auf Seiten des Verbunds. Er hat dafuer zu sorgen, dass Dritte Daten in guter Qualitaet nutzen koennen – spaetestens seit der Delegierten Verordnung. Und die vielfach als Argument angefuehrten Echtzeit-Ist-Daten sind vielmehr ein gewichtiges Argument, spaetestens jetzt die Vorbereitungen zu treffen, auch diese Daten fuer Dritte nutzbar ausspielen zu koennen. Denn Echtzeit und Open Data schliessen sich nicht aus – wenn man denn wie die Skandinavier auf die richtigen Formate setzt, anstatt dem VDV-Unsinn rund um den sogenannten „Open Service“ nachzulaufen.

Die Uhr tickt indes. Spaetestens im Dezember 2023 ist die Ausspielung der dynamischen (Echtzeit) Daten gemaess DV 1926/2017 EU-weit gefordert und nicht mehr nur optional. Ich bin gespannt, ob die deutschen Verbuende das auch so grandios verkacken werden wie bei den Soll-Daten.

PS: Wer Lobbyarbeit machen moechte: Die Karte oben stammt aus dem 2017 als Spassprojekt gestarteten One-Click-Lobby-Projekt rettedeinennahverkehr.de – dort kannst du dich mit wenig Aufwand an deinE LandraetIn oder OberbuergermeisterIn wenden.

Wie Städte die Mobilität der Zukunft gestalten

Linkliste zum Vortrag auf der re:publica. Arbeitsfassung vom Dienstag; wird noch erweitert werden.

Das Upgrade auf Stage 2 war etwas arg respekteinfloessend. Sorry auch an alle, die die Torten der Wahrheit erwartet hatten; als Ausgleich folgender Versuch

Silicon-Valley-Techsolutionismus

Silicon Valley erfindet den Bus neu. Ein Drama in mehreren Akten:

Elon Musk, Monorail-Verkaeufer

Gemeint ist diese Episode: Marge vs. the Monorail – S04E12 bei den Simpsons, Wikipedia:EN

I have a new favourite transport related meme!

Sourced from this hilarious facebook group: buff.ly/2sXP7Ub pic.x.com/hvvzw5ooqa

Screenshot von Volker Blees beim Verkehrsministerium Baden-Württemberg im April 2019

Vernetzte Verkehrstraeger

Technologische Souveraenitaet; Oeffentliche Gelder → Oeffentliche Gueter

Mobilitätsportal Karlsruhe

Open-Data-Community: Code for Germany

Oertliche Communities mit oeffentlicher Foerderung: BonnLab, hackspace moers, WesterwaldLab Betzdorf, Verschwoerhaus Ulm, plus unzaehlige andere, tolle, nicht staedtisch gefoerderte als Vorbild (zB Dingfabrik Koeln, Eigenbaukombinat Halle, die Liste koennte hier quasi endlos sein)

Code for America Fellowship

Digitransit: Offizielle Seite; Deployment in Helsinki; Github-Repositories; Architektur; Ulmer Alpha-Deployment

Datenraum Ulm: GTFS-Daten der SWU; rettedeinennahverkehr.de; GD 411/18 (Anlage 1, Anhang 2 ist hier relevant)

Herrenberg: https://mobil-in-herrenberg.de/; TTN-Links folgen

Mitfahrdezentrale: Twitter @mfdz_de

Radforschung: radforschung.org

Mobility Data Specification

Spezifikation auf Github

Was Städte lernen können (radforschung.org)

MDS für Kommunen erklärt (radforschung.org)

Weitere Lektüre

Verkehrspolitik – eine Interdisziplinäre Einführung (Oliver Schwedes, Hrsg) (via @gglnx)

It’s not all lightbulbs – If we abandon the cult of the Great White Innovator, we will understand the history of technology in a much deeper way

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.zip 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
ZUP 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;
else:
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:

Wer veröffentlicht Fahrpläne als #OpenData in DE?
Ich kenne SWU, VBB, VRS, RNV, DB Fernverkehr via API.
#GTFS pic.x.com/rxmgoesuno

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

IMG_1104

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.

Begrüßung durch Friederike Schulte und Katja Schwab zum #opendata #hackathon pic.x.com/a5k2k3etjb

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.

Teams working pic.x.com/pznegef9wu

Diskussionen und networking pic.x.com/pkj6k8ctcd

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.

Frieda die kleine Tochter von Fritz pic.x.com/uwnpmluei7

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.

Großartiger #DBHackathon war großartig! pic.x.com/lw7sktgnt5

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.

Kurios: Zwischen all den MacBooks hat sich gestern Abend spontan eine reine Thinkpad-Gruppe gefunden. #DBHackathon pic.x.com/h7tiixdulc

Pimp the Reiseauskunft der @DB_Bahn! #DBHackathon pic.x.com/cogtu0abqq

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 😉

Schade, dass das Geschlechterverhältnis beim #DBHackathon so sehr unausgeglichen ist. @DB_Bahn, wollt Ihr dagegen in Zukunft etwas machen?

Moers: Die heimliche Open-Data-Hauptstadt im Nirgendwo

Während @ulmerleben in FFM beim #DBHackathon codet, sind @gruenzeug und @_stk nun beim #ODDMO15 🙂 #ulmapiontour pic.x.com/l2i30bpv4c

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.

.@drewSaysGoVeg is talking about examples of OpenData #ODDMO15 pic.twitter.com/2JEqsEKGhV

— Elmar Burke (@elmarburke) March 21, 2015


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 rockt! Vielen Dank an @OpenDataMoers, @derarndt & @nowanda1 für diesen tollen #ODDMO15! #opendata #ddj pic.x.com/4oncrghdwz

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.

Ausklang des ersten Tages bei @OpenDataMoers pic.twitter.com/gOUmW79GrD

— Madeleine Neumann (@Maggysche) March 21, 2015

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 😉

Die Moerser Feuerwehr beteiligt sich mit dem Projekt OpenAufzug am #oddmo15. „Kein Ding, wir war’n mal Bergleute!“ pic.x.com/uuzoxdjrxi

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.

Fun, fun, fun. @codeforde doing a spectogram at their national workshop pic.twitter.com/6mxaMQS1l8

— drew on the web (@drewSaysGoVeg) March 28, 2015

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.

Replying to @codeforde @codeforde Award 2015 für @UlmAPI und Jena #codeforde pic.x.com/twxhs1dgyc

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 😉

Mission-Statement-Puzzle #crowdsourcing pic.x.com/h81zdql8sm

Free and Open Source your Transit System, Now!

IMG_0781

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

Culture

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.

(via)

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