GBFS and Shared Mobility Data Policy

Helping cities support seamless and sustainable mobility options through GBFS.

This guide is also available in Portuguese, Spanish, and French.

Overview

Securing access to mobility data is an important part of a shared mobility program. Public access to mobility data builds trust in mobility programs and increases shared mobility adoption. Writing effective policy can ensure that mobility data is both accurate and accessible.

This report is intended primarily for individuals responsible for shared mobility procurement and policies at cities or other local authorities. The report provides a foundational understanding of how GBFS supports seamless, sustainable mobility options and how to leverage open data’s potential when writing policy that can influence shared mobility adoption and practice.

Photo by Martti Tulenheimo.

How GBFS can support the effort for cities to offer sustainable transportation

GBFS makes it easy for travelers to find and use shared mobility.

Since it was first established in 2015, GBFS has become the de facto standard for shared mobility data. The specification is now in use in hundreds of cities across at least 45 countries worldwide.

Policymakers should require public GBFS APIs when permitting or licensing shared mobility operations.

GBFS provides a common language for shared mobility operators to share information about options available to travelers. GBFS includes information about vehicles (bicycles, scooters, moped, and cars), stations, and more:

• Vehicle, station, and dock locations and availability
• Vehicle characteristics – type of power, distance that can be traveled on remaining charge
• Geofenced areas for rules related to speed, parking, and prohibited zones

These data are used by trip planning and Mobility as a Service (MaaS) applications, to provide travelers with the information they need to discover and choose shared mobility. Public GBFS APIs enable the integration of shared mobility services with public transportation, allowing users to make first-mile, last-mile connections and multi-modal journeys, making more potential car-free journeys possible.

In addition, GBFS provides local authorities and agencies with a standardized way to ingest, analyze, and compare data generated by shared mobility systems. Advancements in shared mobility platforms have resulted in the generation of vast quantities of mobility data. These data have become an essential part of policy making and regulation of shared mobility operators. Data from shared mobility operators help us to understand how these services impact public safety, and whether or not they advance equity, innovation, sustainability, and other policy goals. Public access to shared mobility data increases transparency and makes operators accountable for the services they operate in the public right-of-way.

GBFS has been designed specifically for use as a source for public data. To make GBFS APIs truly public, they must be made freely available on the open internet and require no API key, token, or other means of access or authentication. Feeds containing sensitive data that require authentication are not a substitute for public APIs.

GBFS enables the exchange of information in a way that ensures all parties agree on what the information represents. You can think of it like a dictionary, where each term has a definition and a set of rules for how it can be used. GBFS is a real-time data specification that describes the current status of a mobility system. GBFS does not support, and is not intended for, historical data such as trip or maintenance records.

GBFS reduces administrative burdens on cities, reduces compliance burdens on operators.

Unlike bespoke data sharing requirements of the past, the standardization of shared mobility data benefits both cities and operators alike. Standardization of mobility data through GBFS has resulted in a growing marketplace of data management software and services, providing a better quality and a greater variety of available solutions. These products and services are used to assist mobility regulation bodies and public authorities in working with GBFS data to effectively manage and regulate mobility services.

Policies requiring standardized open data can prevent the creation of walled gardens, a procurement scenario where cities are locked-in to a specific vendor’s proprietary tools or services. Open, standardized data is portable, allowing cities to change operators if a service fails to meet expectations.

For operators, standardization means an end to a patch-work of regulation that requires different data in different formats for each city in which they operate. Standardization provides assurance to operators that data requests can be clearly defined and are fully implementable. GBFS also carries the potential to bring more users to an operator’s platform by integrating with 3rd party apps. As a consensus-based, open source standard, operators have an equal voice along with cities in the ongoing development of the GBFS specification. Comprehensive documentation and resources are available to cities and operators alike to aid in implementation.

Photo by jean-louis Zimmermann.

Recommendations

Include GBFS as part of a tender.

Your tender should require a publicly accessible GBFS API as a requirement and should set expectations for the data needed to meet your policy goals.

Sample language for tenders

Data sharing requirements:

• A publicly accessible API that conforms to the General Bikeshare Feed Specification (GBFS) current version available at https://github.com/MobilityData/gbfs.
• The GBFS API must be available to the public on the open internet without requiring authentication.

Determine what data to require in a comprehensive policy.

As the shared mobility industry evolves, GBFS evolves to include new features, capabilities, and services. This is why you will read ‘or its equivalent’ in the sample policy language and detailed GBFS information that follows. Simply requiring a shared mobility operator to provide a public GBFS feed will not guarantee the data will fulfill regulatory or other needs.

When developing data policies, it is a good idea to gather input from subject matter experts who will be involved in the program implementation. These may include staff from your technology, licensing, or regulation departments or third parties involved in data analysis.

GBFS is designed to accommodate the needs of a wide variety of mobility platforms and use cases, from traditional docked bikeshare to free floating bikes, scooters, and other vehicles. The specification consists of 12 files or endpoints that contain different types of mobility data. Some of these files and their associated fields are required in order to be compliant with the specification, while others are optional. Which of these files are required by the specification depends on the specific type of mobility system being represented. Optional files and fields provide additional data for specific purposes and use cases. Municipalities may need to require some of these optional files or fields in their regulations to provide additional information in support of travelers, municipal goals, or other needs.

Photo by Spin.

Overview of GBFS Files

File Name	Where Required
gbfs.json	Required – This file is an index of URLs for all other files published as part of a GBFS API. To make data available to the public, a link to this file should be published on the city or agency website or open data portal.
manifest.json	Conditionally Required – This file is an index of gbfs.json URLs for each GBFS data set produced by a publisher.
gbfs_versions.json	Optional – This file lists all files published by the operator according to their versions. Maintaining feeds in past versions as new versions of GBFS become available may prevent breaking of downstream applications.
system_information.json	Required – This file contains basic information about the shared mobility system, however most of the fields are optional. Best practices are to publish the optional fields "phone_number" and "email". Additional optional fields may be useful depending on your use case.
vehicle_types.json	Conditionally Required – This file is required of systems that include information about vehicle types in the "vehicle_status.json" file or its equivalent. This file should be published by systems offering multiple vehicle types for rental, for example pedal bikes and ebikes. If this file is not published, all vehicles in the feed are assumed to be non-motorized bicycles.
station_information.json	Conditionally Required – This file is required of systems utilizing docks. Any station defined in this file must have a corresponding entry in the "station_status.json" file. It contains a list of all stations, their docking or parking capacities, and locations. It supports the configuration of virtual stations that may be used to designate approved parking areas such as racks or geofenced areas for free floating vehicles. This information may be used to support parking restrictions for dockless vehicles through the use of designated parking areas.
station_status.json	Conditionally Required – This file is required of systems utilizing docks and optionally may be used in dockless systems to monitor virtual stations. Any station defined in this file must have a corresponding entry in the "station_information.json" file.This is a real-time file that shows the current status of a station or virtual station, its vehicles, and its docks. It includes aggregated numbers of available vehicles and docks which may optionally be aggregated by vehicle type. This data may be used to determine equitable distribution of services. The optional field "num_vehicles_disabled" or its equivalent may be useful in determining the total number of deployed vehicles or the percentage of the vehicle fleet that is able to be rented.
vehicle_status.json	Conditionally Required – This file (or its equivalent) is required for free floating (dockless) or hybrid (docked/dockless) vehicles. It is optional for station based (docked) vehicles. This is a real-time file that shows the current location, availability status, and other attributes of individual vehicles in a fleet. May optionally be used in station based (docked) systems to publish information on vehicle types, charge or fuel levels, and other vehicle attributes. This data may be used to determine the number of vehicles deployed, their availability for rental, and their distribution within the service area.
system_regions.json	Optional – This file is used to define regions within a system. It may be used to support reporting in systems that encompass multiple jurisdictions.
system_pricing_plans.json	Optional – This file describes pricing plans for a system. It is useful to third party trip planning applications but may not be comprehensive enough to model all available pricing for the system.
system_alerts.json	Optional – This file is intended to alert users about changes to the system that do not fall within normal system operations. For example, system closures due to extreme weather would be listed here. Cities should require this file for use as a means of communicating emergency or other information to users.
geofencing_zones.json	Optional – This file describes geofenced zones and their associated rules or attributes. Geofenced zones may be used to communicate information regarding parking, speed limits, no ride zones, or other rules or restrictions. They may be used to define geographies related to equity, vehicle caps, or other use cases. Cities should require this file if their policies rely on geofence information. Care should be taken when developing geospatial policies that rely on location data. Location data from GPS, cellular, and Wi-Fi signals are subject to interference resulting in accuracy levels in the tens of meters or greater.

Data policy recommendations

Data policies should include clear, enforceable language outlining exactly what data are required and what version of the specification must be published. At minimum, a shared mobility data policy should:

• Ensure ongoing access to data for both the regulating body and the public without undue restrictions on its use.
• Clearly define the format and version of the required data.
• Ensure access to specific data needed to effectively permit, regulate, and manage shared mobility providers.
• Protect the privacy of individuals using the mobility platform.

Sample policy language

[COMPANY] shall provide a publicly accessible API that conforms to the General Bikeshare Feed Specification (GBFS) current version available at https://github.com/MobilityData/gbfs.

[COMPANY] must make the API available to the public on the open internet without requiring authentication.

[COMPANY] shall inform [PERMITTING AGENCY] of the URL for the gbfs.json endpoint prior to deploying vehicles. [COMPANY] must notify [PERMITTING AGENCY] at least 30 days prior to changing the URL of the gbfs.json endpoint.

Data contained in the API shall be offered to the public and [PERMITTING AGENCY] under a non-revocable license that allows the API data to be used, modified, and shared without restriction beyond attribution.

Upon release of a new version of GBFS, [COMPANY] must update API to the new version within [XX¹] days unless prior arrangement has been made with [PERMITTING AGENCY].

GBFS API must contain the following endpoints and all fields required under the GBFS specification:

• gbfs.json
• system_information.json
• [ list of additional endpoints e.g. station_information.json, station_status.json, vehicle_status.json or its equivalent, etc.]

In addition to the fields required under the specification the following files must also contain these optional fields:

• file.json: field name
• file.json: field name

(1.) 90 days recommended

For an example of how a regulator may tailor this language to their particular needs, see SFMTA’s scooter permit language (beginning on page 41).

Additional considerations

The value of open mobility data can only be fully realized when that data is easily accessible to the public and traveler privacy is protected; GBFS is designed to support both. Cities and agencies should publish the locations of gbfs.json files on their websites or open data portals and on the openly available dataset catalog connected to GBFS.

Extreme care should be taken when requiring data from operators that is outside the scope of the specification. Data regarding vehicles that are part of an active rental should never appear in GBFS feeds. The over-collection of data — collecting data without a defined purpose — is strongly discouraged. Combining shared mobility data with other publicly available datasets could have serious privacy implications.

For European countries

Requesting open data from shared mobility operators will become even more crucial in the upcoming years as the European Commission enforces the obligation for each Member State to set a National Access Point (NAP) acting as a portal to all open data in regards to mobility services and all consumer-facing information. NAPs are designed to support a thriving European ecosystem built on interoperability between mobility modes and regions, reinforcing the ability of any consumer to travel seamlessly within the European Union. GBFS is a common and accepted format that allows countries to comply with the European regulations on several levels:

• It complies with the will of creating a common open market, which will prevent monopolistic positions;
• It enables transparency in regards to data and supports the European efforts to open more data for consumers to participate in the life of institutions;
• It protects users’ privacy by ensuring only public-information are published, in line with the spirits of the General Data Protection Regulation (GDPR);
• It supports a greener, more sustainable mobility in which users are given options other than relying on solo-driving;
• It is fully compatible with European norms and standards.

In opening the data, some NAPs such as the one managed by Entur in Norway or France’s data.gouv.fr, have set up a team to support mobility operators to open their data. Their guidance on how to leverage GBFS can be sought after, if needed.

GBFS has been developed and tested under a consensus model to ensure that data defined in the specification will not negatively impact user privacy. Extreme care should be taken when requiring data from operators that is outside the scope of the GBFS has been developed and tested under a consensus model to ensure that data defined in the specification will not negatively impact user privacy. Current versions of GBFS are compliant with GDPR, in that they do not contain any personal or personally identifiable data. The key point to remember is that with GBFS there is no trivial way to reconstruct a single user’s journey or habits thanks to the mandatory rotation of vehicle identification numbers. One will also want to be careful with compliance to the GDPR spirit which states that data collection must be adequate and proportionate to operations needs and cannot contain any identifying information without clear consent from individuals.

To support better interoperability within the European common market, the European standardization body CEN has developed Transmodel (the European Norm “Public Transport Reference Data Model” (EN 12896)) – a data standard that facilitates interoperability between the information processing systems of transport operators and agencies by using matching definitions, structures, and semantics for the data elements used by their various systems. Based on Transmodel, further standards have been defined: NeTEx (CEN/TS 16614-1/2/3/5) for the exchange of public transport schedule information, and SIRI (EN 15531-1/2/3/4/5) for real-time information. Both are currently being adapted for “new modes,” including shared mobility solutions.

GBFS is the only open data standard, used internationally, to be recognized by CEN as compatible and convertible to NeTEx/SIRI based on a canonical mapping soon to be approved by CEN. This convertibility reduces the burden of data production and consumption for all stakeholders of the shared mobility industry.

Useful links

• GBFS Repo on GitHub
• GBFS Public Slack Channel
• NeTEx
• SIRI

MobilityData Shared Mobility team email: sharedmobility@mobilitydata.org

Acknowledgements

Heidi Guenin, Mitch Vars, Josée Sabourin, Tu-Tho Thai and Newton Davis.

Reviewers

Diego Canales - Global Partnerships Manager, Populus AI

Josh Johnson - Public Policy Manager, Spin

Andrew Salzberg - Head of Policy, Transit

Michael Schwartz - Head of Customers and Policy, Ride Report

Oliver O’Brien - Senior Research Associate, University College London

Scott Shepard - VP Global Public Sector, Iomob

This document is built with the intention of supporting and helping cities in the GBFS adoption and does not serve as legal advice. Policy makers should determine if additional consideration of local laws and statutes is necessary before using the sample policy language contained in this document.