mobility-data-specification
mobility-data-specification copied to clipboard
openmobilityfoundation
Open Fare Information
Is your feature request related to a problem? Please describe.
Currently, there are two fields in MDS to cover the cost of trips, which are optional. They are actual_cost and standard_cost inside of trips` on the provider side.
Recently, a number of Shared Scooter companies raised their prices. This should be acknowledge by regulatory agencies and perhaps incorporate in certain jurisdictions into an approval process. (I'm unsure if any RFP / RFQ / Permit process around shared scooters required notification to the City around pricing info, but for example, Chicago's contract with Lyft/Motivate requires notification around pricing changes for Divvy).
More information for both the public and agencies around pricing is need to analyze the impact of these changes. Additionally, there needs to be mechanisms to make sure that various regulatory requirements around price / access / equity are actually being met.
One additional complexity to this is the frequent AB testing of fares by operators, and the possibility that discounts, AB tests, promotions, etc make fare discover-ability hard.
Describe the solution you'd like
-
Pubic accessible pricing information via open API. This is probably best done by requiring GBFS's System Pricing Plans as part of the Realtime data section. Changes are coming to GBFS to include more robust pricing options. This should be required by MDS and hopefully there should be a way in
systems.csvor similar of daylighting pricing info for consumption by third parties. -
The ability to get some sort of historical view on prices for DOT's etc to view. This could be done by either
- making the cost fields in trips mandatory, so that you could deduce the pricing scheme over time by diving by the trip distance / trip time delta
- some sort of new endpoint, such as
/pricing, that contained the pricing scheme and start / end times for it.
- For regulatory regimes where pricing must be approved by the agency, an workflow in agency / city services / policy that allows fare increase/decreases to be submitted / approved /denied.
I'm not wedded to this set of ideas, so if somebody sees a better architecture, please feel free to chime in on this issue.
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).
- Maybe!
Provider or agency
For which API is this feature being requested:
- both
Describe alternatives you've considered
One way to implement this would be to require GBFS System Pricing Plans.
Another possible implementation would be for each company to submit pricing info to individual cities for them to publish in their regulations, which makes the information hard for residents to find and isn't standardized.
Additional context
Add any other context or screenshots about the feature request here.
@hunterowens Does the Chicago use-case require an API and not just regular mail communication from the provider to the city ?
@HenriJ the current Chicago approach doesn't use an API, it requires a communication via email IIRC but tagging @nicklucius for more information.
However, with more and more operators going to a dynamic pricing model, the email communications don't scale. I'd like to see it to be possible for 1) companies to be able to utilize dynamic pricing but 2) regulators to be able to prevent gouging, biased pricing, etc. An API would allow said control to exist.
@hunterowens @HenriJ We've had a variety of data collection methods in place--most recently MDS Provider for the recent scooter pilot. And to answer the question about CSVs, yes we have used CSV transfers for dockless bikes when we had them in 2018 and as well as TNP which I think was set up around 2016.
I’m not sure if/how cities are exerting regulatory authority over pricing, and it seems premature to start with an API change before we have clarity on the policies/analysis the changes would support. Would welcome input from cities/regulators on what kinds of pricing policies they have or are planning. If it makes sense, we could work backwards from there to figure out how MDS could best support.
I like this idea and agree that documenting the use-cases is a prerequisite to designing APIs. I would also like to hear from multiple mobility providers about how this could work in a regime of highly dynamic pricing. (Just my $0.02.)
I think Policy can cover this a bit now, but really it's in the hands of GBFS at this point, or outside the scope of what agencies are using MDS for now.
