Proposal: Clarify use cases between MDS Vehicles and GBFS

[dirkdk]

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

I am wondering if the requirement to also have a GBFS API should be dropped. https://github.com/openmobilityfoundation/mobility-data-specification#gbfs-requirement

If the main reason is compliance checks, I would say the Vehicles endpoint replaces this need and we can drop it. We would like this very much as a provider. This would enable us to use different Quality of Service levels for MDS vs GBFS. For instance, as GBFS is public, we rate limit it but run into problems with data aggregators (@jiffyclub can attest to this) sometimes. If GBFS is not used for compliance anymore we can safely adjust our levels without running the risk of making compliance checks more fragile.

Describe the solution you'd like

Remove the requirement for GBFS for compliance purposes, change it to a suggestion/encouragement for sharing data with consumer services.

Is this a breaking change

A breaking change would require consumers or implementors of the API to modify their code for it to continue to function (ex: renaming of a required field or the change in data type of an existing field). A non-breaking change would allow existing code to continue to function (ex: addition of an optional field or the creation of a new optional endpoint).

• No, not breaking

Impacted Spec

For which spec is this feature being requested?

• provider

[quicklywilliam]

I'm generally supportive of this – GBFS was not intended for regulatory/compliance needs and its regulatory necessity is much diminished with the arrival of the Vehicles endpoint. The existing language does a very good job of addressing this.

That said, one thing that is valuable about having GBFS as part of MDS is that it makes it much more likely that MDS-using cities will require a public-facing GBFS feed in their permit language. Perhaps we could think of a way to retain this benefit without GBFS being formally part of the spec.

Another thing that should be considered is that there is a new "GBFS Private" variant of GBFS being developed that is for regulatory purposes. This is being requested by cities who do use GBFS for regulation, sometimes in addition to MDS and sometimes in its stead. I will reiterate that I'd love to see "GBFS Private" and the Vehicles endpoint become the exact same thing.

CCing @mplsmitch on this.

[thekaveman]

Just to reiterate:

...one thing that is valuable about having GBFS as part of MDS is that it makes it much more likely that MDS-using cities will require a public-facing GBFS feed in their permit language.

This was the original reason for the GBFS requirement in MDS.

[mplsmitch]

Maybe I'm missing it but I don't find anything in the MDS documentation linking GBFS and compliance checks. What I do find is this:

This GBFS feed is useful for residents and can be a useful cross reference for MDS data.

Public GBFS feeds can also encourage a competitive ecosystem of mobility service providers. GBFS aids in the discovery of available vehicles and enables the existence of consumer facing aggregator apps which allow users to see all available vehicles across multiple providers. Regulators may increase access to mobility services by requiring a provider to publish a public GBFS feed.

Based on the above, support for or requiring public GBFS feeds seems in keeping with the OMF's principles. I don't think that precludes differing QOS levels between the two if that's the issue. Maybe that could be clarified in the MDS documentation. QOS is not defined under GBFS, however, if consumers like @jiffyclub who presumably are not abusing the service are experiencing QOS issues due to rate limiting, isn't that an indication that the rate limit is inadequate?

GFBS has always been intended as consumer facing, both to support aggregator apps as well as to provide a level of public transparency when it comes to services that are permitted to operate in the PROW. That's not changing with GBFS-Private. While we have heard from some municipalities that they would like to have additional regulatory tools, the focus of GBFS-Private remains traveler information. There should be little additional overlap with the Vehicles endpoint beyond a stable vehicle ID. More on that in this document.

[schnuerle]

We can discuss this in person at tomorrow's working group meeting.

[dirkdk]

As said on the call as a result of the discussion, language to highlight that if a Provider has both Vehicles and GBFS, that the Vehicles endpoint should be considered source of truth regarding compliance checks would be in line with Spin's desire to allow Providers flexibility on QoS for GBFS.

[schnuerle]

Can someone create a PR to clarify this? Or at least say here what they are proposing, and I can make the PR? We need it in the next 2-3 weeks to make it into the 1.2.0 release.

[dirkdk]

Sorry I was on PTO @schnuerle, I'll get on it

[schnuerle]

Would need to have a PR for this in the next week or so to have time to review and get into 1.2.0.

If someone can put a draft of the language they would like to see in the /vehicles endpoint area, I can add it to the /vehicles beta PR #665. I did add language in the PR already that says /status_changes is the long term source of truth, so adding something there about GBFS vs /vehicles should make sense.

[schnuerle]

@dirkdk and everyone, I added this sentence:

If a provider is using both /vehicles and GBFS endpoints, the /vehicles endpoint should be considered source of truth regarding an agency's compliance checks.

In the third opening paragraph here where it discusses GBFS and compliance.

Please review and give feedback ASAP as this PR will be merged soon.

[schnuerle]

Closed with #665