Make GBFS optional for some modes

[schnuerle]

Is your feature request related to a problem? Please describe.

With the forthcoming addition of new modes like carshare, passenger services, and delivery robots in 2.0, we should consider relaxing the GBFS requirement on all modes in all circumstances/jurisdictions. For example, since delivery robots are not directly reservable by customers, they should not be in any kind of public GBFS feed.

Describe the solution you'd like

Change the GBFS Requirement to be more optional for some modes (maybe even list which modes and scenarios it applies to). Note it should certainly still be required for bike and scooter share.

Is this a breaking change

• No, not breaking

Impacted Spec

For which spec is this feature being requested?

• provider

Describe alternatives you've considered

N/A

Additional context

We have gotten some questions about this already with regards to new modes, so I want to address it now and be clear.

[HiGregory]

@schnuerle We have looked at defining this as various (assets) being monitored.

I still think Delivery Robots should have a public data feed perhaps different than GBFS, but certainly, a way for the public and agencies to track or build apps for Civic Engagement.

Would a community initiative around exploring this potentially be needed to be a good path? I know this is an older request (May) so maybe some folks are already working on this.

[marie-x]

Yeah this is a no-brainer IMHO

[schnuerle]

This will be important to add when finalizing the 2.0 draft. For micromobility and car share, GBFS should still be required when operators are asked for MDS Provider implementations. For delivery robots and passenger services, since the location of the device is not needed when a customer books service, a GBFS feed should not be required - I don't think GBFS can even explicitly handle the publishing of these types of modes/vehicles anyway. Actually not sure it can handle car share right now? Asking @mplsmitch for clarity or who to ask.

@edwinvandenbelt can comment on how the TOMP-API handles any of its info as public feeds now. I know it publishes stations, but I don't think and vehicle locations are public.

[mplsmitch]

GBFS supports car share as of v2.3. Delivery robots could be modeled in GBFS but currently there's no vehicle form factor (e.g. scooter, bike, car etc.) defined for them. That's just a matter of adding another enum to form_factor in this endpoint: https://github.com/MobilityData/gbfs/blob/master/gbfs.md#vehicle_typesjson

[edwinvandenbelt]

@schnuerle the TOMP-API only publishes locations of available assets, independent if it's in a station or in a free floating area. And, we do have a mode field, derived from NeTEx modes and a sub mode, to specify it more precise. The latter one is free format.

[edwinvandenbelt]

And I agree, it doesn't make sense to require gbfs when there are no assets to reserve

[edwinvandenbelt]

Maybe opening hours and operating area. In some scenarios pricing plans for delivery costs... or are the robots reservable for external organisations? In that case, gbfs (and the TOMP-API) would be applicable

[schnuerle]

Merged with PR #825. If anyone has further comments you can leave them here and they may be addressed in the release candidate creation process.

Settled on GBFS being required (for both Provider and Agency) in modes where customers can directly reserve and operate a vehicle themselves (micromobility, car share), but optional when the vehicle is operated by someone or something else (delivery robots, passenger services).