-
Notifications
You must be signed in to change notification settings - Fork 299
Fare capping #745
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fare capping #745
Conversation
I represent OpenStreet, the operator of HELLO CYCLING, one of the largest bikeshare systems in Japan. Our service applies a fare cap every 12 hours, which is an important aspect of our pricing model for ensuring affordability and user satisfaction. However, the current GBFS specification does not support representing time-based fare caps like ours. We strongly support this proposed change, as it would allow us to accurately publish our fare structure through GBFS. This, in turn, would enable third-party apps such as route planners and map services to display our pricing correctly, improving user experience and transparency across the ecosystem. |
Thank you to @keijipoon and @mplsmitch who contributed to this proposal in #507 🙏 I hereby call a vote on this proposal. Voting will be open for 10 full calendar days until 11:59PM UTC on Monday, April 28. Please vote for or against the proposal, and include the organization for which you are voting in your comment. Governance on the spec change process can be found here. |
+1 from OpenStreet |
Two additional votes, including at least one vote from a consumer, are required for the Price capping feature to be included in the next Release Candidate. @keijipoon, please feel free to invite OpenStreet data consumers to vote. Tagging consumers with recent activity on the repository for visibility: @AntoineAugusti (transport.data.gouv.fr), @cmonagle (Transit app), @futuretap (WhereTo?), @Lefois (Raumobil), @leonardehrenfried (OpenTripPlanner), @matt-wirtz (Hacon), @rotger711 (MobiData BW), @sven4all (dashboarddeelmobiliteit.nl), @testower (ENTUR), @tdelmas (Fluctuo), @ue71603 (sharedmobility.ch) Thanks! |
+1 from Where To? / FutureTap. I passed on this vote at first because we currently don’t display fares. Nevertheless the proposal sounds useful. |
+1 from Fluctuo (we will implement it) |
Voting on this PR closes in 2 calendar days. Please vote for or against the proposal, and include the organization for which you are voting in your comment. Please note if you can commit to implementing the proposal. Thanks! |
Thanks for your message. |
@keijipoon The official closing time for this vote is 11:59PM UTC on Thursday, May 1. If there are no votes against by then, the vote will be adopted. Indeed, it has three votes in favor, including one from a consumer and one from a producer (see governance). Thanks! |
This vote has now closed, and it passes! Votes in favor:
There were no votes against. This change will be part of the next MINOR Release Candidate, planned this month, as per the version release cycle in the governance. Thank you all for your involvement in the GBFS spec 🙏 |
* Add field city in station_information (#704) * Prepare to merge 'City in station_information' into master * Future availability by vehicle (#726) * New vehicle_availability endpoint * Update description to match id in vehicle_status * Add pricing_plan_id and vehicle_equipment * Make station_id conditionnally required * Make station_id REQUIRED * Add fare capping definition and example (#745) * Prepare v3.1-RC2 release --------- Co-authored-by: Holger Bruch <holger.bruch@systect.de>
What problem does your proposal solve?
Fixes #507
Some operators have fare caps that were not possible to represent in GBFS (e.g. Hello Cycling in Japan).
What is the proposal?
Add an optional object in system_pricing_plans.json to represent fare cap:
The fare is capped at 15.00 CAD per 12-hour period (720 minutes).
Is this a breaking change?
Which files are affected by this change?
system_pricing_plans.json