Cities, GBFS v2.2 is here for you
What you’re missing out on if you’re still stuck with v1.0 data.
(After getting caught up on v2.2, head over to check out what v2.3-RC has added, too!)
Specification updates create value for all General Bikeshare Feed Specification (GBFS) users, but, with new scooter and bikeshare pilots and RFPs arriving daily, we want to focus our discussion in this post on why cities should start requiring v2.2 data from their operators. The answer is simple: it creates benefits for cities and travelers.
GBFS v2.2 — what you need to know in 1 min ⏲️
A traveler wants to know the cost of their ride, the type of vehicle available, and the geographic limits of their trip. With GBFS v2.2, it is now possible.
4 major additions in v2.2:
- Pricing information 💸
- Representation of different types of shared mobility vehicles 🚲🛴
- Support for geofencing 🗺️
- Support for virtual stations and valet stations
If the shared mobility operators in your city are still producing v1.0, you’re missing out on some fantastic stuff. How do you determine what version you’re getting? Good question, and easy to answer: just go to any of your GBFS files, for example gbfs.json, and look for the version number:
{
"last_updated": 1609866247,
"ttl": 0,
"version": "2.2",
"data": {
If the version number isn’t included, it’s safe to assume you’re still on v1.0.
More information and transparency = a better decision process for the user.
Most of the rest of this blog post is an overview of the new features added in each different version of GBFS. Have a look at GitHub to keep up to speed and contact us for more information. We are never far away → sharedmobility@mobilitydata.org
Quick background
GBFS was initially developed as a standard for docked bikeshare. v1.0 was released in late 2015, and a lot has changed in the mobility industry since then. As the industry has evolved, GBFS has had to adapt to keep pace with new vehicle types, services, and technologies.
In 2019, NABSA contracted with MobilityData to govern and improve GBFS. In March 2020, we announced a continuation of that work through a partnership with NABSA. SInce that time we‘ve produced several extensions to the specification that have resulted in new capabilities and broader adoption.
In the years since GBFS was introduced, it’s become the defacto open data standard for shared mobility. GBFS is used by hundreds of shared mobility systems in over 45 countries worldwide.
v1.1 — Deep links, contact email, and versioning
v1.1 added three new features that set the stage for a better experience for travelers, and regulators as well as GBFS data producers and consumers.
Deep links 📲
Deep links — if you’re the kind of person who wants to see all of their options in one place, deep links are for you. With deep links, you can use an aggregating app to reveal all the shared vehicles in your city. When you’re ready to rent, just tap on the vehicle or station and you’ll be transported as if by magic to the vehicle provider’s app to complete the transaction. If you don’t have the provider’s app installed, you’ll be automatically taken to the appropriate app store to download it.
Deep links are an optional field in GBFS, but we encourage cities to require shared mobility operators to include deep links in their publicly published GBFS datasets. Most major trip-planning applications will require deep links for integration into their apps, so requiring them is one of the best ways to expose more travelers to shared mobility in your city.
Contact email 📥
v1.1 also added a feed contact email. This might not seem like a big deal, but if a feed goes down you don’t want your only option to be the operator’s customer service number. The feed contact email gives you exactly the details you need to contact the right person at your shared mobility operator.
Support for versions #️⃣
Finally, v1.1 laid the foundation for bigger changes to come by setting up support for versions. This improvement not only creates the framework for MobilityData & GBFS stakeholders to be able to make major changes to the specification, but also provides the basis for regulators to be more specific about their data requirements.
For more detailed information about deep links and some of the other improvements mentioned here, see this article.
v2.0 — Improved visibility, clarity, and privacy protection
More visibility 👀
With v2.0, the gbfs.json auto-discovery file changed from optional to required. The auto-discovery file functions like an index, giving data consumers the locations of all the other files in the feed. This means that when you publish the locations of GBFS feeds, you only need to publish the URL of the gbfs.json auto-discovery file.
Traveler privacy 🔒
GBFS v2.0 also contains a whole bunch of other clarifications and refinements, but the biggest change was made to protect traveler privacy. GBFS v2.0 requires the rotation of bike_id for all vehicles, and that’s a big deal, because without rotation it’s possible to track vehicles and identify users. If you’re still publishing static vehicle IDs, you should update your feeds to start rotating them as soon as possible. This is a significant change from previous versions, and we know that it has impacted a number of use cases. MobilityData is working to address concerns that arose and find fixes for other types of data that may be best shared privately (for example, specific vehicle details that can function similarly to an id).
v2.1 — Support for multiple vehicle types and geofencing
v2.1 was a big update (that officially existed only for 24h because v2.2 was implemented the next day!) full of helpful features that allow for better representation of the different types of shared mobility vehicles and operational models that are now common across the world.
Vehicle types 🚲🛴
Prior to v2.1, all vehicles in a GBFS feed were modeled in the same way, making it impossible to distinguish between a regular bike, an e-bike, or a scooter. With the addition of vehicle-type definitions, operators can publish detailed information about all the vehicles in their fleet. So if you’re looking for a bike, but you’d prefer it be an e-bike, and you want to make sure it has enough charge left in the battery to get you to your destination, v2.1 vehicle types is here to help.
Geofencing
v2.1 also added support for geofencing. ‘What’s geofencing?’ you ask? A geofence is a virtual boundary set up around a geographic area. Events can be triggered when a user crosses a geofence, and those events can range from push notifications to adjustments in trip pricing or even disabling of vehicles. Geofences can be used to delineate pick-up and drop-off zones, to limit where trips may start or end, to enforce speed limits and parking restrictions, or to define equity zones.
Virtual stations & valet service
v2.1 also added support for virtual stations and valet services. Virtual stations allow operators to define areas in the right-of-way where vehicles should be parked. Virtual stations share many of the same features as traditional internet-connected bikeshare stations but can take any form from simple pavement markings to bike or scooter racks. Both virtual stations and physical stations can now be designated as offering valet service, meaning that the station has unlimited capacity when valet service is offered.
In addition to vehicle types, geofencing, virtual stations, and valet service (we said it was a big update!), v2.1 also added aggregated numbers of available vehicles and docks by vehicle type. Got a hybrid system with a mix of regular bikes, scooters, and e-bikes? No problem: now when you tap on a station, it can display the total number of available vehicles of each type, as well as the total number of docks available to accept each type.
v2.2 — more flexible pricing
Finally, we’ve arrived at v2.2. (This article was about v2.2, remember?) This version adds a single extension, but it’s an important one, because it deals with pricing. Everyone wants to know how much that shared mobility trip is going to cost them, but prior to v2.2, GBFS wasn’t able to represent pricing in much detail. Now GBFS is able to represent a wide variety of pricing schemes to help users plan their trips. With this extension GBFS can represent price, whether it is a function of time or distance traveled, or in some cases, both. Average charges and price limits can also be represented.
Extra excitement 🤩
Having GBFS v2.2 now official is a huge deal. Why? The GBFS governance process means that any changes to the specification:
- Have been passed by a consensus vote that included data producers and data consumers, and
- Have been implemented in a public data set – so we know the changes are practical!
The extra hurdle of needing the changes to be implemented publicly is especially challenging in an industry where open data must take into consideration issues ranging from traveler privacy to business competition to regulatory standards. But…
The changes over the last year have truly brought GBFS into the present. While there is always plenty more to do, the ability to represent the general nature of shared mobility services in the same way across the globe is of huge value to travelers. But we need cities to require the data, operators to create quality data, and trip aggregators and planning applications to make it easy for operators who create the data to be included in any integrations. MobilityData will continue developing tools and resources to support the GBFS community — stay tuned for more updates soon, or join us on Slack!
