Add geofencing, virtual station, and dockless support

[timMillet]

Context

MobilityData made a proposal to add geofencing zones, virtual stations and dockless support to the GBFS specification. The PR #175 was a first draft, and this Gdoc was kept up-to-date to reflect the evolution of the proposal, according to all the feedback received from the GBFS stakeholders.

As the GBFS specification format has changed a lot recently, the PR #175 has now plenty of conflicts so it was preferred to make this brand new PR. It means that this PR is replacing the PR #175 that will be closed.

Pull Request

A consensus seems to be reached on a modified version of the PR #175, version that the Gdoc reflects. Therefore, this PR adds to the GBFS specialition the propositions from the last version of this Gdoc. It includes only the minimum viable fields for GBFS to support geofencing zones, virtual stations and dockless systems. Some GBFS stakeholders have already committed to produce/consume data from this PR.

This proposal extends GBFS (General Bikesharing Feed Spec) to add support for:

• Dockless systems: free-standing vehicles (e.g. bicycles, e-bikes, scooters) that can be rented on the street, outside the bounds of a physical station.
• Virtual stations where vehicles can be deposited or retrieved from a bounded area, but no physical dock infrastructure is installed.
• Geofencing areas with rules for allowed and disallowed travel and speeds.

The specific changes are:

• Add geofencing_zones.json (as a GeoJSON FeatureCollection) to define geofencing zones and allowed and disallowed travel (1 new file with 13 fields)
• Extend station_information.json to allow description of the area of a virtual station (4 new fields).
• Revise station_information.json to describe stations with unlimited capacity (1 extended field definition)
• Extend free_bike_status.json to allow many systems (1 new field).

Don’t hesitate to provide us with your feedback on this PR!

[kanagy]

Some naming suggestions:

• Can valet be renamed is_valet_station to be consistent with is_virtual_station?
• Should start, end be called start_time, end_time to be more specific (although system_hours.json uses start_time, end_time too but for a different purpose)? Also, what was the reason for putting these outside of rules[] objects?

[timMillet]

Hi @kanagy
Thank you for your suggestions!

• I renamed the field valet in is_valet_station. I agree it has to be consistent with is_virtual_station.

• start and end fields

  • their names were chosen to be consistent with start and end within system_alerts.json that also require timestamp values. start_time and end_time within system_hours.json require time values, so I suggested we could do a distinction based on the field type. I could add an array times like in system_alerts.json.
  • these values were put outside of rules, like name, because they're properties of the geofencing zone itself (the subject), whereas what is inside of rules are properties applying within the geofencing zone (the object: describing travel allowances and limitations)

However, I do not have strong opinions so I can make changes to the start and end fields, if you want!

[kanagy]

Sounds ok. Thanks Tim! Do you plan to bring this to vote soon?

[kanagy]

One more thing: It is not clear from the spec how zones where operator has service should be modelled. Should feeds always contain zones where a provider can operate (e.g. whole city), as well as zones where there's restriction (e.g. can't park / speed limit)? Or only the latter?

Let's say London has provider A, B, C. They all don't allow rides in Westminster and all operate in Zone 1. But they can model their feeds differently:

• Provider A only sends restrictions only (i.e. a clockwise polygon around Westminster with "ride not allowed")
• Provider B sends restrictions and exclusion of operation zone (i.e. a clockwise polygon around Westmister and an anti-clockwise polygon around Zone 1, both with "ride not allowed").
• Provider C sends restrictions and inclusion of operation zone (i.e. a clockwise polygon around Westminster with "ride not allowed" and a clockwise polygon around Zone 1 with "everything allowed").

Which one of these providers is correct? It would be nice to make this clear in the spec and possibly give an example.

[timMillet]

This is a very good question! It’s true that there is a need for clarification. I think both operational zones (where providers can operate) and limitation zones (e.g. can’t park / speed limit) must be provided, to clearly specify where riders can use a vehicle, with or without limitations.

The default behavior should be that when nothing is defined, no limitations apply; i.e zones should be defined according to restrictions rather than allowance. 2 reasons behind this idea: a dockless system could be operated without any operational boundaries or limitations (so there’d be no need to define geofencing zones); and currently in the spec, no allowance zones are necessary for authorizing dock-vehicle users to ride (and the spec should stay consistent). It means that operational boundaries should be provided with anti-clockwise exclusion zones, and limitation zones with clockwise inclusion zones.

Following this thinking and your examples, Provider B is the only correct. Provider A does not provide the operational zone (London Zone 1). Provider C does provide the operational zone but as an allowance rather than a restriction: it means rides are explicitly allowed within London Zone 1, but are implicitly allowed outside of it as well (“no rules defined, no limitations apply”).

On another note, Provider C provides 2 overlapping zones so, as suggested in the former PR #175, a mention should be brought that zones must not overlap. Also, ride_allowed and ride_through_allowed should be required, otherwise it will bring a lot of confusion on the data-consumer side.

If you agree on this, I will make the changes, resolve the conflicts, and call for a vote!

[kanagy]

I agree that if provider doesn't specify geofencing zones, everything is allowed everywhere by default.

Beyond that I'm still not sure I understand your rule. Is the rule just - only ever specify restrictions in the feed (not allowances); limitation zones would be clockwise polygons with restrictions (disallowing riding inside the zone) and operational zones would be anticklockwise polygons with restrictions (disallowing riding outside of the polygon)? I think that works.

I would lean towards operational zones not being mandatory. As you said - by default everything should be allowed. A dockless system might not have any operational boundaries, but still may have parking restrictions for some areas.

About disjointness - I think zones can overap. Consider following example: a provider operates only in East London and West London. So the provider defines an anticlockwise polygon around East London and an anticlockwise polygon around West London. Because both are anticlockwise polygons, their outside areas overlap.

[timMillet]

Is the rule just - only ever specify restrictions in the feed (not allowances); limitation zones would be clockwise polygons with restrictions (disallowing riding inside the zone) and operational zones would be anticlockwise polygons with restrictions (disallowing riding outside of the polygon)?

Yes, it is. I clarified how to model geofencing zones in my last commit, based on our discussion.

About disjointness - I think zones can overlap. Consider following example: a provider operates only in East London and West London. So the provider defines an anticlockwise polygon around East London and an anticlockwise polygon around West London. Because both are anticlockwise polygons, their outside areas overlap.

I agree with your example. I do not have a strong opinion on that as long as if zones can overlap, there is a method for ordering polygons and their rules. So I will let the current definition of the field rules as it is (with "In the event of overlapping or colliding rule, the earlier defined rule (in order of the JSON file) takes precedence."). Are you ok with this?

[kanagy]

I think since now only restrictions are defined in the feed, in the event of overlapping, why not take the union of the overlapping zones? I.e. assume these zones overlap:

• A: ride_allowed=false
• B: ride_through_allowed=false
• C: ride_allowed=false

The consumer app would interpret this as:

• ride_through_allowed=false is in zone B
• ride_allowed=false is in zone A union C

What do you think?

[kanagy]

Another thing I noticed: should geofencing_zones object have a field "type" and value "FeatureCollection" for completeness with RFC7946? It seems that is required in https://tools.ietf.org/html/rfc7946#section-3.3

[timMillet]

I'm ok with the use case you described. I updated the definition of rules to reflect that idea:

In the case of overlapping polygons, the combined set of rules associated with the overlapping polygons applies to the union of the polygons. In the event of colliding rules in this set, the earlier rule (in order of the JSON file) also takes precedence.

I also added conditions related to same-polygon rule conflicts (in case producers define rules with and without vehicle_type_id).

In the event of colliding rules within the same polygon, the earlier rule (in order of the JSON file) takes precedence.

And finally, you were right about the type=FeatureCollection field for compliance with RFC7946, so I added it. Thank you very much for all your contributions!

@kanagy please let me know if you have any other comments! Then I'll call for a vote.

[kanagy]

This looks good to me. Only not sure if you want to omit vehicle_capacity since that has a dependency on #136

[timMillet]

Evan just called for a vote on #136 so I'd leave the references to the vehicle type proposal in this PR, hoping both will be adopted at the same time 🤞

[timMillet]

I think the Geofencing, virtual station, and dockless-support proposal is ready for a vote! I hereby call a vote on this proposal. Voting will be open for 7 full calendar days, until 23:59:59 UTC on Tuesday, April 21st.

Please vote for or against the proposal, and include the organization for which you are voting in your comment.

Please also note if you can commit to implementing the proposal.

[kanagy]

Voting +1 on behalf of Google Maps. We're implementing this proposal with Lime.

[madupras]

+1 from PBSC

[bhandzo]

+1 from Bird.

[JMilot1]

+1 from Transit

[ghost]

+1 for IBI Group

[heidiguenin]

The vote on this is now closed, and it passes!

Votes in favor:
Google Maps
PBSC
Bird
Transit
IBI Group

No votes against.

We'll be merging, creating v2.1RC, and checking in with Google & Lime to double check implementation to try to move this to official ASAP. Thanks all!