Better clarification of vehicle rental dropoff restrictions requiring station-only dropoffs

[evansiroky]

As of the latest spec in 3.0 it seems that it is a little unclear how a provider would communicate that their system requires vehicles to be dropped off at stations only. There appear to be only a few places in the spec that pertain to this topic. Firstly, in the Files section, the free_bike_status.json file says:

...Required of systems that offer vehicles for rent outside of stations.

However, in the geofencing_zones.json section, it says

By default, no restrictions apply everywhere.

Given this wording, it appears this could lead to ambiguous situations for systems the have drop-off restrictions that are not completely defined in the geofencing_zones.json file or for systems that require drop-offs at stations only or even some kind of hybrid system that requires some but not all vehicles to be dropped off at a station only.

Perhaps there should be some kind of flag in system_information to indicate that the entire system requires drop-offs at stations only. Or maybe each vehicle in free_bike_status.json should have some kind of flag that says whether the vehicle must be dropped off at a station.

[mplsmitch]

Related to this we need a way to designate systems that require A to A rentals where vehicles need to be returned to the station or parking place where the rental originated. Hybrid systems make this tricky and there are a lot of them now where different rules apply depending on what type of vehicle is rented. Maybe vehichle_types.json should be extended to apply rules to classes of vehicles?

[josee-sabourin]

This was something that was explored in the carsharing (#255) proposal using a field such as return_type or share_type with enumerated values such as free_floating, roundtrip, station_based, etc. The biggest question was whether this field should exist in free_bike_status.json, vehicle_types.json or system_information.json, hybrid systems would rule out system_information.json though.

[NicolasFrasie]

From the carsharing point of view (as a producer), there are two aspects I would like to highlight :

• Free-floating carshare services create very small areas with a limited number of parking spots, inside the areas of service where it can be difficult to park, or outside the areas (such as airports). They should be considered as stations since the number of parking spots and vehicle available are generally displayed in the apps of the service.
• An increasing number of services offer free-floating and round-trip carsharing in the same city (Zipcar in London ; Communauto in Montreal ; Mobility in Geneva).

Therefore, as mentionned by @josee-sabourin , I suggest to add a field such as return_type or share_type with enumerated values such as free_floating and roundtrip in station_information.json and vehicle_types.json (or free_bike_status). I would be more than happy to share examples with you.

There is one tricky example I don't know how to deal with : [Hvv Switch point stations in Hambourg (Germany)](https://www.hvv-switch.de/en/hvv-switch-points/) can "host" different services, including round trip and free-floating carshare services. This type of stations dedicated to multi-modalité is duplicated in others cities (Wien in Austria and Belgium as far as I know).

[stale]

This discussion has been automatically marked as stale because it has not had recent activity. It will be closed in 60 days if no further activity occurs. Thank you for your contributions.

[evansiroky]

Adding a comment as I believe this is still a relevant issue.

[heidiguenin]

Adding a comment as I believe this is still a relevant issue.

Thanks @evansiroky - it is indeed, and we're working on it soon. We'll be working on the needs assessment for vehicle drop-off restrictions in May & will be looking for additional examples from the community.

[josee-sabourin]

We've conducted a needs assessment on this issue to identify some key questions to discuss before moving to a pull request.

The main question, as already identified above, is does the dropoff restriction live in system_information.json, vehicle_types.json, station_information.json, or free_bike_status.json?

That said, none of these solutions can encompass every outcome:

• system_information.json - how would you model a hybrid system?
• vehicle_types.json - currently an optional file
• station_information.json - only a required file for station-based vehicles, additionally, how would you model stations that may have some spots for A-to-A and others for A-to-B rentals?
• free_bike_status.json - only a required file for free-floating vehicles

This leads to bigger questions as we move towards a new major version release:

• Should vehicle_types.json become required?
• Should free_bike_status.json become required?

[hbruch]

I added RegioRad Stuttgart and Freies Lastenrad Stuttgart as examples to the needs assessment document. The latter would be a pure roundtrip system. For RegioRad, default system return mode would be station_based, exceptions might be modeled in vehicle_types.json as roundtrip.

A not yet addressed need is that vehicles might have a home station where they should be returned to, even if rented elsewhere. For these, an extension to free_bike_status.json might be necessary.

free_bike_stations.json IMHO should stay optionally required.

[josee-sabourin]

Thanks for all the input, we've opened a pull request at #329. I'll be closing this issue and the discussion can continue over on the pull request.