Mitfahrvermittlung über die Entwicklung einer offenen Schnittstelle optimieren
Herausforderung und Ziel
Der Mitfahrmarkt in Deutschland ist stark fragmentiert und hierdurch für die Nutzer der vielfältigen Vermittlungsangebote nicht ausreichend transparent. Fahrer und Mitfahrer finden zum Teil nicht oder nur mit großem Zeitaufwand zusammen. Das Projekt MMP will dieses Problem lösen, indem es gemeinsam mit den Mitfahrvermittlungen und weiteren Akteuren eine Meta-Suchmaschine für private Fahrgemeinschaften (Ridesharing mit privaten Pkw ohne Gewinnabsichten) und ein Konzept für das notwendige begleitende Marketing entwickelt.
In der aktuellen Phase 1 des Projektes sollen hierfür die technischen und organisatorischen Grundlagen ermittelt werden. Dies beinhaltet zwecks Untersuchung der Anforderungen im technischen Bereich vor allem die Abstimmung mit den bestehenden Mitfahrvermittlungen sowie die Entwicklung einer Schnittstelle bzw. eines offenen Datenstandards.
Vernetzte Mobilität braucht Datenstandards
Dass Mobilität durch eine bessere Vernetzung verschiedener Verkehrsmittel schneller, komfortabler und umweltfreundlicher werden kann, ist mittlerweile allgemeiner Konsens. Doch an dem „wie“ scheiden sich oft die Geister. Eines der Kernprobleme ist, dass fast jeder Anbieter von Mobilitätslösungen in Deutschland einen anderen Datenstandard nutzt.
Dies ist auch beim Mitfahrmarkt nicht anders. Dabei wäre gerade der Mitfahrmarkt besonders auf eine Vernetzung angewiesen, wie ein früheres Projekt an der RWTH Aachen und die darauffolgenden Entwicklungen des Mitfahrmarkts in den letzten Jahren verdeutlicht haben. Die große Anzahl an Vermittlungsangeboten erhöht den Aufwand für das Zusammenfinden und vermindert mögliche Vermittlungserfolge. Ein Metaportal könnte dieses Problem lösen, doch dies ist nur möglich, wenn die Daten mindestens strukturiert, im besten Fall in einem einheitlichen Datenstandard vorliegen. Vergleichbar ist die Situation mit der menschlichen Kommunikation: Möchte man komplexe Informationen austauschen, so ist es zwingend erforderlich, die Sprache des Anderen zu beherrschen. Ansonsten ist Kommunikation nur mit hohem Aufwand und dem Verlust vieler Details möglich. Genauso verhält es sich in der Mobilität: Eine gut funktionierende Vernetzung gibt es nur mit gemeinsamer Sprache, also einem gemeinsamen Datenstandard.
Open Data
Offene Daten werden insbesondere durch folgende Eigenschaften charakterisiert:
- freie Lizenzen (z. B. Creative Commons)
- nicht personenbezogen
- maschinenlesbar
- offene Formate / Standards
- vollständig und möglichst unverarbeitet
Wichtig ist, dass es sich dabei um einen offenen Datenstandard handelt, der ohne Lizenzgebühren einsehbar und nutzbar ist. Die derzeitige unbefriedigende Situation ist auf geschlossene Standards zurückzuführen – ein Datenaustausch zwischen den Plattformen findet aktuell nahezu nicht statt.
Das Internet selbst sollte dabei Vorbild sein: Nur durch offene Standards ist die Vernetzung möglich geworden. Und auch hier wieder gilt die Analogie zur menschlichen Sprache: Die Idee, für jede Nutzung eines Wortes eine Lizenzgebühr zu verlangen, würde zu Recht als völlig absurd abgetan werden.
Öffnung als Chance
Um Mobilität bestmöglich zu vernetzen, sollten Daten nicht nur in einem austauschbaren Format vorliegen: Zusätzlich sind freie Lizenzen wichtig, damit das volle Potenzial aus den Daten geschöpft werden kann. Unter anderem wäre eine Verbindung zwischen öffentlichem Personennahverkehr (ÖPNV) und Mitfahrportalen wünschenswert, da z. B. in ländlichen Gegenden Mitfahrer oftmals mit der Fahrgemeinschaft zum Bahnhof fahren.
Sind die Daten dagegen wie derzeit geschlossen, so müsste ein Routing-Anbieter mit jedem Mitfahrportal-Betreiber einzeln aushandeln, unter welchen Bedingungen er Zugang zu den Daten erhält. Dies gilt auch für die Verknüpfung mit weiteren Mobilitätsanbietern: Zu jedem müsste ein individuelles Vertragsverhältnis aufgebaut werden. Dies können – wenn überhaupt – nur die ganz großen Anbieter, die Einrichtung und der Betrieb dezentraler Mobilitätsportale kleinerer Anbieter würde verhindert oder zumindest erheblich erschwert werden.
Für die Aufnahme einzelner Mitfahrportale in das geplante Metaportal werden freie Lizenzen nicht zwingend vorausgesetzt. Um jedoch das Potenzial der Vernetzung zwischen den verschiedenen Verkehrsmitteln nutzbar zu machen und viele Vermittlungen zu ermöglichen, empfiehlt sich die Freigabe der Daten unter einer freien Lizenz.
Leichter Einstieg mit dem Ziel digitaler Live-Vernetzung
Um die Freigabe der Daten möglichst einfach zu gestalten, wird ein mehrstufiges Modell vorgeschlagen. Idee ist, Anbietern von Mitfahrvermittlungen die Chance zu geben, ihrer individuellen Entwicklungsgeschwindigkeit entsprechend an dem Projekt teilzunehmen und so ihren Aufwand in realistischen Grenzen zu halten.
Zur Überführung strukturierter Daten aller Art in ein Metaportal, werden sie zunächst durch regelmäßigen Abruf (Polling) angenommen. Sie müssen allerdings konvertiert werden, was zu dem oben beschriebenen Problem führt, da sie nicht immer kompatibel sein werden.
Der darauffolgende Schritt wäre ein regelmäßiger Abruf über den offenen Datenstandard. Hierfür müsste die Mitfahrbörse diesen implementiert haben; sie hätte gleichzeitig die Sicherheit, dass die Daten auf dem Metaportal schneller und zuverlässiger aktualisiert werden können.
Im Endausbau wird eine Abkehr von den klassischen Pull- und Push-Mechanismen angestrebt. Über eine Websocket-Verbindung könnten Updates ressourcenschonend an das Metaportal und – falls vom Betreiber gewünscht – auch darüber hinaus geteilt werden.
Abruf-Strategien
Die geplante Schnittstelle sieht vor, dass eine Kopie aller Streckendaten auf dem Metaportal vorliegt.
Eine ebenfalls denkbare und zum Teil bereits genutzte Alternative wäre eine Live-Abfrage jedes einzelnen Portals bei jeder Such-Anfrage eines Nutzers an das Metaportal. Dies bringt jedoch erhebliche Nachteile mit:
- Anfragen auf dem Metaportal würden erheblich länger dauern, was insbesondere bei spontanen Mitnahmen via Smartphone nicht praktikabel wäre. Ebenfalls würde dieses Vorgehen zu Stoßzeiten erhebliche Serverressourcen bei jedem einzelnen Portal binden und es ggf. überlasten.
- Eine Verknüpfung mit anderen Verkehrsmitteln oder weiteren Mitfahrgelegenheiten wird unmöglich, weil es nicht machbar ist, jede nur mögliche Teilstrecke durch eine Live-Abfrage zu erhalten. Dem Routing auf dem Metaportal würden daher essenzielle Informationen fehlen.
- Private Mitfahrvermittlung ist geographisch viel komplexer als z. B. Flüge, wo ein Live-Abruf durch die limitierte Anzahl an Flughäfen gut umsetzbar ist. Bei der Mitfahrvermittlung liegen dagegen Start und Ende viel kleinräumiger vor, und die Geopositionierung und das Routing laufen auf jedem Portal anders. Daher würde eine Live-Abfrage zu extrem unterschiedlichen Ergebnissen je nach Portal führen, was für den Nutzer Irritation bis hin zur Unbenutzbarkeit zur Folge hätte.
Aus diesen Gründen wird im Projekt MMP zunächst die Strategie eines Komplett-Datenabrufs und eines lokalen Routings auf dem Metaportal verfolgt. Dies schließt selbstverständlich nicht aus, dass auch eine Live-Abfrage spezifiziert werden könnte.
Datenschutz
Bei all den besprochenen Daten geht es um nicht personenbezogene Daten, welche gefahrenlos geteilt werden können. Konkret bedeutet das, dass alle personenbezogenen Daten wie E-Mail-Kontakt, postalische Adresse oder Handynummer auf dem Server des Anbieters verbleiben. Lediglich Informationen über die Fahrt selbst dürfen freigegeben und weiterverwendet werden. Die Kontaktaufnahme eines Interessenten muss daher auf dem Server des ursprünglichen Anbieters geschehen.
Denn eines ist klar: Datenschutz hat allerhöchste Priorität. Bei dem Protokoll soll es strukturell unmöglich sein, aus Versehen personenbezogene Daten zu veröffentlichen. Daher muss klar zwischen öffentlichen und privaten Daten unterschieden werden: Erstere möchte man nutzen, zweitere schützen.
Anforderungen an ein Austauschformat
Folgende Anforderungen an ein Austauschformat werden seitens MMP vorgeschlagen:
- Geringer Implementierungsaufwand: Das Austauschformat sollte mit einfachen Mitteln und bestehenden Libraries umsetzbar sein.
- Dezentralität: Das Austauschformat muss eine Vielzahl an Quellen unterstützen. Insbesondere muss berücksichtigt werden, dass die Quellen auch untereinander Datenaustausch betreiben und Duplikate verhindert werden können.
- Aktualität: Das Datenformat sollte eine möglichst einfache Aktualisierung von Datenbeständen unterstützen, so dass eine Aktualität von Plattformen wie dem Meta-Mitfahrportal mit hoher Zuverlässigkeit gegeben ist.
- Unterschiedliche Protokolle: Das Format muss hinreichend flexibel sein, um in verschiedenen Protokollen eingesetzt zu werden. Dies betrifft insbesondere die Unterstützung vom einfachen Polling bis hin zu Live-Websocket-Updates, welche zuvor beschrieben wurden.
- Erweiterbarkeit: Ein jetzt definiertes Austauschformat kann nicht alle zukünftig benötigten Felder erfassen, so dass das Format leicht um eigene Attribute erweiterbar sein muss.
Bestehende Datenstandards
Es gibt bereits eine Reihe an Datenstandards, die sich im Umfeld des Ridesharing-Marktes bewegen. Grob lassen sich diese in zwei Kategorien einsortieren: Spezielle Ride-Sharing-Schnittstellen, welche die spezifischen Bedürfnisse des Ridesharings berücksichtigen, und allgemeine Mobilitäts-DatenStandards, die durch eine höhere Abstraktion Kompatibilität zu anderen Mobilitätsformen herstellen. Eine Auswahl:
DYCAPO ist das Ergebnis einer Bachelor-Arbeit, die ein abstraktes Datenmodell auf JSON-Basis definiert und einen vollwertigen Server mit vielen Aspekten des Meta-Mitfahrportals entwickelt hat. Die Dokumentation und der Code sind öffentlich auf der Software-Entwicklungsplattform GITHUB einsehbar.
Das oben erwähnte Forschungsprojekt hat ein sehr umfangreiches XML-Datenmodell spezifi- TAT Technik Arbeit Transfer gGmbH – 4 – MMPkompakt Heft 2 ziert, das viele wichtige Aspekte anspricht, aber aufgrund seines Alters von ca. 10 Jahren mittlerweile einer Aktualisierung bedarf.
Verschiedene hier aus Neutralitätsgründen nicht aufgeführte plattform-spezifische Schnittstellen bilden ebenfalls Mitfahrgelegenheiten ab.
Die Datenstandards GTFS und GTFS-RT bieten eine gute und realistische Möglichkeit, Ridesharing-Daten mit weiteren Mobilitätsdaten wie z. B. dem ÖPNV zu verknüpfen. Außerdem ist GTFS ein Standard-Import-Format für Open-SourceRouting-Engines.
Notwendige Datenobjekte
Abschließend sind die Datenobjekte skizziert, die für eine Abbildung von Fahrgemeinschaften notwendig sind. Auf die Auflistung aller Attribute wird hier aus Platzgründen verzichtet.
Das Objekt „Trip“ stellt das Basisobjekt für jede Fahrt dar. Es enthält alle Basisangaben, die für eine Fahrt notwendig sind.
Das Objekt „RecurrentTrip“ beschreibt wiederkehrende Fahrten mit einem flexiblen System aus Daten und Zeiten inklusive Ausnahmen.
Das Objekt „Stop“ stellt einen Stopp auf einem Trip dar. Es ist Teil eines „Trips“ und hat eine „Location“.
Das Objekt „Location“ stellt einen Ort dar, an welchem Stopps stattfinden. Neben einem geographischen Punkt werden auch weitere geographische Angaben wie eine für den Nutzer lesbare Adresse ermöglicht.
Das Objekt „Preferences“ stellt die Präferenzen und mögliche ergänzende Angaben eines Trips dar. Hierzu zählen Fahrradmitnahme, Raucher, Frau oder Mann als Mitfahrer, Mitnahme von Tieren und weitere Rahmenparameter.
Das Objekt „Person“ stellt eine vollständig anonymisierte Personen-Instanz dar. Das Objekt „Participation“ beschreibt die Teilnahme einer Person an einem Trip. Hierbei wird zusätzlich auf „Stop“ verlinkt, um den Ein- und Ausstiegspunkt zu definieren.
Das Objekt „Car“ beschreibt detailliert das Fahrzeug.
Beteiligungsmöglichkeiten
Um eine größtmögliche Transparenz zu erreichen, wird die Datenschnittstelle für das Meta-Mitfahrportal auf GITHUB entwickelt unter der Adresse github.com/ridesharing-api/documentation.
Der aktuelle Stand und die laufenden Änderungen können so jederzeit online nachvollzogen werden. Interessierte sind außerdem eingeladen, sich aktiv zu beteiligen, beispielsweise durch die Ergänzung der weiter oben vorgestellten Anforderungen an das angestrebte Austauschformat.
Datenschnittstellen existierender Portale werden in das Entwicklungsprojekt auf Github explizit nicht hochgeladen. Es wird jedoch angestrebt, Zugang zu den Schnittstellen interessierter Portale zu erhalten, um die Bedürfnisse der einzelnen Portalbetreiber möglichst genau zu verstehen und dies in die weitere Entwicklung der MMP-Datenschnittstelle mit einfließen zu lassen. Auf diese Weise soll sichergestellt werden, dass die Schnittstelle für das MetaMitfahrportal am Ende für alle Beteiligten effizient und arbeitssparend gestaltet ist
Der Text steht unter der Lizenz Creative Commons BY. Autor ist Ernesto Ruge. Als Teil der Schriftenreihe MMPkompakt kann er auf der Seite des TAT in Form einer PDF heruntergeladen werden.
