OpenData beim RMV

Am 04.07.2013 hatten @levudev, @scy und ich die Möglichkeit mit Herrn Redmann (Leiter IT) vom RMV in Hofheim über das Thema OpenData zu sprechen, da der RMV aktuell Echtzeitdaten der Fahrzeuge in die Haltestellemasten integriert.

Herr Redmann erklärte zu Beginn die allgemeine Struktur des RMV. Er wies unter anderem darauf hin, dass der RMV, wie alle anderen Verkehrsverbünde auch, auf Zuschüsse aus Steuermitteln angewiesen ist. Mit einer Quote von ca. 50% Zuschüssen steht er dabei im bundesweiten Vergleich noch relativ gut da. Das Ziel des RMV ist ganz klar vorgegeben: „Das Angebot des öffentlichen Personennahverkehrs ist daher vorausschauend, nutzerorientiert, attraktiv, leistungsfähig und effizient zu gestalten.“ (§ 3 ÖPNVG)

Nach den einleitenden Informationen ging es zum eigentlichen Thema. Herr Redmann erläuterte, dass es 3 verschiedene Kategorien von Daten gibt, die unterschiedlich behandelt werden. Zum einen gibt es die Infrastruktur-Daten. Diese Daten sind offen und werden auf Anfrage auch weitergegeben. Dabei handelt es sich um Eigenschaften der einzelnen Haltestellen, z.B. wo sich diese befinden (GPS-Koordinaten) und ob sie barrierefrei sind. Möglicherweise wird es diese Daten auch irgendwann zum direkten Download auf der Seite des RMV geben. Mit diesen Daten geht der RMV also sehr offen um. Einzige Bedingung des RMV hier: Wer die Daten verwendet, soll keine alten Daten verwenden sondern sich mindestens jährlich drum kümmern, vom RMV die aktuellen Daten zu bekommen. Schließlich ist es blöd, wenn eine App, die einem die nächste Haltestelle zeigen soll, einem eine Haltestelle zeigt, die seit einem Jahr nicht mehr angefahren wird.

Anschließend erklärte Herr Redmann wie es um die Fahrplanrohdaten oder Soll-Daten bestellt ist. Vereinfacht gesagt handelt es sich dabei lediglich um die Fahrpläne der einzelnen Linien: Wann und wo fahren Bahnen und Busse ab. Diese Daten gibt der RMV nur unter bestimmten Bedingungen heraus, da sich diese Daten nahezu täglich ändern. Das liegt vor allem an Verkehrsänderungen, Unfällen, bei denen Strecken nicht sofort wieder befahrbar sind, Sonderverkehren und anderen Dingen, die den ÖPNV beeinflussen. Diese Daten sind komplexer als weithin angenommen. Einen Algorithmus zu schreiben, der daraus sinnvolle Fahrplanauskünfte erstellt, ist nicht einfach. Was solch ein Algorithmus zum Beispiel berücksichtigen muss, ist der Fußweg von einer zu nächsten Haltestelle bzw. zwischen verschiedenen Gleisen oder Abfahrtsorten an der selben Haltestelle. Wenn eine Bahn an Ffm Tief ankommt und der Anschluss oben eine Minute später abfährt, wäre diese Verbindung nicht zu bekommen. Der RMV hat ein Interesse daran, realistische Verbindungen vorzuschlagen: In die Planung der Verbindungen und der Umstiege fließt viel Detailarbeit, die dafür sorgen soll, dass Fahrgäste optimal versorgt werden. Mit einer externen Anwendung, die mit den Rohdaten der Fahrplänen arbeitet, kann das nicht gesichert werden.

Aus diesen Gründen arbeitet der RMV an der Bereitstellung einer API, um einerseits die volle Kontrolle über die erstellten Fahrplanauskünfte und den verwendeten Algorithmus zu haben und andererseits den ÖPNV attraktiver zu machen. Allerdings wird es zum Schutz vor Missbrauch (Verfügbarkeit der Server) einen API-Key mit einer begrenzten Anzahl an Zugriffen geben. Wer den Dienst stärker nutzt, muss das begründen und/oder einen nutzungsabhängigen Betrag zahlen.

Durch diese Maßnahme kann der RMV sicherstellen, dass die Fahrplanauskünfte realistisch sind, denn in den Berechnungen sind auch die Echtzeitdaten verfügbar. Diese Pflege wäre für eine externe Anwendung allein zeitlich schwierig umzusetzen. Sobald diese API fertig ist, wäre der RMV auch nicht abgeneigt einen Hackday zu veranstalten, auf diesem können dann die ersten Anwendungen mit der neuen API entstehen. Konkrete Planungen für diesen Tag oder einen Fertigstellungstermin der API steht allerdings noch nicht fest.

Wiesbaden und die liebe Transparenz

Am 10.12.12 hat jemand™ einen Bürgerantrag an unsere Fraktion in Wiesbaden gestellt. In diesem Antrag ging es schlicht um das Einführen von OpenData [1] in Wiesbaden. Dieser Bürgerantrag mündete schließlich in einem Antrag an den Ausschuss für Bürgerbeteiligung am 29.01.13 [2]. Im Ausschuss selbst haben dann die Regierungsfraktionen (CDU und SPD) aus dem Antrag zur Einführung einen reinen Berichtsantrag gemacht. Der Magistrat solle doch mal berichten, was da auf uns zukommt und vor allem was an Kosten entstehen würde.

Am 14.05.13 war es dann auch endlich soweit. Der Magistrat hat berichtet, was das ganze denn so kosten würde. Die Übersicht findet ihr unter [3]. Als ich die Preise sah, war ich doch „etwas“ verwundert. Dort werden für die nächsten 4 Jahre 892.000 € veranschlagt. Dabei konnte es sich doch nur um einen schlechten Scherz handeln.

Ich recherchierte ein wenig und fragte die ein oder andere Person, die sich mit dem Betrieb und vor allem der Einführung besser auskennt als ich. Wenig erstaunlich stellte sich heraus, dass die Stadt Wiesbaden hier WEIT übers Ziel hinaus geschossen ist. Um das zu Vergleichen ziehe ich mal govdata.de herran. Das Datenportal des Bundes(!). In der dortigen FAQ [4](erster Reiter ganz unten) sind einige Kosten aufgeführt. Dort steht, dass die Realisierungskosten (also Entwicklung) 130.000 € betragen, sowie die Kosten für Wartung, Pflege und Betrieb 22.500 € für das erste Jahr.

Schauen wir uns jetzt mal an, was Wiesbaden für die ersten 4 Jahre veranschlagt hat: Entwicklung 80.000 €, Wartung und Pflege 50.000 €, Betrieb 240.000 €. Es wird also mit 60.000 € pro Jahr für Wartung, Pflege und Betrieb kalkuliert. Man möchte uns also tatsächlich erzählen, dass ein OpenData-Portal für eine Kommune mehr Kosten verursacht, als das für den gesamten Bund? Das glaubt ihr doch selbst nicht!

Nun wissen wir aber, dass Wiesbaden nicht die erste Verwaltung ist, die über die Einführung nachdachte (dank des Antrages zwangsweise). Es gibt ja schließlich schon Verwaltungen die OpenData eingeführt haben und sich in der Umsetzung befinden. Es wäre also ein leichtes aus diesen Verwaltungen den Source Code für ein bereits existierendes Portal zu erhalten.

Selbst wenn das nicht klappen sollte, zeigt die Erfahrung aus andern Städten und dem Ausland, dass es billiger geht. Eine Kanadische Großstadt kostet der Betrieb ca, 200-300 US$/Monat und schaffte es innerhalb von 2 Wochen online zu gehen [5]. Auch das Hosting an sich ist nicht teuer. Für maximal 500 € bekommt man eigentlich schon was vernünftiges.

Alles in allem die Realisierung von einem OpenData-Portal kein Hexenwerk und vor allem wesentlich preisgünstiger. Aus Rostock hab ich erfahren, dass für das komplette Projekt, von der Planung bis zum Start 3 Monate ins Land gingen und das komplette Teil 4.000 € (in Worten: viertausend) gekostet hat. Das Hosting erfolgt auf eigener Hardware und als Software wird CKAN [6] verwendet. Umgesetzt haben das 2 Mitarbeiter mit 30% und ein Informatikstudent, der sein Praktikum leistete.

Seit dem Start hat Rostock einen Aufwand von ca 1-2 h pro Woche. Darunter zählt dann auch die Aufbereitung und Akquierierung neuer Daten. Das kann zwar in einzelnen Fällen steigen (z.B. beim Haushalt) aber eine allzu große Mehrbelastung ist das jetzt nicht.

Die knapp 900.000 € sind also weit ab vom Schuss, was man tatsächlich für die Umsetzung brauchen würde. Da der Antrag nach der Bekanntgabe im Ausschuss für „Durch Aussprache erledigt“ erklärt wurde, sagt mir das, dass in Wiesbaden Transparenz durch Aussprache erledigt ist. Aber das ist ja nichts Neues [7] und [8].

[1] http://de.wikipedia.org/wiki/Open_Data
[2] http://linke-und-piraten-wiesbaden.de/antrag/open-data
[3] http://linke-und-piraten-wiesbaden.de/downloads/drucksachen/Kostensch%C3%A4tzung%20Open%20Data%20TOP%2011%20BVI%202013-05-14.pdf
[4] https://www.govdata.de/web/guest/faq
[5] http://blog.mastermaq.ca/2010/01/13/open-data-comes-to-edmonton/
[6] http://ckan.de/
[7] http://debaernd.de/2012/02/03/rathaus-tv-durch-aussprache-erledigt/
[8] http://debaernd.de/2011/12/07/beteiligungverstandnis-der-cdu-wiesbaden/