Taskforce Tech: GBSF & API

[Ronald]

Today we agreed  (in the Taskforce meeting)  to use and build further on the GBSF (General Bike Share Feed) which is in use in the United States.

In this conversation, we will discuss possible extensions and we will link to our documentation on GitHub.

In phase 1 we define how all shared bikes in the Netherlands can be shown on one (integrated map).

In phase 2A we define how we can (deep)link to the operators to:

1. get more information
   
2. to book a bike
   
3. to open a lock
   

In phase 2B we will extend this standard to make in-app bookings and unlocking possible.

In this google group, we can continue our discussion and this will be input for our meeting on July 4, where we will pinpoint the standard we will use.

[Sven Boor]

During the meeting yesterday we created a list of data we would like to be covered with GBSF, some points on that list are already covered by the standard, for some others there are already proposals and discussions on the github page of GBFS. I try to give an overview.

• Deep linking

There is already a proposal for deep linking https://github.com/NABSA/gbfs/pull/25. This proposal includes exactly the requirements we formulated yesterday (deep linking for a bike and a station). The only thing that is needed is that there is one operator that implement this to get it approved.

• Type of system 

We would like to have an indication for what kind of system you are dealing (free floating, station based, virtual station based) in https://github.com/NABSA/gbfs/blob/master/gbfs.md#system_informationjson. I had already a discussion about this idea in https://github.com/NABSA/gbfs/issues/96, but not a concrete proposal yet.

• Pricing

Pricing is already included within GBFS https://github.com/NABSA/gbfs/blob/master/gbfs.md#system_pricing_plansjson. Although this format could be a bit more standardised, so that automatic calculations for price can be made for example. 

• Types of bikes

We would like to have information about what kind of bikes an operator provides within GBFS. There is already some discussion going on but no concrete proposal yet https://github.com/NABSA/gbfs/issues/93 

• Operation area

For a free floating system we would like to indicate where you can return your bike (for example you are only allowed to return the bike within the city). In this https://github.com/NABSA/gbfs/issues/65 thread there is already a discussion about this idea.

• Virtual stations

We would like to introduce virtual stations (a virtual location where you allowed to park your bike) within GBFS so operators comparable with Donkey Republic are supported as well. There is a proposal https://github.com/NABSA/gbfs/pull/92 that is covering this issue but I am not sure if this is the way to go. I will propose an alternative.

I think this is everything we discussed yesterday related to GBFS. If I missed something please append to this list. If you want to create a proposal for a point on this list, let me know. I created a fork within the openbikeshare organisation https://github.com/openbikeshare/gbfs where we can work together on proposals.

Last point, in GBFS a lot of fields/files are optional, for our situation we maybe have to make more fields required (for example https://github.com/NABSA/gbfs/blob/master/gbfs.md#system_pricing_plansjson).

Op woensdag 13 juni 2018 20:07:09 UTC+2 schreef Ronald:

[Ronald]

Let's create a draft agreement on the Tech standard in this google doc: https://docs.google.com/document/d/13rzPYHhkPT_DQ9pkS1Os78JhEuwNIch9KynjkurXrPc/edit?usp=sharing

[Ronald]

About:

• Deep linking -There is already a proposal for deep linking https://github.com/NABSA/gbfs/pull/25. This proposal includes exactly the requirements we formulated yesterday (deep linking for a bike and a station).

I propose to add this to our standard GBFS-NL . See google doc

[Ewout Oonk]

I would like to propose the following changes to the GBFS specification, which allow providers to integrate any type of bike share (free floating, station-based; virtual station based) through a single integration without the need to specify the type of bike share or to include additional fields for the operating area or virtual zone.

1. Data is only shown on a bike level.

Unavailable bikes that are either in repair, reserved or located in a station that is out of service are not shown. By only publishing data on bike-level station_status.json can be removed from the API. Therefore, the available data from the three types of bike share can be combined in a single object type. 

2. Return locations are combined in a single standardised object.

Point data (stations, including a parameter for the number of available docks) and polygons (operating areas and virtual stations) can be combined in a single GeoJSON object. 

Op donderdag 28 juni 2018 14:38:03 UTC+2 schreef Ronald:

[Sven Boor]

I think this are good proposals, but a problem is that it can make the previous version of GBFS incompatibel. In the end it's more important to use a standard that's already used in a lot of places, then having the most beautiful beautiful standard that's completely different.

1. Data is only shown on a bike level.

Unavailable bikes that are either in repair, reserved or located in a station that is out of service are not shown. By only publishing data on bike-level station_status.json can be removed from the API. Therefore, the available data from the three types of bike share can be combined in a single object type. 

That's fine to me within the GBFS+ specification because it's still compatible with GBFS. 

- What's the reason you don't want to include repair and reserved? As a user if I see an OVfiets for example and I can't rent it, I would like to know why.

- If bikes are not shown when a station is closed it's not possible to plan a trip before the station is opened (For example if I want to go to Vlissingen by train + bike on a sunday and I leave at 08:00, then that bicycle rent station is not opened yet, but when I arrive at 10:00 it's opened)

Maybe it's easier to stick to the GBFS specification and encourage the usage of free_bike_status.json. If we do that we have to add a optional field to free_bike_status.json that describes at which station a bike is parked (so that you can lookup the opening hours, and maybe some other interesting information.). 

 

2. Return locations are combined in a single standardised object.

Point data (stations, including a parameter for the number of available docks) and polygons (operating areas and virtual stations) can be combined in a single GeoJSON object. 

I think this already covered by this proposal https://github.com/openbikeshare/gbfs/blob/virtual_location/gbfs.md#station_informationjson do you agree?

[all...@donkeyrepublic.com]

Perhaps late, but.. 

I have received feedback from our tech team, they are very positive about the GBFS standard. We support this choice.

Our points of attention are points that i think have all been discussed, but i just want to make sure they end up in the check list:

- a user choses a location, then the DR app assigns a bike. The user should be able to change bike if desired.

- user should be able to report issues on the bike

- the user should be able to lock & unlock the bike while continuing the rental.

Allard

[Ronald]

We willen alle partijen die de intentieverklaring getekend hebben vragen, net als Allard (Donkey) zijn mening te geven over de GBFS+.

Om het overzchtelijk te houden graag een "voor/tegen/anders" in onderstaand google doc:

https://docs.google.com/document/d/13rzPYHhkPT_DQ9pkS1Os78JhEuwNIch9KynjkurXrPc/edit?usp=sharing

Als je dat meteen even doet (uiterlijk maandag ochtend 10 uur), hebben we nog voor de vergadering een mooi overzicht.

[Ronald]

Sorry de goede link om te inventariseren welke partij wat vindt:

https://docs.google.com/spreadsheets/d/1BQgUBQL_gJXPkENRXc-eJMYlJm5vV_ICx09p-JwXf-s/htmlview

Dat geeft overzicht voor de vergadering morgen