Add vehicle drop off restrictions

[josee-sabourin]

What problem does your proposal solve? Please begin with the relevant issue number. If there is no existing issue, please also describe alternative solutions you have considered.

As discussed in issue #270, there is no way to describe how a vehicle should be returned at the end of a trip.

What is the proposal?

This proposal adds a return_type field to vehicle_types.json that allows operators to define if the vehicle is free_floating (vehicle must be returned anywhere within the service area), roundtrip (vehicle must be returned at original rental station), or station (vehicle must be returned to any station within the service area). The field is modelled as an array to account for hybrid vehicles that have multiple ways of being returned.

Additionally, to account for edge cases where a vehicle must be returned to a particular station that is not the original station, a home_station field has been added to free_bike_status.json.

Read the full extension proposal here.

Is this a breaking change?

• Yes
• No
• Unsure

Which files are affected by this change?

• vehicle_types.json
• free_bike_status.json

[kanagy]

Thanks for the proposal!

[kanagy]

Hello! I'd love to hear about aggregators / transportation apps on needs assessment in #270, specifically (sorry to be late):

• Are there any aggregators currently that already support hybrid systems (as described in the doc)? If so how are they currently represented in the feeds and does this proposal work for you?
• Is there an interest to support A to A systems, e.g. bike rental shops? This is a curious use case for transportation apps (built for getting from A to B); it would mean surfacing these it as a viable option for an A to B routes but then somehow cautioning that a user needs to get back to A eventually.

[viestat]

Hello!

Is there any intention to merge this PR?
This PR along with #349 are needed in order to resolve the need outlaid in #332.

Thanks!

[mplsmitch]

@viestat In order to merge this PR it needs to be voted on. We'll be calling a vote as soon as we've got the necessary support lined up. In order to pass we need at least 3 votes including one from a data producer and one from a data consumer. Would you be willing to support this as the data producer?

Full governance/change process is here

[viestat]

Would you be willing to support this as the data producer?

@mplsmitch thank you for clarifying, I am willing to support it.

[josee-sabourin]

I hereby call a vote on this proposal. Voting will be open for 10 full calendar days until 11:59PM UTC on September 1st, 2021.
Please vote for or against the proposal, and include the organization for which you are voting in your comment.
Please note if you can commit to implementing the proposal.

EDIT: Tagging for previous engagement in issue/google docs - @hbruch @leonardehrenfried @flaktack @viestat

[kanagy]

Google Maps supports this proposal. We don't intend on immediately supporting it, but think this will be useful in the future to model increasingly hybrid systems.

I think minor changes would be useful in this PR:

1. Renaming return_types to return_constraints seems more accurate. It makes it clear that these are optional constraints that when defined routing apps should respect.
2. Optionally, adding any_charging_station as a constraint after Add field to designate stations that support vehicle charging #340 PR is in.

[testower]

Entur supports this proposal and will implement it in our aggregation service.

[nbdh]

Nextbike supports this proposal. As such limitations are rather scarce in our systems publishing this field probably won't have priority for us.

[NicolasFrasie]

Communauto supports this proposal. It is required to specify if a vehicle is round-trip for GBFS to be able to model round trip carsharing (such as Communauto and Modo in Canada, Zipcar and Enterprise CarShare in US, Citiz in France, etc.).

This PR is a prerequisite for PR #350 which aims to extend the current GBFS specification to allow car sharing support (roundtrip like Zipcar, free-floating like GIG CarShare and station-to-station like BlueLA)

[viestat]

Dott supports this proposal, however we will not implement this until #349 (or any alternative proposal that fully addresses #332) is merged.

[Miryad3108]

The French national access point to transport data transport.data.gouv.fr supports this proposal which has been integrated into the PR #350

[evansiroky]

IBI Group supports this proposal, although we recommend renaming free_bike_status.json#home_station to free_bike_status.json#home_station_id to try to follow a naming convention that shows which fields have IDs as values.

[kanagy]

+1 for renaming to home_station to home_station_id for consistency with other fields

[cait32]

BCycle supports this proposal, but will not implement it immediately.

[ncancelliere]

Spin supports this proposal. We don’t plan on immediately supporting it.

[ezmckinn]

Superpedestrian supports this proposal, but like @viestat noted, would not implement until #349 is merged.

[josee-sabourin]

This vote is now closed, and it passes!

Votes in favour:
Google Maps (consumer)
Entur (consumer)
Nextbike (producer)
Communauto (producer)
Dott (producer)
Transport.data.gouv.fr (consumer)
IBI Group (consumer)
BCycle (producer)
Spin (producer)
Superpedestrian (producer)

Regarding @kanagy's and @evansiroky's comments: We will make the semantic changes once we merge into v2.3-RC. Regarding any_charging_station, we will open an issue to determine the need for this field.