Generell ist zwischen einer Schnittstelle (API-Endpunkt) und der Bereitstellung von Bulk-Datensätzen zu unterscheiden. Letztere waeren beispielsweise die DS100-Schlüssel samt relevanter Daten dazu (Koordinaten, weitere Schlüssel wie IBNR etc.) in einem offenen, strukturierten Format. Fuer Daten mit seltenen Änderungen wie einen Sollfahrplan ist die Bereitstellung als Bulk-Datensatz vorzuziehen.
Die Bereitstellung sollte sich an den 5 Sternen für offene Daten orientieren und hier möglichst viele der 5 Sterne zu erreichen versuchen.
Fuer API-Endpunkte sollte sich die Bereitstellung an etablierten internationalen Standards orientieren, deren Spezifikation frei verfuegbar ist.
Rohdaten sind in den meisten Fällen vorzuziehen. Eine pauschale Aussage zu Veredelungen fällt schwer, das kommt auf den Einzelfall an.
Wenn möglich, soll auch im Falle einer „Veredelung“ gleichzeitig Zugriff auf die Rohdaten gewährt werden. Die Erfahrung zeigt, dass sich quasi immer jemand aus der Community findet, die/der hilft, die Rohdaten für das jeweilige Projekt passend aufzubereiten. Häufig fällt es auch schwer, eine klare Grenze zu ziehen, wo bereits eine Veredelung stattfindet, und was noch _Roh_daten sind. Ein Verkehrsunternehmen soll die Daten in der granularsten Form anbieten, in der sie intern vorliegen.
Wirkliche Rohdaten haben bisweilen den Nachteil, dass sie schwierig zu interpretieren sind. Wenn beispielsweise für die Verspätungen (Prognosen) mehrere Hochrechnungen gemacht werden, dann sollte nur die wahrscheinlichste publiziert werden. Auch gute Dokumentation des Datenformats, idealerweise mit Beispielen, kann helfen, dass die Daten auch wirklich korrekt interpretiert und verwendet werden können.
Für Sollfahrplandaten hat sich das GTFS-Format als de-facto-Standard etabliert. Da die auf Google Transit bereitgestellten GTFS-Daten nicht immer perfekt exportiert zu sein scheinen, böte sich auch das intern verwendete Austauschformat (vermutlich HAFAS) samt einer Dokumentation an. Die Open-Data-Community würde sich in diesem Fall selbst um eine Konversion kümmern. Dieser Weg wird z.B. in den Niederlanden gegangen.
Auch in der Schweiz werden die Daten von der SBB als HAFAS-Rohdaten-Format publiziert (eine Doku liegt ebenfalls dort). Die Daten werden von einer unabhängigen Stelle regelmässig auf GTFS umgerechnet, wobei auch komplexere Modellierungsfälle wie Flügelungen berücksichtigt werden.
Falls Echtzeitdaten im GTFS-RT-Format bereitgestellt werden, lassen sich diese Daten mit einem GTFS-Feed zu einer Gesamtlage mit Sollfahrplan und nur den Abweichungen über die Ist-Schnittstelle kombinieren. Diese Kombination ist im Vergleich zum klassischen VDV-Ansatz (Hafas, EFA oder neuerdings TRIAS) sehr datensparsam. Beim Ausfall der Echtzeitschnittstelle oder einem Netzausfall ist ein Rückfall auf den Sollfahrplan möglich. Analog funktioniert auch die Kombination von NeTEx und SIRI.
Durch die Delegierte Verordnung (EU) 1926/2017 werden die Datenformate NeTEx und SIRI für die Veröffentlichung gefordert. Natürlich ist es zulässig und ggf. auch sinnvoll, sowohl NeTEx/SIRI als auch GTFS/GTFS-RT bereitzustellen.
Theoretisch besteht die Möglichkeit, mit Linked Data verschiedene Datenquellen semantisch zu verknüpfen. Hierbei wird das Datenformat mit Semantikinformationen angereichert.
Die Bereitstellung offener Daten hat bislang in vielen Bereichen zur Entwicklung von innovativen Lösungen geführt, die vorher von den Dateneignern nicht realisiert werden konnten – entweder, weil sie den speziellen Anwendungsfall nicht erkannt hatten, oder weil ihnen das Know-How für die Erarbeitung fehlte, oder weil die Entwicklung einer Lösung für einen speziellen Anwendungsfall finanziell nicht leistbar war.
Ein EVU kann so indirekt die Ausweitung der Angebotspalette innovativer Mobilitätsanwendungen fördern, die auch seinen eigenen Kund_innen zugute kommen.
Die Bereitstellung kann letztlich für vier Gruppen interessant sein:
Absolut nicht.
Das Ziel ist aus- und nachdrücklich Open Data – das bedeutet gemäß der Open Definition, dass das Erheben von Lizenzgebühren ausdrücklich nicht erlaubt ist.
Wenn Daten nur gegen Geld erhältlich sind, „lohnt“ sich die Entwicklung von Lösungen demzufolge nur, wenn diese Kosten z.B. durch den Verkauf des fertigen Produkts wieder gedeckt werden können. Dies bedeutet eine prohibitive Hürde für Lösungen, die sehr kleine, spezielle Zielgruppen ansprechen, und kein breites Publikum – beispielsweise Menschen mit Mobilitätseinschränkungen, die ohnehin an vielen Stellen im bisherigen Eisenbahnverkehr benachteiligt werden. Während viele Beitragende in der Open-Data-Bewegung willens sind, Personenarbeitsstunden in erheblichem Gegenwert für die Lösung von Problemen zu investieren, dürfte der Wille, für die nötigen Daten auch noch Geld zu bezahlen, keine weite Verbreitung haben. Zudem leben viele (freie) Projekte vom Austausch – beispielsweise, indem interessierte Nutzer_innen eines Programms Fehlerreporte oder sogar Bugfixes einreichen. Solch ein Austausch wäre unter unfreien Lizenzen nicht möglich, da die Beitragenden mangels eines eigenen API-Keys bzw. einer Nutzungslizenz keinen Zugriff auf die Datenquelle hätten.
Zudem sollte bedacht werden, dass es sich bei den bereitgestellten Daten in der Regel um Faktendaten handelt, deren Nachnutzung (sobald sie einmal veröffentlicht sind) nicht eingeschränkt werden kann. So sind beispielsweise bei reinen Fahrplan- oder Lagedaten regelmäßig nicht die notwendigen Hürden für die Schöpfungshöhe nach dem Urheberrecht erfüllt (vgl. Kapitel 2.6 des Abschlussbericht zum FoPS 70.825. Vor dem Hintergrund ist auch die immer noch übliche Praxis, auf dem Urheberrecht basierende Lizenzverträge wie CC BY oder DL-DE BY auf die Datensätze anzuwenden, enorm fragwürdig. (siehe auch)
Die Open-Data-Community könnte idealerweise auf einen verlässlichen Datenbestand zurückgreifen und ggf. sogar die Datenqualität des Anbieters verbessern. Viele interessante Daten sind bereits jetzt durch Interessierte per Crowdsourcing gesammelt worden und auf Plattformen wie Wikipedia, OpenStreetMap oder einschlägigen Foren (drehscheibe-online etc.) in verschiedenen Formaten und verschiedener Qualität verfügbar.
Durch eine offizielle Bereitstellung relevanter Daten würde dieser Datenbestand idealerweise 1.) größer, 2.) regelmäßiger und ggf. zuverlässiger aktualisiert. Gerade für Anwendungen, die über ein Prototypenstadius hinaus wachsen möchten, ist eine regelmäßig aktualisierte und verlässliche Datenquelle wichtig. Eine gute, offizielle Dokumentation, auf die verwiesen werden kann, erschließt die Nachnutzung der Daten zudem einer deutlich größeren Gemeine von Entwickler_innen.
Die Erfahrungen in der Zusammenarbeit mit Daten bereitstellenden Kommunen haben gezeigt, dass durch geeignete Feedbackprozesse oftmals auch die Datenqualität der veröffentlichenden Stelle verbessert werden konnte.
Das obliegt der Open-Data-Community, die eine heterogene Gruppe ist, und deren Verhalten nicht vorhergesagt werden kann ;) Aufgrund des eher speziellen Themas ist nicht damit zu rechnen, dass eine Veröffentlichung von heute auf morgen einen überwältigenden Zustrom an Entwickler_innen mit mannigfaltigen Anwendungen mit sich bringen würde. Die Anwendung von Transitdaten hat sich jedoch als praktisches Beispiel für den Umgang mit offenen Daten in den Open Knowledge Labs, aber auch im Bereich der Hochschullehre etabliert. Es ist auch damit zu rechnen, dass es bereits viele Anbieter_innen bestehender Anwendungen und Apps gibt, die mit dem neuen Datenbestand den Funktionsumfang ihrer Anwendungen erweitern würden. Potenzielle Anwendungsgebiete wurden bereits vorher genannt.
Wie bereits beschrieben werden von den Aktiven in der Open-Data-Community häufig eigene Probleme gelöst, die sich im Alltag ergeben. Im Idealfall fördert die Bereitstellung offizieller Daten auch den Austausch zwischen verschiedenen Gruppen, wie dies bereits schon in anderen Kontexten passiert ist. Beispielsweise hat die Community zur schnellen und präzisen Aktualisierung von Stationsplänen beigetragen, nachdem die Berliner S-Bahn dazu übergegangen war, für ihre Bau- und Umsteigeinformationen die freie Weltkarte OpenStreetMap zu verwenden.
Die Community könnte grundsätzlich nicht mit „unfreien Daten“ arbeiten, d.h. allem mit proprietärer Lizenz, bei dem die Nachnutzung nicht einwandfrei gesichert ist. Auch NDAs, Service Level Agreements und ähnliche Vertragswerke schließen viele potenzielle Beitragende aus. Die Entwicklung von Lösungen in der Community basiert darauf, einen niederschwelligen Einstieg zu bieten, so dass alle* mit dem nötigen Know-How beitragen können. Jede Art rechtlicher Hürden, die nicht mit den einschlägigen freien Lizenzen vereinbar sind, stehen dem im Wege.
Weiter sind Daten problematisch, die in einem Format vorliegen, das nur mit proprietärer Software lesbar ist. Hierzu gehören z.B. Binärformate, oder Formate, die nur mit kommerzieller Software oder nur für bestimmte Betriebssysteme erhältlicher Software lesbar sind. Dies würde viele Freiwillige abhalten, sich mit den Daten zu beschäftigen.
Schwierig sind zudem Formate mit schlechter oder fehlender Dokumentation. Bisweilen werden zwar proprietäre Formate reverse-engineered – das bedeutet jedoch einen langwierigen Prozess, bei dem oft nicht gewährleistet werden kann, dass alle Eventualitäten abgedeckt sind.
Nicht zuletzt sollten Aktualisierungen von Datensätzen möglichst unverzüglich stattfinden.
Die Community bearbeitet ein weites Feld an Problemen; in der Regel geht es darum, den eigenen Alltag oder den seiner Mitmenschen zu vereinfachen, oder politisches Handeln nachvollziehbar zu machen. Eine abschließende Aufzählung dürfte umfangreich werden; als Beispiel sei auf die Projektübersicht der Open Knowledge Labs der OKF verwiesen, das auf dem Brigades-Programm von Code for America aus den USA basiert.
Dieser Aufschrieb entstand kollaborativ durch Beitragende u.a. aus den Mailinglisten open-data-nahverkehr und open-transport. Er steht, soweit möglich, unter einer CC0-Lizenz
To the extent possible under law, the authors have waived all copyright and related or neighboring rights to EVU-Open-Data-FAQ. This work is published from: Deutschland.
Dieser Text darf als lebendes Dokument verstanden werden. Sollten Änderungen erforderlich sein, dürfen gerne Pull Requests eingereicht werden.