An open data standard is a documented set of requirements that describe how people and organizations can produce and distribute data on a particular subject. Open data standards are typically developed “in the open” meaning the public has a way to contribute.

Click on any of the below standards to learn more:

• • • JSON

    • GeoJSON

    • POSIX

    • IETF BCP 47

    • WGS84

    • IANA Time Zones

JSON stands for Javascript Object Notation. It is a lightweight text format for storing and transporting data, that is easy to understand and read. More information about JSON can be found at https://www.w3schools.com/js/js_json_intro.asp.

GeoJSON is an open data standard for denoting geographical features (lines and polygons) and their attributes in JSON format. More information on GeoJSON can be found at https://geojson.org/.

GBFS was created to make real-time shared mobility information available in a standardized format to support the development of traveler facing applications.

GBFS specifies how shared mobility data should be structured for proper interoperability of systems. Before the creation of GBFS, bike sharing systems each used different proprietary data formats, making it difficult for application developers to create tools for travellers.

Public GBFS feeds help facilitate the discovery of mobility services, increasing access to shared mobility. They also provide transparency around businesses that are permitted to operate in the public right of way. This transparency can increase public trust of shared mobility operators and their services.

GBFS is a specification for public data, however some GBFS producers have elected to publish private feeds that require authentication using an API key or login. Great care has been taken in the development of GBFS to ensure that data contained in the specification does not adversely affect user privacy. Requiring authentication of GBFS data greatly diminishes it’s value as a source of public information.

GBFS-Private is a new project undertaken by MobilityData to develop guidance on publishing certain types of information that may be too sensitive in nature to include in public GBFS feeds. The goal of the project is to preserve public data while continuing to protect user privacy.

GBFS is a real-time public data specification for consumer-facing applications, whereas MDS is not public data and is intended for use only by regulators. GBFS provides real-time data to support the discovery and use of mobility systems by travelers. MDS contains both real-time and historical data that is used by cities to monitor and regulate shared mobility operators.

All MDS Provider feeds are required to also publish a public GBFS feed.

For providers, GBFS 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 providers that data requests can be clearly defined and are fully implementable. As a consensus-based, open source standard, providers have an equal voice along with cities in the ongoing development of the GBFS specification. Comprehensive documentation and resources are available to cities and providers alike to aid in implementation.

For consumers, data standardization allows application developers to aggregate data from multiple providers across multiple markets. GBFS can eliminate the need for bespoke solutions for each mobility system.

For cities, requiring GBFS data as part of a shared mobility program can help to increase access to shared mobility services. Standardization of mobility data through GBFS has resulted in a growing marketplace of data management software and services. These products and services are used to assist cities in working with GBFS data to effectively manage and regulate mobility services.

GBFS does not contain personal data. Given the real-time nature of the data, as well as other safety measures such as rotating bike_id, a user’s information will never be shared and a user or individual trips will not be able to be traced.

GBFS does not contain operational data. GBFS only contains real-time data that is beneficial to the customer for their trips.

systems.csv is a list of all the known systems that publish public GBFS feeds.

systems.csv is the primary index of GBFS data sources, it allows developers to build software on top of it, provides a source for research projects, and demonstrates the reach of the specification worldwide.

systems.csv is currently maintained by MobilityData and community members. If you have or are aware of a system that does not appear on the list please add it by opening a pull request.

No - there is no compliance or validation requirement for inclusion in systems.csv. To be considered fully compliant with GBFS, systems MUST have an entry in the systems.csv file.

Shared mobility encompasses both micromobility, such as bikeshare and scooters, as well as other larger types of mobility, such as carsharing.

Shared micromobility typically refers to small, lightweight mobility devices with speeds below 25km/h that are hired by the end user. Examples include bikes, ebikes, scooters, etc.

While GBFS has its roots in bikeshare, it has been expanded as the shared mobility industry has evolved to encompass all forms of shared mobility vehicles.

GBFS is an open source project developed under a consensus-based governance model. Contributors come from across the shared mobility industry, public sector, civic technology and elsewhere. Proposals for changes or additions to the specification are made through Pull Requests. Once the community has had adequate time to comment and iterate on a proposal, the proposal is put to a vote. If the proposal passes, it becomes part of a release candidate. When the release candidate has been successfully implemented in a public data set, it becomes an official release. The complete governance and change process can be found here.

If you are interested in proposing a modification, you can do so at the GBFS GitHub repo. If you do not have the solution to the problem and would like to start a discussion, we recommend you open an issue. If you have a solution and would like to propose a change, please open a Pull Request.

GitHub is a website and service that allows people to work collaboratively on software and other projects. GitHub provides discussion forums and supports version control, which is an important part of managing and storing versions of a software project.

A repository, often called a “repo”, is a place where all of a project's documents and versions are stored.

An issue on GitHub is a place for discussion. Anyone can open an issue to spark conversation about the specification, be it a direction you would like to see the spec take, or a problem you are experiencing in using the specification.

A pull request is a request to change the specification. Anyone can open a pull request and open the floor to comments and discussion. Pull requests are then voted on to see whether or not they should be merged into the specification.

GBFS Best Practices are recommendations we provide that are not required under the specification, but that make your data amazing! They are identified in the documentation using the keywords "SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" and are to be interpreted as described in RFC2119, BCP 14 and RFC8174 when, and only when, they appear in all capitals, as shown here.

GBFS Best Practices are important so that the end user has access to the most reliable and complete information without compromising their privacy.

Validator tools do not check for conformance with Best Practices, since they are not explicit in the specification. It is recommended to use a manual approach to ensure conformance with Best Practices.

If you notice a data feed does not conform to Best Practices, you can try to contact the publisher using their feed contact email found in system_information.json.

If you would like to propose a modification to Best Practices, please do so by either opening an Issue or Pull Request via GitHub.

The bike_id field is a unique identifier for each vehicle in a system. Rotating bike_id means that a vehicle’s ID will change to a random string each time a rental ends. Use of persistent vehicle IDs poses a threat to user privacy. This is especially important for dockless mobility systems, where a user may end or begin their trip in front of their home or other frequently visited locations.

Using a validator ensures that your data conforms to the requirements set out by the specification. In a nutshell, a validator ensures you have a valid GBFS feed.

Currently, MobilityData does not have a GBFS validator, however we have plans to build a canonical validator in 2021. In the meantime, there are a handful of community-built validators and other tools available; check out our Tools page for the list.

A producer is the entity that is publishing GBFS, most often the system operator.

A consumer is someone who is using GBFS data. Examples of GBFS consumers are trip planning applications, researchers and regulators.

A system is the entirety of the shared mobility service from a single provider. Systems can be made up of docking stations, vehicles, and other infrastructure, and are typically limited to the local geography in which they operate.

A system’s fleet is made up of individual vehicles. Some systems may have multiple vehicle types, whereas others may only have one. Examples of shared mobility vehicles are bikes, ebikes, scooters, and mopeds.

A station is a location where shared mobility vehicles are made available for rent. Stations may include physical infrastructure like rental kiosks, docks or racks, or they may be virtual, delineated by pavement markings.

A geofence is a virtual boundary that defines a geographic area. When a shared mobility vehicle enters or exits a geofenced area, events can be triggered, for example a push notification can be sent to a user’s phone. Geofencing may be used to delineate pick up and drop off zones, no-ride zones, speed limit zones, equity zones, etc.

An API (Application Program Interface) communicates with two applications. A common analogy for explaining an API is to think of a restaurant; you are one “system”, and the kitchen is another. An intermediary is needed to communicate what you want the kitchen to do for you. That intermediary, in this case the server, is the equivalent of an API.

An API endpoint is the specific digital location where requests for information are sent by one program and where the resource lives.

A deeplink is a link that takes you to specific content rather than a general homepage. In the context of GBFS, a deeplink would take you to the rental page for that specific vehicle or station, rather than the system’s homepage.

There are a number of ways you can get involved with our organization and the Shared Mobility community!

• • Join our slack: https://mobilitydata-io.herokuapp.com/

  • Join us on Github: https://github.com/NABSA/gbfs

  • Become a member: https://bit.ly/Membership-form-2021

MobilityData has two membership types:

Core Member:

• • Core Members are voting members, who have the opportunity to join any working group, an invitation to send up to two representatives to any of our workshops with no fee, early access to new tools and services (exclusive access for the first three months), a stronger influence on our roadmap, and recognition on MobilityData’s website as a Core Member.

Regular Member:

• Regular Members are non-voting members who receive updates on MobilityData’s projects, an invitation for one representative to attend one MobilityData workshop each year, occasional invitations to selected working groups and discussions, and recognition on MobilityData’s website as a Regular Member.

For more information check out MobilityData's website.

To become a MobilityData member, please fill out this form.

If you have questions about membership, please contact [email protected]