Future availability by vehicle

[richfab]

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.

Following the discussion in #616 and #722

Operators want to be able to describe the future availability of their services, for example to display it in trip planners. This is particularly useful for systems that allow vehicles to be booked in advance (e.g. carsharing, cargo bike share, etc).

What is the proposal?

Add a new OPTIONAL endpoint vehicle_availability.json which describes the future availability of each vehicle.

Is this a breaking change?

• Yes
• No
• Unsure

Which files are affected by this change?

Proposal to add a new OPTIONAL endpoint: vehicle_availability.json

[matt-wirtz]

Thanks @richfab.
I think the vehicle_equipment and pricing_plan_id would be necessary too as I explained in the original proposal: #616 (comment)
I'm not sure about the home_station_id being optional. If the vehicle is currently not available it will not show up in vehicle_status either. So it's not known where this vehicle is located and could be found rendering the info when it's available useless. So I think that should be REQUIRED too.

[richfab]

Hi @matt-wirtz,

As suggested, I added pricing_plan_id and vehicle_equipment to the proposal.

I renamed home_station_id to station_id to broaden the potential use cases.

I made the field station_id Conditionally REQUIRED. Indeed, we could imagine a shared mobility system with no station at all (i.e. all vehicles are within a small perimeter), in this case station_id would not be required.

Do you or anyone else see any other things that should be changed in the proposal? If not, I propose to open a vote in 7 days.

Thank you very much for your contributions and patience 🙏

[futuretap]

I made the field station_id Conditionally REQUIRED. Indeed, we could imagine a shared mobility system with no station at all (i.e. all vehicles are within a small perimeter), in this case station_id would not be required.

Couldn’t we handle that case with is_virtual_station = true, including a station_area? Otherwise we could end up in a situation where a vehicle-based reservation is made based on the current availability but then the vehicle is moved to the other side of the city. We would need some language to forbid that case. Imo it’s easier to make station_id always required. Then this case simply can’t happen.

[richfab]

Good points @futuretap. I made station_id REQUIRED.

Does anyone see anything else that should be changed in the proposal? If not, a vote will be opened in 7 days. Thanks!