MDS is the trend when you talk about data feed standards in shared mobility. But the historical GBFS feed, launched in 2015 by the NABSA, is another important part of the services data management. I took part in the Shared Mobility Data Workshop organised by MobilityData in Paris on December 2019, which goal was to contribute to the v2.0 of the data feed standard, that has been released on March 2020, and I wanted to highlight its results.

A bit of history

The open data standard for bike-share was launched in 2015 by the North-American Bike-share Association (NABSA) to provide “real-time data feeds in a uniform format publicly available online, with an emphasis on findability”.

GBFS has been designed to provide the status of a system at this moment and is therefore not a tool to get and analyse historical data. It is also a “read-only” data feed, meaning that any data being written back into individual bike-share systems are excluded from this spec.

These are the differences with MDS, that is a communication tool between operators and authorities made that allows analysing the data history.

Since 2015, GBFS has been used by most of the major operators and on the main bike-share services around the globe: nextbike, Motivate (now Lyft), Social Bicycles (then Jump, now Lime), Tembici, B-Cycle… and Vélib’, Bicing, Bixi, Citi Bike… are all using this standard. When the e-scooter sharing trend arrived back in 2018, some operator also adopted it as a standard, such as Spin, Lime or Jump.

What’s new in v2.0?

As shared mobility services evolve faster and faster, users and developers needs are changing at a similar pace. The GBFS standard had to evolve to match the current needs. A meaningful example is the development of mobility apps, aggregating data from public transport, car sharing, or shared micromobility services. You can imagine the importance of having your bike-share service available in Google Maps or Transit App! GBFS v2.0 now has new fields to integrated deep links, that allow end-user to access these services directly from the aggregator.

The popularisation of “free-floating” services raised privacy issues. The combination of a vehicle ID and accurate trip origin and destination makes it easier to reconstruct individual trips from raw data. GBFS v2.0 now requires the rotation of the vehicle ID after each ride, making it impossible to track a specific vehicle from data.

Some clarifications have also been introduced in the new standard, that is still under development to match with new shared micromobility needs.

A cooperative development

GBFS development is led by MobilityData. The NABSA’s subcontractor gathered transport authorities, operators, software/app developers, and other shared mobility experts during workshops to get the richest feedback and integrate specific constraints of each stakeholder. A real collaborative development.

Following the industry’s evolution, the 2019 Paris workshop was rich with discussions around vehicle types, and geofencing zones. The current development of multimodal offers and implementation of local regulation based on geofenced zones required the integration of these data. GBFS is now an ever-evolving standard that will take into account the industry trends and requirements to stay up-to-date and provoke adoption among operators and solution providers.

You’ll find the full details of the GBFS v2.0 release in the Medium article by MobilityData.