Proposal: Clarify use cases between MDS Vehicles and GBFS

dirkdk commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.