Gaetano Rizzo

Mit Fermata möchten wir für Ordnung auf der Straßenkante sorgen und über die relevanten Datenaustauschformate wie die neue „Mobility Data Specification“ aufklären: Eine IT-Schnittstelle zum Austausch von Daten und Regeln zwischen Behörden und Mobilitätsanbietern.

Als wir vom Team Fermata uns mit dem Plattform-Gedanken rund um virtuelle Haltestellen und Curbside Management beschäftigten, wurde schnell klar, dass unsere Lösung eine Art Datendrehkreuz werden würde.

Die Fermata-Plattform bringt die Anbieter von Car-Sharing, Bike-Sharing, Ride-Pooling, Micromobility mit Städten bzw. deren ÖPNV (Öffentlicher Personennahverkehr) als Partner zusammen und sorgt so für eine effiziente Nutzung jeder Straßenkante. Schließlich schafft die Plattform eine Grundlage für Partnerschaft, Zusammenarbeit und Innovation zwischen der Stadt, den Mobilitätsanbietern und den Bürgern.

Andererseits möchten wir kein Vermittlungsbüro oder Maklerservice werden, sondern ein datenbasiertes Geschäftsmodell aufbauen. Demnach benötigen wir Daten-Schnittstellen, sogenannte APIs (application programming interfaces = Anwendungsprogrammier-schnittstellen), und die gibt es wie Sand am Meer. Welche nehmen wir? Entweder wir nehmen alle Daten in dem Format, wie sie uns bereitgestellt werden, oder definieren unseren eigenen Standard.

Im ersten Fall wäre die Eintrittshürde für unsere Plattformnutzer, wie die Kommunen und Transportunternehmen, am niedrigsten. Sie müssten ihre Daten nicht zuerst umwandeln und formatieren, sondern könnten sie uns, so wie sie sind, einfach über den Zaun werfen. Die ordentliche Datenaufbereitung und Qualitätssicherung beim Austausch ist hier eine Herausforderung. Haben die gelieferten Daten die ausreichende Qualität und Quantität, damit unser Drehkreuz sich in angemessener Geschwindigkeit und ohne Störung drehen kann?

Im zweiten Fall stünden wir vor der Herausforderung, unseren Datenstandard erstmal definieren zu müssen und dann auch zu etablieren. Jeder Partner müsste die Daten, die er an uns schickt, zunächst kompatibel machen. Auch die von uns erhaltenen Daten müsste er für seine Bedürfnisse wieder umwandeln. Im Einzelfall könnte dies Software-seitig mit geringem Programmieraufwand gelöst werden, wäre jedoch eine nicht zu unterschätzende Hürde bei den ersten Schritten des Markteintritts.

Außerdem ist immer noch die Frage offen, welche Daten in welcher Qualität und Quantität benötigen wir überhaupt? Gibt es zwischen diesen beiden Extremen einen Mittelweg? Gibt es bestehende Datenformate oder API-Standards, auf die wir aufsetzen könnten? Warum das Rad neu erfinden?

In der EU und in Deutschland, dem Erfinder des Eich- und Messwesens, gibt es für so ziemlich alles irgendeine Regel, Norm oder sonstige Form der Vereinheitlichung – sprich einen Standard. Kaum, dass wir uns schlau machten, schwirrten schnell von verschiedenen Seiten Begriffe für APIs und IT-Schnittstellen umher:

JSON, Rest, MQTT und XML meinten die Einen, die Anderen beharrten auf CSV, GTFS, GBFS sowie MDS. Dritte wiesen dringend auf die Standards VDV452 sowie Datex2 hin.

Kurz: Auf der Straße herrscht das Chaos, bei den Datenformaten aber auch – zumindest für den Laien. Wir klären auf und lichten den Datendschungel.

CSV und XML sind Formate für Textdateien. CSV steht für die englische Formulierung „Comma-separated values“, also durch Kommata getrennte Werte bzw. Inhalte, und XML für das englische “Extensible Markup Language”. Während CSV oft in Tabellenkalkulationen wie Excel verwendet wird, weil die Daten wie in Spalten formatiert sind, kann die Datenstruktur einer XML-Datei wesentlich komplexer und verschachtelter sein.

https://tools.ietf.org/html/rfc4180

https://www.w3.org/XML/

„JavaScript Object Notation“, kurz JSON, ist ein kompaktes Datenformat in einer einfach lesbaren Textform zum Zweck des Datenaustauschs zwischen Anwendungen. In der Regel ist jedes JSON-Objekt ein gültiges JavaScript, andererseits kann JSON auch von anderen Programmiersprachen verwendet werden. Ergänzt um geografische Daten wird stattdessen GeoJSON verwendet.

https://www.json.org/json-de.html

https://geojson.org/

„Representational State Transfer“, abgekürzt REST, seltener auch ReST und in manchen Kontexten RESTful bezeichnet, ist ein Programmierparadigma also ein fundamentaler Programmierstil für verteilte Systeme und daher sehr populär im weltweiten Verbund von Rechnernetzwerken, dem Internet. Ähnliche Alternativen sind SOAP, WSDL und RPC. Es wurde von Roy Thomas Fielding 1994 entwickelt und 2000 im Rahmen seiner Dissertation veröffentlicht.

https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm

MQTT (Message Queuing Telemetry Transport) ist ein offenes Nachrichtenprotokoll für Machine-to-Machine-Kommunikation (M2M), das in Sensoren, Mobiltelefonen, eingebetteten Systemen in Fahrzeugen verwendet wird und daher im Bereich IoT (Internet of Things) große Verbreitung findet. Über die internationale, nicht-gewinnorientierte @oas Organization for the Advancement of Structured Information Standards (OASIS) wird es als Protokoll des Internet der Dinge standardisiert.

https://www.oasis-open.org/committees/mqtt

Der VDV ist der Branchenverband des ÖPNV in Deutschland und hat für die Datenübertragung verschiedene Schnittstellen definiert, darunter VDV 451 für die Datenübertragung zwischen ÖPNV-Anwendungen und VDV 452 für Liniennetz und Fahrplan.

https://www.vdv.de/oepnv-datenmodell.aspx

DATEX II ist die in Europa verwendete elektronische Sprache für den Austausch von Verkehrsinformationen und Verkehrsdaten und wird vom technischen Ausschuss Nummer 278 des Europäischen Komitees für Normung, kurz CEN / TC 278, das für Normen im Bereich der intelligenten Transportsysteme (ITS) in Europa verantwortlich ist, entwickelt und veröffentlicht.

https://datex2.eu/

„General Transit Feed Specification“ (GTFS) wurde ursprünglich von Google Maps-Mitarbeitern entwickelt und hieß daher am Anfang „Google Transit Feed Specification“. Anders als die oben genannten deutschen und europäischen Standards existierte zu jenem Zeitpunkt in den Vereinigten Staaten kein einheitlicher Industriestandard zum Austausch von Fahrplänen des öffentlichen Personenverkehrs und dazugehöriger geografischer Informationen, wie z. B. die Standorte von Haltestellen. Tatsächlich ist GTFS gar kein Dateiformat, sondern eine Sammlung von mindestens sechs und bis zu 15 CSV-Dateien. Auch wenn GTFS weiterhin von Google gepflegt wird, wurde das „Google“ im Namen durch „General“ ersetzt, um für neue Nutzer mit einer Aversion gegenüber Google eventuelle Hürden abzubauen.

https://developers.google.com/transit/gtfs/

„General Bikeshare Feed Specification“ (GBFS) wurde 2015 von der North American Bikeshare Association (NABSA) in Anlehnung an GTFS ins Leben gerufen, um die shared micro mobility besser verwalten zu können. Diese Spezifikation ist eine Sammlung von mindestens einer und bis zu elf JSON-Dateien.

https://github.com/NABSA/gbfs

Von den letzten beiden Genannten ist die „Mobility Data Specification“ (MDS) inspiriert und ursprünglich vom Los Angeles Department of Transportation (LADOT) entwickelt worden. Mittlerweile wurde sie an die neu gegründete Open-Source-Softwarestiftung Open Mobility Foundation (OMF) übergeben, die zusammen mit der oben genannten OASIS diese Spezifikation zum globalen Standard erheben möchte, die über das Management von Micro Mobility Services hinausgehen soll.

https://github.com/openmobilityfoundation/mobility-data-specification

Als Open Source angelegt, wird MDS stetig weiterentwickelt und untergliedert sich aktuell in drei unterschiedliche Komponenten:

1. Provider: basierend auf JSON; wird von Mobilitätsanbietern implementiert sowie von Aufsichtsbehörden verwendet und muss einen GBFS-Feed veröffentlichen können.

2. Agency: wird von Aufsichtsbehörden implementiert, von Mobilitätsanbietern genutzt und enthält eine Sammlung von RESTful-APIs.

3. Policy: im Oktober 2019 erstmals veröffentlicht, wird sie von Regulierungsbehörden implementiert und von Mobilitätsanbietern genutzt. Hierüber werden die kommunalen Regeln festgelegt, z.B. maximal zugelassene Fahrzeuge oder Parkverbotszonen. Der Datenaustausch erfolgt mit JSON- bzw. für Standortdaten mit GeoJSON-Dateien oder einer REST-API.

Vorteile von MDS

Es ermöglicht Mobilitätsanbietern, Echtzeitdaten über ihre Fahrzeuge an die Stadt zu senden.

Städte können auch historische Daten direkt von den Mobilitätsanbietern abrufen. Dank der Provider-API erhält die Stadt Informationen über Start, Ende und Route jeder Fahrzeugfahrt. Die Stadt sammelt auch Informationen darüber, ob das Fahrzeug außer Betrieb oder die Batterie leer ist oder ob es gerade neu ausbalanciert wird, d.h. in einen anderen Teil der Stadt verlegt wird. Dabei wird natürlich der Datenschutz und die Datensicherheit entsprechend berücksichtigt.

Wichtig ist vor allem die Perspektive, dass die Schnittstelle auch eine Rückmeldung von der Stadt zum Mobilitätsanbieter ermöglicht, um sie über Ereignisse wie Straßensperrungen durch Demonstrationen oder Bauarbeiten zeitnah zu informieren, oder wenn ihre Fahrzeuge außerhalb eines geeigneten Parkplatzes abgestellt wurden. Schließlich können wir uns auch vorstellen, dass Städte irgendwann in der Lage sein werden, das Verhalten von Mobilitätsunternehmen aktiv zu beeinflussen: zum Beispiel durch die Anpassung der Parkgebühren von Fahrzeugen an Stau- oder Schadstoffspitzen oder wenn Fahrten aus einkommensschwachen Gebieten stammen.

Zusätzlich zum Status der verfügbaren Fahrzeuge legt MDS auch fest, wie Informationen über Fahrzeuge ausgetauscht werden sollen, die aufgrund von Umverteilung, Wartung oder schwacher Batterie durch Statusänderungen des Fahrzeugereignisses nicht verfügbar sind.

In den USA hat sich MDS schon zum Standard entwickelt und auch in den ersten Europäischen (z.B. Brüssel, Lissabon, Paris, Zürich) und Asiatischen Städten (z.B. Singapur), die ein Curbside-Management aufbauen, findet diese Spezifikation Anwendung.

Fazit

Das Datenaustauschformat der Stunde scheint MDS zu sein. Über den Open-Source-Gedanken ist eine weltweite Community daran beteiligt, diese Spezifikation in kurzen Entwicklungszeiträumen stetig weiterzuentwickeln und auch produktiv einzusetzen. Fast alle Mobilitätsanbieter können schon jetzt Daten in diesem Format liefern.

Das Fermata-Team neigt dazu, sich auf MDS für die Fermata-Plattform zu fokussieren. Wozu neigt jedoch die Leserin bzw. der Leser dieses Artikels?

Gaetano Rizzo

Frankfurt, Hesse, Germany
2K followers 500+ connections

About

Experience

2BeCommUnity

-

-

Projects

Ausstellung "Film und Games. Ein Wechselspiel"

Apr 2015 - Feb 2016

Charity Gaming Marathon

Apr 2013 - May 2014

View Gaetano’s full profile

Other similar profiles

Jonathan Ukena

René Leuthold

Alexandra Stenzel

Max Tarantik

Laura Kaufmann

Thomas Nolte

Sebastian Cremer

Julia Backhaus

Dr. Gunter Gehrke

Michael Bamberg

Thyra von Gerlach

Tita Marie Lindauer

Damian Georgy

Christian Wust

Florian Stieler

Lisa Demirörs

Reinhold Peters

Hartmut Keding

Timo Mildenberger

Arthur Dell

Explore collaborative articles

Others named Gaetano Rizzo

Gaetano Rizzo

Gaetano Rizzo

Gaetano Rizzo

Gaetano Rizzo

Gaetano Rizzo

Frankfurt, Hesse, Germany 2K followers 500+ connections

About

Experience

2BeCommUnity

-

-

Projects

Ausstellung "Film und Games. Ein Wechselspiel"

Apr 2015 - Feb 2016

Charity Gaming Marathon

Apr 2013 - May 2014

View Gaetano’s full profile

Other similar profiles

Jonathan Ukena

René Leuthold

Alexandra Stenzel

Max Tarantik

Laura Kaufmann

Thomas Nolte

Sebastian Cremer

Julia Backhaus

Dr. Gunter Gehrke

Michael Bamberg

Thyra von Gerlach

Tita Marie Lindauer

Damian Georgy

Christian Wust

Florian Stieler

Lisa Demirörs

Reinhold Peters

Hartmut Keding

Timo Mildenberger

Arthur Dell

Explore collaborative articles

Others named Gaetano Rizzo

Gaetano Rizzo

Gaetano Rizzo

Gaetano Rizzo

Gaetano Rizzo

Frankfurt, Hesse, Germany
2K followers 500+ connections