Freefloating bicycles

[sven4all]

First well done with creating this standard!

I want to use this standard to make positions of freefloating bicycles available available as open data. In the standard https://github.com/NABSA/gbfs/blob/master/gbfs.md#files is specified that station_information and station_status are required. In a freefloating bicycle system there are no stations and therefor these files are not relevant.

Another suggestion that I have is adding a type of system (free floating/ station_based maybe some other options renting a bike at a station and having to bring it back to the same station) to system information https://github.com/NABSA/gbfs/blob/master/gbfs.md#system_informationjson

I am interested in your opinion. Based on that I could propose formal changes.

[mplsmitch]

@sven4all You are correct - in a free-floating system, station_infomation.json and station_status.json would not be required end points but free_bike_status.json would go from optional to required. What do you think would be the best way to express that? I'm reluctant to make every end point optional.

system_type sounds interesting. The challenge is in clearly defining the types. I could see something like:

• station based

• free floating

• hybrid (both stations and free floating)

Going beyond that would require a way to describe the various business rules or city regulations. For example in a free floating system are users required to lock the bikes to a physical object (lock to requirement), park them in designated spaces ( virtual station), park anywhere legal or some combination?

[sven4all]

@mplsmitch Thank you for your input!

I think it should be made semi-optional. You have to provide at least station_information.json and station_status.json or free_bike_status.json. If neither of this two is provided it's completely useless. Do you agree?

The second part is a bit more difficult. I don't have an overview of all different policies that are implemented world wide (in the Netherlands an effort is made to create one policy that is applied by all municipalities). Let's start with system_type and later think about how to implement all those rules, hopefully there will some form of standardisation by governments on those rules as well.

[barbeau]

I think it should be made semi-optional. You have to provide at least station_information.json and station_status.json or free_bike_status.json. If neither of this two is provided it's completely useless.

We used the term "Conditionally required" in GTFS-realtime v2.0, and then explained the conditions under which the field was required in the "Description" section.

[sven4all]

@barbeau Good addition!

[tomschenkjr]

Great conversation.

One of the questions is how easy it is to tell whether a system is dockless or docked, and therefore, which files I should expect (especially if there isn't a gbfs.json).

Based on @mplsmitch suggestion, I agree it makes sense to include system_type in the system_information.json file. Likewise, these systems may not be binary, so they may offer both docked and dockless (as well as scooters, etc.) in the future. So, the additional field may be like:

system_type: {
  "docked_bikes": "yes",
  "dockless_bikes": "no",
  "scooters": "no"
}

As a result, if system_type.dockless_bikes: yes then the programmer knows that free_bike_status.json must also be present.

This, combined with "conditionally required" used to GTFS-realtime v2.0 should give both clear documentation and schematic clarity for people interacting with the data.

/cc @levyj @nicklucius

[sven4all]

@tomschenkjr I am not so sure about this kind of system_type, do you have examples of systems that combines docked_bikes and dockless_bikes (other then hybrid systems)?

In #92 I made a comment about different type of bikes, a scooter is another type of bike, isn't it? What types of bicycles are available is not related to the system_type in my opinion. I am thinking about how different bike types can included in a logical way (single speed, 3-speed, 8-speed, e-bike, scooters etc.)

[mplsmitch]

My system will combine both docked and dockless staring in August. There are a number of others headed in this direction.

…

On Sat, May 5, 2018, 10:34 AM Sven Boor ***@***.***> wrote: I am not so sure about this kind of system_type, do you have examples of systems that combines docked_bikes and dockless_bikes (other then hybrid systems)? In #92 <#92> I made a comment about different type of bikes, a scooter is another type of bike, isn't it? What types of bicycles are available is not related to the system_type in my opinion. I am thinking about how different bike types can included in a logical way (single speed, 3-speed, 8-speed, e-bike, scooters etc.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#96 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOh7FXjkeMIFsHT3zvztbpBue_bGaktVks5tvcZvgaJpZM4TjDIO> .

[sven4all]

Ok clear, then I have no problem with including that in the way suggested. Only I would suggest to keep the "scooters" part out, and add "virtual_docked_bikes"/"hybrid" (or a better name if someone has an idea) for systems working with geofenced stations.

Do you have more information about how such a combined system will work (docked en dockless_bikes)? (just curious).

[mplsmitch]

What I'm talking about is an existing station based system that will expand by adding dockless bikes. We refer to this as hybrid. How hybrid or dockless systems will work depends on the particular business rules of the operator or city requirements. In some cases that means geo-fencing, in others bikes are required to be locked to something while others will use only wheel locks and be parked anywhere legal.

…

On Sat, May 5, 2018, 12:14 PM Sven Boor ***@***.***> wrote: Ok clear, then I have no problem with including that in the way suggested. Only I would suggest to keep the "scooters" part out, and add "virtual_docked_bikes"/"hybrid" (or a better name if someone has an idea) for systems working with geofenced stations. Do you have more information about how such a combined system will work (docked en dockless_bikes)? (just curious). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#96 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOh7FQP-U7zQif_IjfTmTFFXalarxdSUks5tvd3qgaJpZM4TjDIO> .

[khwilson]

Just throwing in that in DC, dockless providers either just provide an empty list of stations (there aren't any after all) or don't provide station_* files. In #93, I suggested that one way to possibly handle "hybrid" systems was to provide a list of bike_types instead of is_bike which would capture scooters or other possible attributes (e.g., multiple speeds of bikes). The bike_types could either be fixed by the standard, or perhaps provided as custom metadata in the gbfs.json file.

Perhaps in version 2, it would be better or reverse the presumption of docked and make free_bike_status.json be the required feed and have individual bikes their point to their stations? In this world, station_information.json can either just be an empty list or optional.

[mplsmitch]

#102 has been merged - closing #96 & #102