Future availability of vehicle types by station

[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

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).

What is the proposal?

Add a new endpoint vehicle_type_availability.json which describes the future availability of each vehicle type by station.

Is this a breaking change?

• Yes
• No
• Unsure

Which files are affected by this change?

Proposal to add a new endpoint: vehicle_type_availability.json

[mplsmitch]

@richfab How do you handle time_slots when they're is no future booking to set the until?
Should it be null?
"from": "2024-12-24T08:15Z", "until": "Null"

[richfab]

Thanks @mplsmitch. I was just going to ask if we should make until OPTIONAL for when a vehicle type is available all the time starting from a date.
{"from": "2024-12-24T08:15Z"}

[mplsmitch]

I like that

[Lefois]

Thank you @richfab for open this PR! Indeed a very nice addon for many use-cases that I would vote for.

As far as I understood the proposed file is optional. Also I understood from the discussion in issue 616 that availabilities based on certain vehicles are not wished by many operators due of privacy reasons, which is understandable. However, the carsharing provider in our region (and one of the biggest in Germany), stadtmobil has availabilities only vehicle-wise. There are no "vehicle types". It would completely make sense for me to add availabilities as well to vehicles. So that we say it is optional to add whethervehicle_type_availability.json or as similar vehicles_availability.json

If I think about our forecast idea for micromobility (issue 612) we might also remove the "Not supported for free floating (dockless) vehicles" constraint for the vehicles.

Once accepted, we would start implementing a reference implementation for vehicles right away as well as we would support the vehicle_types approach and get an implementation ready.

[futuretap]

I second this, @Lefois. I helped the folks at CommonsBooking, a WordPress plugin to manage small, mostly volunteer-based (cargo) bike operations with their GBFS API. Their GBFS adaption suffered from the lack of availability modeling in GBFS. The idea of CommonsBooking is to manage reservations for all sorts of items, including vehicles. They allow hour- or day-based reservations. So for their data model a vehicle-based availability is most appropriate.

[matt-wirtz]

@Lefois Thanks for bringing up this topic again. And that brings us back to the very beginning of the discussion where we already suggested to provide future availability by vehicle.
Having the future availability by vehicle/asset would make things much easier here. For the producer the availability data by vehicle is readily available. I think there is no MSP who already has it by vehicle type. So that needs to be processed. The consumer side systems probably are more designed to work with per vehicle information. So less effort there too. But they have the advantage that as a workaround they could easily propagate the per vehicle type information to virtual vehicles - maybe causing some issues down the road.
So strong support for having the option to provide future availability information by vehicle or by vehicle_type.

[richfab]

I observe that the need for a vehicle-based model is supported by several data producers and data consumers.

For this reason, I will close the current PR and create a new PR #726 'Future availability by vehicle' to continue the discussion.

In this discussion, let's keep in mind the guiding principle of GBFS which is that data is public and useful to travelers.

Thanks! 🙏