Improvements to GBFS

[mplsmitch]

I'm working with NABSA on a proposal to hire a consultant to help manage this project. If approved, NABSA will issue an RFP to develop a governance model and versioning scheme that will help keep things moving forward. In addition to better governance, GBFS needs to better reflect changes in the mobility industry. NABSA has now broadened it's scope to include micro-mobility services beyond shared bicycles and the specification should support those services. What else should go into a scope of work for this RFP?

[evansiroky]

This sounds like good news to me. The two things I would love to see added to the GBFS are the ability to define custom vehicle types and support for dockless vehicles via a definition of areas where vehicles are allowed to be dropped off at.

[yocontra]

We're primarily working from the city side of things - trip data is hard to get and even harder to keep current. We have ~15 (and growing) integrations to pull trip data from US bikeshare providers so cities can use it for planning purposes. Keeping these working is time consuming, and the data is usually 2-3 quarters out of date. Any standardization there would be a big leap forward.

[mplsmitch]

@contra - in addition to GBFS, this RFP also includes work related to MDS which is evolving as the standard for trip data.

[barbeau]

@mplsmitch Glad to hear more effort is being put into GBFS governance! From a consumer's perspective, zone-based service attributes (e.g., allowed drop-off areas) and deep links are two big holes in GBFS that I'd love to see become part of the official spec.

[mplsmitch]

Here's NABSA's RFP for work on GBFS & MDS. Deadline is March 29th. Please pass it on to anyone who may be interested.

NABSA Request for Proposals_ Data Consultant.pdf

[hunterowens]

@mplsmitch very excited from our end to see improvements to GBFS and inclusion with MDS.

Some things that I would love to see, a non-exhaustive list.

1) Payment / Fare Information - GBFS should make it easy to view the cost structure / access methods for a ride / vehicle, similar to the way we require Taxi's to have fare info the on the side of the vehicle.

2) Single endpoints for operators. Currently, in MDS, we are now requiring the GBFS auto discovery URL inside providers.csv to highlight all the open GBFS feeds, now that a good chunk of GBFS is not- city specific, we should have a better way of surfacing to developers how to access the entire universe of "operator x" vehicles.

3) Additional Vehicle Types. ( see above )

4) Integration with MDS /service_areas to express zones / preferences areas.

[heidiguenin]

The project @mplsmitch discussed at the start of this thread has kicked off. You can see NABSA's announcement here. And if you're willing to fill out the survey once it's live, please do fill in that opt-in form!

[kdwinnell]

Would love to see distance/charge remaining included in the feed so the rider is confident the scooter/e-bike selected will get them to where the want to go.

[heidiguenin]

The GBFS business & technical needs survey is live! Please take a few minutes to add your perspective, and feel free to share it with colleagues.

[kyle-nycdot]

Two suggestions for free_bike_status.json:

It would be incredibly useful to have a timestamp value for when the bike was placed at the current location (either by a trip end or rebalancing or otherwise).

It would also be great to formalize a requirement such that vehicles do not appear in the feed if they have not communicated with a server for more than a given amount of time, say 10-15min. I have experienced plenty of instances of bikes appearing in the feed for long intervals when the bike is, in fact, not there.

[heidiguenin]

A few notes now that this project is starting to wrap up. (That doesn't mean GBFS improvement is ending - just this work related to the RFP @mplsmitch mentioned.)

Deep links are in #25 and vehicle types are in #136 - both are open for voting right now! (#136 includes a new optional field last_reported in free_bike_status.json.

@kdwinnell's request for distance/charge remaining is covered by the current_range_meters field for station_status.json and free_bike_status.json in PR #136.

@hunterowens's request for payment / fare information would be covered in @kanagy's "Improving pricing information" proposal #194. Requiring an autodiscovery mechanism is currently proposed in PR #189, and it's open for voting right now!