Schlagwort-Archive: opnv

Fahrplandaten, Zwischenstand 2020

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.

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.

Defending Rail in Europe

Eine Leseempfehlung: Jon Worth schreibt regelmaessig ueber (europaeische) Eisenbahn und die Probleme, die damit verbunden sind. Zum Beispiel ueber den Spagat, den die DB in ihren Rollen als (a) profitorientiertes Unternehmen und (b, in der Teilgliederung DB Fernverkehr) Rueckgrat des Eisenbahnfernverkehrs unternehmen muss:

DB, it seems, wants to profit-maximise, and not to maximise the number of people travelling by train, and for the sake of the environment the latter needs to be a vital priority.

[…]

As things stand, DB is neither a proper public service operator, nor is it a competitor in a liberalised market. Its half-way position most definitely does not suit the passenger, and does not encourage modal shift to railways.

Das ist ein vermeintliches Nischenthema, das uns als weitgehend un-organisierte OPV-Nutzer_innen jedoch massiv betrifft. Wie zum Beispiel die Streichung einer ganzen Reihe von Nachtzugangeboten zum Ende des Jahres 2014.

Wer sich dafuer also interessiert: Jon lesen 🙂

Anstrengungsfreier Nahverkehr – aber nur um den Preis der Anonymität

Frueher. War manchmal schon auch gut, aber nicht alles besser.

Frueher. War manchmal schon auch gut, aber nicht alles besser.

Seit ich zu studieren angefangen habe, lande ich mehrmals jährlich in irgendwelchen deutschen Städten, vor allem in Berlin –  um Freunde zu besuchen, Konferenzen und BarCamps zu besuchen, oder (wie häufig im Falle Berlins) um als Endpunkt irgendwelcher Urlaubs-(Tramp-)Reisen zu dienen. Und wann immer ich in Berlin – oder einer beliebigen anderen größeren Stadt, in der ich mehr als nur ein paar Tage verbringen werde – ankomme, werde ich mit der immer gleichen, nervigen Frage konfrontiert:

Welches Nahverkehrsticket soll ich nur kaufen?

Das klingt jetzt vielleicht ein wenig lachhaft. Und für jemand mit einem etwas weniger knapp gestrickten Budget, oder für Leute, die nicht ganz so auf Optimierung im Allgemeinen und optimalen Nahverkehr im Besonderen abfahren wie ich, ist das sicherlich auch eine lächerliche Frage. Ich halte das aktuelle Abrechnungsprinzip (nicht nur) im deutschen Nahverkehr aber für eines der größten Hindernisse auf dem Weg zu einem möglichst anstrengungsfreien Nahverkehr – weil man sich im Vorhinein aussuchen muss, wie häufig man den ÖPNV nutzen wird.

Exkurs: „Anstrengungsfrei“ heißt, alle mentalen oder physikalischen Barrieren beim Zugang zu öffentlichem Nahverkehr auf ein Minimum zu reduzieren. Das heißt beispielsweise eine enge Taktung (→ geringe Wartezeiten), saubere und klimatisierte Fahrzeuge, so einfache und angenehme Fahrplan- und Reiseinformationsabfragen wie irgendwie möglich, oder sogar die Minimierung empfundener (sic!) Wartezeiten, indem Echtzeit-Abfahrtsinformationen an Haltestellen bereitgestellt werden. Weitere Beispiele hierzu in der Arbeit von Katrin Dziekan.

Beispiel: Welches Ticket kaufe ich für eine Woche re:publica?

In Berlin habe ich beispielsweise zwei halbwegs sinnvolle Optionen, den dortigen (IMO hervorragenden) Nahverkehr zu benutzen. Eine Wochenkarte für die Tarifzonen AB kostet mich momentan 28,80 EUR und erlaubt mir eine unbeschränkte ÖPNV-Nutzung während dieser Zeit. Einzelfahrscheine kosten mich im Viererpack je 2,20 EUR – und ich kann übrig gebliebene Tickets immer einfach fuer den naechsten Berlinaufenthalt mitbringen (mit Vier-Fahrten-Karten Kurzstrecke lässt sich das dann noch für kürzere Fahrten supplementieren)

fahrscheine

In einer perfekten Welt wüsste ich natürlich schon vorher, wie häufig ich das Nahverkehrssystem einer Stadt verwenden werde – und für Berlin funktioniert das sogar mittlerweile halbwegs gut: Ich habe ein Gefühl für die Stadt bekommen, was mir erlaubt, grob abzuschätzen, wie häufig ich zu Fuß unterwegs sein werde und wann ich Bahn, Tram und Bus benutzen muss oder möchte. Falls ich nicht mehr als 13 Fahrten während meines Aufenthalts machen werde, komme ich mit Vier-Fahrten-Karten günstiger davon; falls ich vermutlich häufiger unterwegs sein werde, kaufe ich mir die Wochen-Umweltkarte.

Das funktioniert jedoch nur, wenn auch alles so abläuft, wie geplant. Einmal habe ich mehr Geld für Vier-Fahrten-Karten verbraten, als eine Umweltkarte gekostet hätte – bierselige Nächte sind in Berlin einfach nicht vollständig, wenn man nicht die Hälfte davon in der S- oder U-Bahn verbracht hat 😉
Andersherum geht das natürlich genauso. Vermeintlich meine Lektion gelernt habend, kaufte ich mir eine Wochenkarte – und verbrachte die Zeit hauptsächlich mit Leuten, die ebensowenig ein Problem mit langen Wanderungen durch eine Stadt hatten wie ich. Letztendlich kostete so jede tatsächlich gemachte Fahrt ganze 4,80 EUR. Nunja.

Die Idiotie dieses Systems ist seine absolute Unflexibilität, und der Grund dafür liegt in der Abrechnungsmodalität über anonyme Papierfahrscheine. Sobald ein Ticket entwertet und benutzt ist, existiert es praktisch nicht mehr: Das Geld ist ausgegeben, der Fahrschein verbraucht, die Kosten versunken. Falls ich tagsüber meine vierte Fahrt des Tages antrete, kann ich nicht einfach die drei zuvor benutzten Tickets aus der Hosentasche ziehen und sie gegen eine rabattierte Tageskarte eintauschen – die benutzten Tickets haben ja keinerlei Wert mehr.

Aus Sicht eines Verkehrsbetriebs oder -verbunds ist dieses System natürlich vollkommen nachvollziehbar und sinnvoll. Wer kann denn schliesslich beweisen, dass ich diese drei Fahrscheine nicht kurz vorher aus dem Abfalleimer eines U-Bahnhofs gezogen habe? Und selbst wenn das kein Problem wäre, bräuchte das Verkehrsunternehmen entweder passendes Equipment oder entsprechend Personal, um die Einzelfahrscheine zur Tageskarte „aufzuwerten“. Wer würde so etwas denn machen?

Naja, Transport for London zum Beispiel. Der Londoner Verkehrsverbund hat die altbekannten Papierfahrscheine zugunsten elektronischer Geldbörsen abgeschafft, und die Anonymität der Papierfahrscheine durch (maximal) Pseudonymität ersetzt.

Und aus Passagiersicht ist es das auch vollkommen wert.

Das Oyster-System von TfL

By Frank Murmann (Own work) [GFDL or CC-BY-3.0], via Wikimedia Commons

Oyster Card. By Frank Murmann (Own work) [GFDL or CC-BY-3.0], via Wikimedia Commons

Ich habe Oyster zum ersten Mal bei einem London-Trip 2007 ausprobiert, und war sofort angetan vom Konzept. Gegen ein Pfand von aktuell 5 GBP gibt es eine RFID-basierte Pay-As-You-Go Oyster Card, die dann an Automaten mit Geld aufgeladen werden kann.

Um eine Tube-Station zu betreten, wird dann die Karte an die Personenvereinzelungsanlage am Eingang gehalten, und am Ende der Reise wird auf dieselbe Art und Weise am Ausgang wieder ausgecheckt. Analog gibt es Kontaktpunkte in Bussen, oder auf Bahnsteigen „regulärer“ Eisenbahnlinien, so wie die an vielen DB-Bahnhöfen versteckten Touch and Travel-Kontaktpunkte.

[Public domain], via Wikimedia Commons

See page for author [Public domain], via Wikimedia Commons

Der meines Erachtens beste Clou des Systems ist aber nicht die Kostenersparnis durch den reduzierten Preis gegenüber klassischen Papierfahrscheinen, oder die zigtausenden Fahrscheine, die nicht gedruckt und weggeworfen werden, sondern die Fahrpreisdeckelung: Egal wie viele Fahrten an einem Tag unternommen werden, es wird niemals mehr als der Preis einer Tageskarte abgebucht werden. Das entspricht der Idee, nach der n-ten Fahrt eines Tages die bisher bezahlten Kosten von Einzelfahrscheinen auf ein Upgrade zu einem Tagesfahrschein anrechnen zu können — was natürlich nur geht, wenn nachvollzogen werden kann, dass diese Fahrscheine nicht etwa von anderen Passagieren erschnorrt oder aus dem Muell aufgelesen wurden.

Die Oyster-Karte ist dabei nicht einmal personengebunden: Genau wie eine reguläre Tageskarte übertragbar ist, kann auch die Oyster-Karte weitergegeben werden, so dass sich das Upgrade auf eine Tageskarte auch wirklich lohnt — was dann aber implizit passiert, sobald auch wirklich genügend Fahrten benutzt wurden. Die vorherige Überlegung, ob man auch wirklich die erkaufte Leistung auch ausreizt, entfällt. Eine mentale Hürde weniger!

Aber der Datenschutz!

Ja, der Datenschutz. Die Oyster-Karte ist nicht anonym, sondern maximal pseudonym: Zwar kann die Karte nur dann eindeutig an eine oder mehrere Personen gebunden werden, wenn die Aufladung per Kreditkarte erfolgt; die Speicherung vergangener Fahrten ist aber systeminhärent und kaum zu umgehen. Das reicht in Deutschland üblicherweise, um mindestens ein Unwohlsein zu verursachen; in der Regel wird die vereinte Front der Datenschützer_innen dann auch Menetekel von Totalüberwachung und gläsernen Passagieren an die Wand zu malen.

Und tatsächlich, in Cory Doctorows Jugendroman Little Brother gerät der Protagonist wegen seiner vom üblichen Muster abweichenden Mobilitätsnutzung des BART-Systems ins Visier der repressiven Regierung, gegen die er ankämpft (das Buch steht unter Creative-Commons-Lizenz, Fundstelle ist Seite 100 ff.)

Kein Wunder also, dass Versuche, die VDV-Kernapplikation als solch ein Zahlungssystem  in deutschen Verkehrsverbünden zu etablieren, auf Widerstand stoßen. „Der ueberwachte OPNV“ sei das, und impliziert wird, dass wir uns damit einer totalitären Kontrolle über unser Leben aussetzen.

Ich habe mit dieser Argumentation zwei Probleme. Erstens übersieht sie — wie so oft — die Machtfrage: Wer kann durch die bloße Verfügbarkeit von Mobilitätsdaten den Passagieren gegenüber Macht ausüben? Die Verkehrsverbünde und -unternehmen? Wohl kaum. Allenfalls einem repressiven Staat und seinen Organen billige ich das Vermögen zu solchem Handeln zu — und in dem Fall liegt das Problem im repressiven Staat begründet. Der geht aber auch von Papiertickets nicht weg.

Die Zukunft vernetzter Mobilitaet

von Julian Herzog (Eigenes Werk) [GFDL (http://www.gnu.org/copyleft/fdl.html) oder CC-BY-3.0 (http://creativecommons.org/licenses/by/3.0)], via Wikimedia Commons

von Julian Herzog • [more photography on my website] (Eigenes Werk) [GFDL oder CC-BY-3.0], via Wikimedia Commons

Zweitens lässt diese Papierfahrscheinromantik außer Acht, wie sich Mobilität in der Zukunft weiterentwickeln wird. Car2Go hatte in Ulm immerhin (ohne große Feierlichkeiten) seinen sechsten Geburtstag, und hat mit seinem von manchen Bike-Sharing-Modellen abgeschauten Free-Floating-Konzept und minutengenauer Abrechnung den Markt deutlich aufgerüttelt. Uber rüttelt noch heftiger, momentan ohne dass man vorhersagen könnte, welche mittelfristigen Folgen das für den Taximarkt hat. Und selbstfahrende Autos fahren immerhin schon als Versuchsträger durch die Ulmer Straßen.

Interessant wird vor allem werden, wie sich solche verschiedenen Verkehrsmodalitäten künftig mit klassischem ÖPNV verknüpfen lassen. Beispielsweise, indem Free-Floater, Bikesharing oder gar selbstfahrende Autos nicht etwa mit Bus und Bahn konkurrieren, sondern diese ergänzen — durch Spezialtarife nach Betriebsschluss des klassischen ÖPNV, zum Beispiel. Oder indem das klassische Ticket in das NFC-System des Smartphones integriert wird, das die Vorbestellung von Anrufsammeltaxis oder Rufbussen am Ende einer Reise in den ländlichen Bereich gleich miterledigt.

Der DING ist einer der Verbünde, die hier mit dem „Ticket2Mix“ einen bescheidenen, für Verhältnisse deutscher Verbünde aber schon beinahe revolutionären Anfang machen: Neben der regulären Monatskarte sind auch Freiminuten bei drei Carsharing-Anbietern in Ulm und Umgebung im Ticketpreis enthalten. Das entfaltet noch lange nicht das Potenzial, das in RFID-Fahrscheinen steckt, aber gibt zumindest einen winzigen Vorgeschmack auf das, was möglich wäre.

Aber eben nur, solange ein reibungsloser und attraktiver Nahverkehr und die damit verbundenen Folgen für Lebens- und Wohnqualität nicht als weniger wichtig angesehen werden, als dass er unbedingt anonym zu benutzen wäre.

Randnotiz: VDV-Kernapplikation und die in Deutschland getesteten Prototypen haben allesamt ihre Macken und Probleme, insbesondere bei der Usability. Mir geht es aber um das Grundprinzip dahinter, und den Widerstand gegen das System allein aus dem Standpunkt heraus, dass Datenschutz schwerer wiege.

Nachtrag vom 2014-10-20: Der Titel dieses Artikels endete ursprünglich mit „verhindert durch Datenschutz“. Das ist vermutlich irreführend gewesen, denn tatsächlich gibt es mit Touch und Travel ja ein vergleichbares System (wenngleich hier umgekehrt als bei Oyster aktive Endgeräte und passive Berührpunkte verwendet werden), und es gibt keine mir bekannten datenschutzrechtlichen Bestrebungen, vergleichbare Ticketingsysteme zu verbieten oder einzuschränken. Gemeint war der Artikel insbesondere als Replik auf den verlinkten Blogartikel, in dem vom überwachten Nahverkehr die Rede war, und sämtliche anderen Horrorvisionen einer komplett überwachten Gesellschaft. Der Zyniker in mir würde ein verbundübergreifendes intelligentes Ticketingsystem ohnehin zunächst an den Verbünden und dem VDV und danach an einer Vergabe an T-Systems oder Siemens scheitern sehen 😉

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.

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.

uni-forum

 

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.

Werkzeugkiste

Mal wieder ein Open-Data-Rundumschlag: den Einsteig macht ein Interview der bpb mit Marian Steinbach, der auf der rp13 seine Bemuehungen vorstellte, die Datenformate von Ratsinformationssystemen zu standardisieren. Ueberraschenderweise machen hier die RIS-Anbieter richtig Dampf, man darf gespannt sein – nicht zuletzt, weil auch Ulm hier etwas anbieten moechte – und somit irgendwann auch fuer Ulm ein Angebot wie offeneskoeln moeglich sein koennte.

Aus Koeln kommen auch einige Wunschlisten, was man sich denn gerne so alles wuenschen wuerde: Einmal eine Open-Data-Wunschliste fuer NRW, einmal die Variante fuer die Stadt Koeln.

In Muenchen scheint das Engagement derweil eingeschlafen zu sein und sich gar nichts mehr zu tun – was Roland Moriz so geaergert hat, dass er ein Blog eingerichtet hat und nun nach MitstreiterInnen sucht.

 ♦

Oft ist das Problem ja nicht einmal, dass Daten gar nicht verfuegbar waeren, sondern dass sie in irgendwelchen PDFs versteckt sind. Noch schlimmer ist, wenn das PDF-Tabellen sind, da wird dann selbst das Parsing mit pdftotext… anstrengend.

Bildschirmfoto vom 2013-05-17 18:50:01

Introducing: Tabula. Die freie Software kann einfach von Github gezogen und lokal installiert werden – danach koennen beliebige PDFs hochgeladen und die zu parsenden Tabellen per Drag and Drop ausgewaehlt werden. Poof: Eine CSV-Tabelle! Hurra!

Eine Livedemo (bei der man aber nichts eigenes hochladen kann) gibt es hier.

Weitere PDF-Exporter neben tabula und pdftotext – insbesondere auch fuer Windows-Systeme – sind nebenan bei der Knight Foundation gesammelt.

 ♦

Nachdem’s hier schon lange nix mehr zu Geodaten und Karten gab, und R auch nicht jedermanns Sache ist, hier der Verweis auf Lisa Williams‘ Blog, speziell auf die zwei Artikel The Insanely Illustrated Guide To Your First Data-Driven TileMill Map und The Absurdly Illustrated Guide To Your First Dynamic, Data-Driven Timeline.

Beide Artikel sind in der Tat wahnsinnig absurd hervorragend bebildert und zeigen den kompletten Weg zum fertigen Produkt – im Fall der Karte also tatsaechlich von der Datenakquise ueber eigene Geocoding-Scripte in Google Docs (sic!) bis hin zur angepassten TileMill-Karte. Sehr schoen!

(Wer Spanisch kann, kann solcherlei Dinge auch im neuen MOOC der Knight Foundation lernen, der aktuell stattfindet)

 ♦

Wer trotzdem gerne mit R arbeiten moechte: Da gibts nun eine neue Version des OpenStreetMap-Packages, das nun auch jede Menge zusaetzlicher Tileserver unterstuetzt. Einziger Nachteil: Hat Java-Dependencies.

(via)

 ♦

Noch ein Kartenfundstueck: Die ÖPNVKARTE nutzt die OpenStreetMap-Daten, um eine um Nahverkehrsdaten angereicherte Karte auszugeben. Huebsch.

 ♦

Tiaga Peixoto stellt die Frage, ob „Open Government“ ueberhaupt etwas mit Transparenz und vor allem Rechenschaftspflicht zu tun haben muss:

ABSTRACT

By looking at the nature of data that may be disclosed by governments, Harlan Yu and David Robinson provide an analytical framework that evinces the ambiguities underlying the term “open government data.” While agreeing with their core analysis, I contend that the authors ignore the enabling conditions under which transparency may lead to accountability, notably the publicity and political agency conditions. I argue that the authors also overlook the role of participatory mechanisms as an essential element in unlocking the potential for open data to produce better government decisions and policies. Finally, I conduct an empirical analysis of the publicity and political agency conditions in countries that have launched open data efforts, highlighting the challenges associated with open data as a path to accountability.

[…] CONCLUSION

As a whole, this analysis advises caution on the part of policymakers and advocates with regard to the potential of open data to foster accountability. Even when data is politically important, accounting for the publicity and political agency conditions might be a commendable reflection for a better understanding of the prospects and limits of open data.

PEIXOTO, Tiago. The Uncertain Relationship Between Open Data and Accountability: A Response to Yu and Robinson’s The New Ambiguity of “Open Government”. DISCOURSE, 2013, 60. Jg., Nr. 6.

(via)

In eine aehnliche Richtung geht auch dieser DLF-Bericht u.a. mit Ina Schieferdecker, Michael Kreil et al.

(via)

Und zum Schluss noch ein wenig Urheberrecht. Denny Vrandečić (u.a. von Wikidata) exkursiert eine Weile ueber Lizenzfragen bei Daten(banken) und kommt zu dem Schluss, dass mensch hier bei der Veroeffentlichung allenfalls CC0 als „Lizenz“ verwenden sollte – mit dem Argument dass, wer CC-BY oder ODbL verwendet, die Position staerkt, dass rohe Daten ueberhaupt schutzfaehig im Sinne des Urheberrechts sind:

The extension from works to content, from expression to ideas, is another dimension, this time in scope instead of time, in the continuous struggle to extend and expand intellectual property rights. It is not just a battle over the laws, but also, and more importantly, over our believes and minds, to make us more accepting towards the notion that ideas and knowledge belong to companies and individuals, and are not part of our commons.

Every time data is published under a restrictive license, “they” have managed to conquer another strategic piece of territory. Restrictive in this case includes CC-BY, CC-BY-SA, CC-BY-NC, GFDL, ODBL, and (god forbid!) CC-BY-SA-NC-ND, and many other such licenses.

Every time you wonder what license some data has that you want to use, or whether you need to ask the data publisher if you can use it, “they” have won another battle.

Every time you integrate two data sources and want to publish the results, and start to wonder how to fulfill your legal obligation towards the original dataset publishers, “they” laugh and welcome you as a member of their fifth column.

Let them win, and some day you will be sued for mentioning a number.

(via @johl)

Ein ereignisreiches Open-Transit-Wochenende

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

DIVA-Allueren

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

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

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

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

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

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

Ausflug zum VBB und endlich Ulmer GTFS-Daten 🙂

gtfs

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

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

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

okfbuero

 

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

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

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

Trampstatistik

Hinweg:

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

Rueckweg:

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

Apps and the City

Der erste „Apps and the City“-Hackday lockte ueber 100 EntwicklerInnen in den Supermarkt Berlin — mit einigem Medienecho im Deutschlandfunk (direkt zur MP3) und in der RBB-Abendschau (Direktlink).

Praktischer Nahverkehr auf Basis offener Daten scheint also doch oeffentliches Interesse zu erregen 🙂

(zugehoeriger Blogeintrag bei der OKFN / verwandt: Sieben scheinbare Gruende gegen offene Daten)

Erste Schritte in QGIS

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

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

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

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

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

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