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 #_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 #_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!

[richfab]

Thank you to everyone who contributed to this proposal in #616, #722 and #726 🙏

I hereby call a vote on this proposal. Voting will be open for 10 full calendar days until 11:59PM UTC on Friday, February 28.

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.

Governance on the spec change process can be found here.

[matt-wirtz]

+1 from Hacon (consumer) are going to implement this

[Lefois]

raumobil votes for the proposal. We are going to implement this as a consumer.

[futuretap]

+1 from Where To? / FutureTap (consumer). We plan to implement this.