Implementation of General Bikeshare Feed Specification

[trevorgerhardt]

NABSA has announced the approval of GBFS and bikeshare providers are going to begin publishing in that format. We should prepare OTP to consume that data.

See: http://us11.campaign-archive1.com/?u=8327d4c9221c755645cd5334f&id=bfc8d7b6f0&e=ec9a6946e8 and http://nabsa.net/ for the announcements.

Copy of the specification draft: https://docs.google.com/document/d/1ff9uv7z3rVdOSBAseY9v0CQphY5PzEGlmfpHqxLJoXE/edit#heading=h.ic7i1m4gcev7

https://github.com/NABSA/gbfs

[laurentg]

Excellent, good news. It would be nice indeed for OTP to have a GBFS connector.

[barbeau]

We are working on this for our USF deployment (SoBi), and should be able to
submit a PR.
On Dec 4, 2015 4:13 AM, "Laurent Grégoire" notifications@github.com wrote:

Excellent, good news. It would be nice indeed for OTP to have a GBFS
connector.

—
Reply to this email directly or view it on GitHub
#2181 (comment)
.

[barbeau]

cc @jmfield2 - see above for link to the draft spec

Supposedly the final spec will be published under NABSA's Github account soon:
https://github.com/NABSA

[fruminator]

@barbeau -- will what you are doing with OTP/GBFS for SoBi in USF actually handle the 'floating' bikes when doing trip planning? That is, will it plan trips using the bikes that are available but not at stations/hubs?

[barbeau]

@fruminator Good question - I believe the short answer is no, it won't fully handle the floating bikes situation. On the drop-off side of the bikeshare trip leg, it's more of a workaround given current OTP capabilities (see details below). We debated how exactly to handle this, especially with some of the pickup/dropoff rules still being in flux at USF.

@jmfield2 is the one actually implementing floating bike support, so he can correct me if I'm wrong, but I believe this is what we finally decided given the limited time/budget of our project:

• Available floating bikes to rent are treated like mobile stations with availability of a single bike, and infinite capacity for dropping off bikes.
• Hubs are treated like normal stations with real-time availability and capacity defined by the API response.

For the bikeshare trip leg pickup - this allows OTP to find the origin of the bikeshare leg of the trip as either a single floating bike location or a hub with available bikes - this behavior is what you would expect.

For the bikeshare trip leg drop-off - This is the workaround part. OTP was originally built to handle fixed stations, so it looks for a bikeshare location with available capacity to drop off the bike. In our implementation, that dropoff location will be either a hub with available capacity (which is expected behavior), or another location of another available bike to rent (which is the hack/workaround part, using the infinite capacity definition of the floating bikes). This allows the trip plan to be calculated by OTP, and there are typically enough available floating bikes to give a reasonable drop-off location for the bikeshare trip leg.

USF rules on available drop-off locations are still evolving - right now the vast majority of the regularly traveled part of campus is a massive drop-off zone, so riders can effectively drop off the bike wherever they want. I believe SoBi's model is to provide credit to riders that drop off bikes at hub locations, but at USF the service is free, so that's not much of an incentive :). This makes the drop-off location presented by OTP less important than the pickup location - it's not really information that the rider needs. We plan to hard this publicly in mid-February, so we'll see what kind of feedback we get at that point, and how the rules continue to evolve. We recognize that this workaround may not be feasible for other deployments - we'd certainly welcome any additional improvements to change the actual OTP bikeshare routing behavior.

Our implementation to support GBFS is in this PR on our own repo (which we'll hopefully be putting into a PR here soon) - CUTR-at-USF/usf-mobullity#109.

And, looks like this is the official NABSA repo for GBFS, with a draft link to the spec currently available:

https://github.com/NABSA/gbfs

[laurentg]

Concerning "floating-bikes", I'm not sure about those exact rules; but if you assume you can go all the way up to your destination with the rented-bike and drop-it off at the final destination, it probably could be handled by OTP. The same kind of development was done some time ago with GoAbout for the Netherlands (it was called "OV-fiets" mode, where you can rent a bike for one day, usually at a railway station, and keep it at your destination until you come back later on).

This developement is available (AFAIR) in the branch ov-fiets here, but was not merged back in master.

In depart at, the concept is rather simple, we just allow as a final state the mode "renting a bike" (State::isFinal()) when some request flag is set (in this case, it can also depend on the rented bike, if the rental station allows this mode). In arrive by it's a bit more complex as you need multiple states at your starting point: one state renting a bike and another not (in case your destination/origin is close by, you want to be able to compute a walk-only path).

[jmfield2]

I think @barbeau is mostly correct but as of right now for floating bikes bikesAvailable is set to 1 (as he said), but spacesAvailable is 0. This can be made "infinite" trivially and allow OTP to drop bikes in the same location, but this assumes there is some kind of rack there for the user to correctly lock the bike and based on recent announcements of fees starting next year for anyone that doesn't correctly lock a bike at a rack (not necessarily a hub AFAIK), I believe we decided to turn that off and only allow drops at hubs with space. This does mean some routes may need to go beyond a destination and then walk back - the number of active hubs is currently 9.

Another option might be to add static station/racks on campus with bikes=0 and spaces > 0 either through OSM, or loading them locally (which I also implemented for quick testing) - but we don't currently use it because I'm not sure if it is safe or acceptable to have more than one dynamic bike rental updater adding stations from distinct sources..

As for ov-fiets, does depart at mean the bike dropoff @ destination, or is that for arrive by? I wasn't entirely sure :) I think that could work, as assuming there are racks nearby at most common destinations is probably safe.

As for the implementation of the opendata gbfs spec that we have so far, we currently consume the station_information, station_status, and free_bike_status feeds extending the GenericJSONBikeRentalDataSource class and just mapping the defined fields to the relevant OTP structures. I also needed to skip any bikes/stations with is_reserved or is_disabled set, obviously.

The hub implementation is a bit more complicated because the data is split between station information and station status - so I opted to implement it as a seperate class from the floating bikes. Basically, we load the general hub info (name) from station info which adds the data to a private 'hubs' HashMap for <id, BikeRentalStation>. Then, we load station status and add real-time availability to the previously created station (loaded by hubs.get(id) ), and finally adds this to the standard 'stations' structure.

[laurentg]

@jmfield2

As for ov-fiets, does depart at mean the bike dropoff @ destination, or is that for arrive by?

Both. In the OTP parlance, depart at means you do a forward search (starting at the journey origin and searching toward the journey destination), while arrive by means a backward search (starting at the journey destination and searching toward the journey start). In both you drop the OV-fiets at the journey destination; but depending on the mode that corresponds either to the starting or ending state.

To summarize, depending on the mode:

• depart at: initial state (journey departure) is walking, no rented bike; ending state is renting a bike or walking.
• arrive by: initial state (journey destination) is renting a bike or walking (thus 2 initial states); ending state is walking, no rented bike.

[barbeau]

PR for GBFS support as discussed above now open at #2315.

[barbeau]

Note that there is now a branch with GBFS implementation by @demory for TriMet's MOD Sandbox project here:
https://github.com/opentripplanner/OpenTripPlanner/tree/gbfs

[barbeau]

GBFS is now supported in the master branch following the merge of PR #2458, so this issue can be closed.

Configuration is pretty simple, very similar to adding a new real-time updater for real-time transit info – instructions for adding GBFS feeds is at:
http://docs.opentripplanner.org/en/latest/Configuration/#real-time-data

…under the last entry “GBFS Configuration”.