bikeshare docks

[drewda]

It's not fixed-route transit, but bikeshare systems might be straightforward to represent in Transitland: each dock as a Stop. Bikeshare and fixed-route transit are also very complementary modes of travel.

Let's not consider this until after station hierarchies is in place--that's changing how Stops work.

Potential datasources:

• https://github.com/NABSA/gbfs
• https://github.com/eskerda/pybikes and http://api.citybik.es/v2/ by @eskerda (who reached out to us with a friendly note last summer)

[barbeau]

+1 for adding bikeshare. In addition to docks, we'd like to see free floating bikes (i.e., for systems that don't have docks, but instead GPS on the bikes). I don't know whether this could live in Transitland or not based on your road map, as it's live data that changes in real-time. We do have early support for floating bikes in OpenTripPlanner (more below).

One feature that I'd like to see for docks and bikes, but currently isn't supported in GBFS, is the ability to offer a link to the user to rent a specific bike, or a bike from a specific hub, by tapping on a map marker.

We've implemented this in the USF Maps App, but had to hard-code the URLs:

I've opened a GBFS proposal for adding a purchase_url that would allow support of this type of URL to be passed to GBFS consumers. I'd like to see this exposed via the Mapzen API as well, and any wisdom/support on the GBFS issue is appreciated :).

I've added some implementation details are below for how we're using bikeshare data in a few apps (USF Maps App - based on OTP, OTP Android, OneBusAway) in case that is helpful as the datastore and API for bikeshare are designed for Mapzen services.

---

Existing bikeshare app implementations

We currently support virtual bikeshare docks and free floating bikes in our OTP fork for our campus, the USF Maps App:
http://maps.usf.edu/#layers

Enable the "Share-A-Bull Bikes" layer to see the floating bikes and virtual docks/hubs (we don't have physical bike docks, but just geographic areas where they encourage riders to leave bikes). Trip planning via "Rental bike" will also give you a trip plan that picks up the closest floating bike (refreshed in real-time) and drops it at a virtual hub.

Bikeshare support is also implemented in OTP Android (trip planning and layer for docks only - see this issue for what we need to do to support floating bikes), and on-deck in OneBusAway Android in OneBusAway/onebusaway-android#402.

All of the above use OTP to consume a GBFS feed and expose bikeshare via an OTP API, both for the trip plan and the bike/dock locations. Here's the live API endpoint for the bike/dock locations for our USF Maps App:
http://maps.usf.edu/otp/routers/default/bike_rental

...and official OTP docs for this API:
http://dev.opentripplanner.org/apidoc/0.15.0/resource_BikeRental.html

Support for floating bikes in the OTP API is a first draft based on what was easiest to modify in OTP and still keep routing, etc. Right now floating bikes are still <station> elements (with capacity of 0 and availability of 1), and we're using the bike and hub prefix in the IDs to distinguish between the two. Ideally we'd split these out to different element types.

For us to use Mapzen services as an OTP replacement in the above apps, we'd need to be able to get docks and floating bike locations from the Mapzen API.

[barbeau]

FYI - for GBFS feed discovery, NABSA has a CSV file of all known vendor implementations in the GBFS Github repo:
https://github.com/NABSA/gbfs/blob/master/systems.csv

You could treat this as an API endpoint by hitting https://raw.githubusercontent.com/NABSA/gbfs/master/systems.csv.

[drewda]

Related: https://github.com/NABSA/gbfs/blob/master/systems.csv

[drewda]

Related, this is how Coord computes services areas for bikeshare providers: https://medium.com/coord/crafting-bespoke-maps-of-bike-share-service-areas-c46d47e8fb87