GBFS V1.1 Add support for e-bikes and geofenced bike return areas

[dsgermain]

Decoupled geofencing zones from stations as much as possible, while maintaining the ability to link them as that exists in some systems. Zones need to be decoupled because they can live independently from stations, although in some systems they are intrinsically linked to them. Although some variables are the same between stations and zones, zones have features which are unique to them. If we left zones within stations, it would become confusing to define pure zones (stations that have no docks).

free_bike_status.json can now be used to determine the number of each type of bike available per station and per geofencing zone.

Add geofencing_zone_information.json to list low volatility information relating to geofencing zones, such as their position and which station, if any, they are linked to.

Add geofencing_status.json to list transient information relating to geofencing zones, such as whether the zone is allowing returns and the number of bikes it contains.

Modify free_bike_status.json to include the bike type, as well as a way to differentiate whether bikes are geofenced at a station, or geofenced in a free floating system.

Modify station_status.json to add is_charging_station field to indicate if charging ability is present at this station.

[sven4all]

Good to see that someone is working on improvements based on new developments in bikesharing.

I would like to make bike type more general. mechanical bikes and electrical bikes are indeed two types of bikes. But there are several other 'types' of bikes (bikes without gears, bikes with 3 gears, bikes with 8 gears, tandems, cargo bikes, all of these types are already for rent in the Netherlands).

Something else I am not sure about is if geofencing_zone_status.json is really needed, because most of the data in this file is derived data. All the data can be derived from https://github.com/NABSA/gbfs/blob/master/gbfs.md#free_bike_statusjson. Only is_returning is maybe interesting because some cities have zones where parking is forbidden, but I think it's better to develop a separate standard for municipalities where they can define those zones (because if you have 5 bike operators in a city you get 5 overlapping zones, if municipality makes those files available the bike operator can use them in their own apps as well).

EDIT: There is already a ticket that discusses bike_types. #81

[dsgermain]

@sven4all we have already implemented the feature as described, so if you want additional changes, you will have to open another request yourself.

In our context, geofencing_zone_status is needed. You don't need to implement it if you don't need it.

[nackko]

Hey @dsgermain, I think you mentioned pinging back when the consuming application is available ? I'm curious to see how it translates to features.

…

On Fri, 27 Apr 2018, 10:29 dsgermain, ***@***.***> wrote: @sven4all <https://github.com/sven4all> we have already implemented the feature as described, so if you want additional changes, you will have to open another request yourself. In our context, geofencing_zone_status is needed. You don't need to implement it if you don't need it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#92 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZbi8jrYCYMDNXArFxxtbQP7qwleDOWks5tsytDgaJpZM4Sm2vl> .

[barbeau]

we have already implemented the feature as described,

@dsgermain Very cool! What's the GBFS endpoint where the new features are available?

[dsgermain]

@barbeau it is not released yet (still in a version that is in QA). The first city to have it will probably be Chattanooga in a few weeks. I will ping here once deployed. cc @f8full

[tomschenkjr]

@Chicago is also including the draft v1.1 spec in this pull request as part of their dockless bikeshare program this summer (starting today). Companies haven't deployed, yet, but will also note when it's deployed.

[tomschenkjr]

Digging-in to some of the more detailed specifics of v1.1, it appears that station_information.json is still listed as a required. Though, as specified, it seems like a dockless provider station_information.json would simply be stations: [ ].

I assume this is because v1.0 required station_information.json was required, therefore, marking as optional would be perceived as a major change. Is this a correct assumption?

[mplsmitch]

@tomschenkjr - there's a discussion going on about clarifying that in #96. In short we would change station_information.json and free_bike_status.json to "Conditionally required" and rewrite the definitions. I don't think that would have any adverse effects on current feeds so maybe we could roll it into 1.1?

[tomschenkjr]

@mplsmitch - thanks! I'll hop over to 96 and discuss in-thread.

[barbeau]

Before v1.1 is released, I wanted to bring up the idea of introducing a version field in the spec, so consumers know when a producer has updated their feed. I started a discussion at #94 if anyone wants to talk further on this (just to keep all the discussion in the same place).

[sven4all]

Still not sure about this proposal.

Why should we introduce a separate entity for geofence? geofence for me is another kind of a station, it's not a physical station but a virtual station. Isn't it better to add a field to station that make it possible to distinguish physical and virtual stations?

[mplsmitch]

Oops! too many tabs open - I'll fix it. Thanks @sven4all

[hkieferling]

@dsgermain what you mean by array of entries? Each entry should be an object like [{ 'ebike': 5 }, { 'mechanical': 3 }] ? Can you give an example?

[dsgermain]

@hkieferling Yes, your example is correct. It would be nice to have a base set (enum) of approved bike types which the vendors can extend if it doesn't fit their model.

[dsgermain]

@sven4all we want to avoid the client (consumer) having to know which variables are "active" or "valid" within the station feed. If we merge geofencing zones within stations, some variables will be populated/not populated as a function of whether the geofencing zones are active or not. It is cleaner to separate the two concepts so that physical stations, mixed physical/geofencing stations or pure geofencing stations have a clear set of distinct variables.

In your counter proposal, how would the client know which variable they can use without having to know the implementation details of the feed?

[sven4all]

@dsgermain hmm, I think that this is in general a 'problem' with GBFS there are a lot of optional fields.

But let's have a closer look:
geofencing_zone_information.json in your proposal consists of the following fields:
https://github.com/NABSA/gbfs/blob/f76251ad4c754b62defc42562887724f287b73ea/gbfs.md#geofencing_zone_informationjson

while station_information.json consists of the following fields:
https://github.com/NABSA/gbfs/blob/f76251ad4c754b62defc42562887724f287b73ea/gbfs.md#geofencing_zone_informationjson

extra in station_information.json in comparison to geofencing_zone_information.json is short_name, address , cross_street, rental_methods (all those fields are optional, but I don't see any reason why they can't be used with geofences)
extra in geofencing_zone_information.json in comparison to station_information.json is: zone_area (can also describe the exact location of a station), station_id (but if a geofence is a station this field is not needed).

geofencing_zone_status.json (https://github.com/NABSA/gbfs/blob/f76251ad4c754b62defc42562887724f287b73ea/gbfs.md#geofencing_zone_statusjson) consists completely of data that could be derived from free_bike_status.json (https://github.com/NABSA/gbfs/blob/f76251ad4c754b62defc42562887724f287b73ea/gbfs.md#free_bike_statusjson) and therefor it's in my opinion cleaner to don't include that file at all in the specification.

I already started a while ago with making my counter proposal more specific, https://github.com/openbikeshare/gbfs/blob/virtual_location/gbfs.md#station_informationjson (WIP). I would like to hear others opinions as well.

[dsgermain]

@sven4all as mentioned, we have hybrid stations which are physical + a geofencing zone around or near them (same station ID). Your proposal does not seem to handle that. BTW, our proposal is already live on our Chattanooga system.

[sven4all]

Ok maybe you could explain hybrid stations better to me (I don't understand them, why would you combine a physical racks with a geofencing zone?).

In my proposal you can set is_returning in station_status.json https://github.com/NABSA/gbfs/blob/f76251ad4c754b62defc42562887724f287b73ea/gbfs.md#station_statusjson always to true I think that's exactly the same policy as you describe as hybrid? All bikes that are not in a rack can be put in free_bike_status.json.

[evansiroky]

Hello there, I am Evan Siroky and I have been working on improving OpenTripPlanner to be able to plan multi-modal trips with one-way car rentals (Car2Go and ReachNow). In order to make the trip planner properly take note of the service area of the carshare companies, we manually defined some GeoJSON representing the service area. These service area definitions are absolutely critical pieces of information that are required during trip planning purposes to adequately tell the user where a vehicle can be dropped off. It would be great if this PR could be vetted and merged into the specification as soon as possible.

I have a few recommendations for improving this existing proposal:

• I also don't fully understand the concept of a hybrid station that this change seeks to implement. I think I agree with @sven4all that the GeoJSON area could be defined within station_information.json. It seems like the feed would either define a station as being a geofence and thus it would require the geofence GeoJSON or the station would be defined as a physical location having docks, but it can't be both at the same time. If the system allows vehicles to be in docks or to be dropped off anywhere the feed would include (at least) 2 separate station definitions: one for the physical location and another for the geofence area. Maybe I'm missing something though, and if so, please further clarify the purpose of station_id and geofence_zone_id in free_bike_status.json. Otherwise, please remove the geofencing_zone_*.json files and put the relevant information in station_information.json and station_status.json.
• remove post_code from geofencing_zone_information.json. Zones can easily span multiple postal codes. Furthermore, having GPS coordinates or GeoJSON is enough to derive all kinds of info including postal codes, administrative areas, etc.
• remove num_bikes_available_types from station_status.json and geofencing_zone_status.json and also remove is_ebike from free_bike_status.json. I have a counter-proposal that goes into much more detail for handling vehicle types in Add vehicle type definitions #136.
• Add additional information to system_information.json regarding policies about dropping off a vehicle outside of a geofence:
  • Add a field bike_dropoff_outside_service_area_allowed that is a 1/0 boolean describing whether a vehicle being rented can be dropped off (thus ending the rental) outside of the defined service area.
  • Add a field bike_dropoff_fee_outside_service_area which lists the cost a user would incur for dropping off a vehicle outside of the service area if this is permitted.

[barbeau]

Related to @evansiroky's suggested changes above - could we get a show of hands for who has implemented geofenced bike return areas as currently presented in this proposal? And who has implemented a different approach (with a link to that approach)?

@dsgermain @sven4all ?

[evansiroky]

In a branch of OpenTripPlanner yet to be merged into the main branches, we have implemented code to consume data about car rentals that includes a geofence (see here). For now, there is a single url where the response body returned is a single GeoJSON MultiPloygon representing the full extent of the area that dropping off a car is allowed.

[antrim]

I'm with @MobilityData working for @NABSA.

Observing this discussion, it seems like experimental data practices around geofencing and vehicle types are beginning to diverge. @dsgermain Did Chattanooga implement this proposal? @evansiroky Any updates on the OpenTripPlanner implementation?

Here are my suggestions to move this forward:

• Continue discussion of bike types over in Add available bike type(s) in station_status.json #81, so we can come to consensus around one choice at a time.
• Develop a shared understanding of the use case needs in order to come to consensus. For example many people are asking about cases where there is a hyrbid station, in which available bikes and capacity is differentiated between between its components: station facility (discrete point) and a surrounding geofence.

@dsgermain Can you provide a description or example of cases showing why need the above values for the geofenced area and station facility separately, rather than for the aggregate station complex?

One process example we might borrow from GTFS is using a Google Doc to hammer out specification changes because it makes commenting and changes easier. This document shows use case examples: http://bit.ly/gtfs-pathways

Does anyone have other suggestions or feedback for how to move forward with a consensus specification change?

[evansiroky]

In the IBI fork of OpenTripPlanner, we have implemented code to consume GBFS feeds where each "bike" is assumed to be an eScooter. We currently have a test server running with this implementation. On our test server, we are consuming data from 7 companies operating eScooters with a GBFS feed. Of those 7 companies, two of the feeds do appear to have partially implemented this PR and have the geofencing_zone_status.json and geofencing_zone_information.json files/urls (although one of those companies has reversed the lat/lons in the geofencing_zone_information.json file). Due to inconsistent and lack of data, we haven't implemented code for this PR and instead manually load a GeoJSON file and assume that that is the allowable dropoff area for all companies. Although this manually created GeoJSON file does align well with one of the two feed's geofence that is defined, it does not with the other. I'll be creating an issue for our team to track regarding this.

On another somewhat related note, we have also implemented a way to manually load two other GeoJSON files to describe areas where a city has regulations of "no eScooter parking" and "no eScooter riding" respectively. Issue #167 hints at the need for a more structured way to obtain that information.

I think it makes sense to split up the effort of coming to a consensus on defining vehicle types and geofencing as they are fairly independent topics, although I think both are very important.

[antrim]

Note that there is an open pull request (openmobilityfoundation/mobility-data-specification#322) on the Mobility Data Specification (MDS) related to geofencing in GBFS. This feature would make it possible for cities to specify and change allowed and disallowed travel zones via the MDS API.

Possibilities:

• GBFS consuming applications could potentially consume those geofencing parameters from an MDS feed.
• And/or, a bike/scooter sharing system operator could consume the MDS feed and then pass into a GBFS feed for the GBFS consuming application.

Implications:

• GBFS needs geofencing and allowed travel policy features, even if this is also defined in MDS, because not every city has an MDS feed, and there is an immediate need for GBFS-consuming applications to have access to this data.
• MDS and GBFS should collaborate so semantics align, and so that both possibilities listed above would be possible.

Just wanted to establish this link so GBFS and MDS are on a good coordination path…

A comparison of open proposals to add geofencing and dockless features to GBFS is here: https://docs.google.com/spreadsheets/d/1mItFXGE0WdubtQBEeEPjil7HUyKt-48cyaoBL-k1pRc/edit. I'll add notes about MDS.

[marie-x]

Additional feedback or questions on the MDS Policy proposal are strongly encouraged! I am working on a presentation covering the background and rationale that's a little less dry.

[jcn]

The intent was always for the system_regions feed to be able to provide a denormalized place for details about things like geofences, but we hadn't actually gotten to a place where this was defined.

It's possible this does not actually cover the use cases we're thinking about, but it's definitely something to explore.

[heidiguenin]

PR #136 and PR #175 address these issues and represent a heap of input from GBFS consumers and producers. We're hoping we can solidify support around them as the next steps forward. It would be great to get all of your input over there on the solutions that have emerged so far as "minimum viable proposals" that better represents what operators are providing on the ground.

That said, I'd like to propose we close this issue and move relevant conversation there.

@dsgermain @sven4all @f8full @barbeau @tomschenkjr @mplsmitch @hkieferling @evansiroky @jcn @Karcass