GBFS and Shared Mobility Data Policy
Helping cities support seamless and sustainable mobility options through GBFS.
(This guide is available in Portuguese and Spanish.)
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 municipalities. The report provides a foundational understanding of how GBFS supports seamless, sustainable mobility options and how to leverage open source data’s potential when writing policy that can influence shared mobility adoption and practice. The specific policy language is applicable primarily to cities in the Americas. For the European stakeholders, a specific report will be published in the summer of 2021.
How GBFS can support the effort for cities to offer sustainable transportation
GBFS makes it easy for travelers to find and use shared mobility.
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.
In addition, GBFS provides municipalities 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 platforms 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 cities 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. 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.
Recommendations
Include GBFS as part of an RFP.
Your RFP should require a publicly accessible GBFS API as a requirement and should set expectations for the data needed to meet your policy goals.
Sample RFP Language
Data Sharing Requirements
- A publicly accessible API that conforms to the General Bikeshare Feed Specification (GBFS) current version available at https://github.com/NABSA/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 IT department, City Attorney’s office, City Clerk 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 thirteen 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.
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. |
| 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, email and feed_contact_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 free_bike_status 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_bikes_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. |
| free_bike_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_hours.json | Optional – This file is used to indicate hours and days of operation when vehicles are available for rent. It should be required if the service is not available for 24 hours a day, 7 days a week. If this file is not published, it indicates that vehicles are available for rental 24/7. (This file may be deprecated in the future, in which case system hours should be published using the method described in the appropriate version.) |
| system_calendar.json | Optional – This optional file should be required of systems that operate seasonally or that do not offer continuous year-round service. (This file may be deprecated in the future in which case system hours should be published using the method described in the appropriate version.) |
| 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/NABSA/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 [XX1] days unless prior arrangement has been made with [PERMITTING AGENCY].
- 90 days recommended
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, free_bike 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_name.json: field_name, field name
- file_name.json: field_name, field name
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. Cities and agencies should publish the locations of gbfs.json files on their websites or open data portals and on the openly available dataset catalogue connected to GBFS.
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 specification. (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.) Data regarding vehicles that are part of an active rental should never appear in GBFS feeds.
Useful links
MobilityData Shared Mobility team email: sharedmobility@mobilitydata.org
Acknowledgement
Shared Mobility Team at MobilityData
Heidi Guenin, Director, Product, Shared Mobility
Mitch Vars, Senior, Shared Mobility Specialist
Josée Sabourin, Shared Mobility Specialist
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
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.
