Skip to content

Conversation

richfab
Copy link
Contributor

@richfab richfab commented Apr 10, 2025

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:

"fare_capping": {
  "duration": 720,
  "price": 15.00
}

The fare is capped at 15.00 CAD per 12-hour period (720 minutes).

Is this a breaking change?

  • Yes
  • No
  • Unsure

Which files are affected by this change?

system_pricing_plans.json

@richfab richfab added the v3.1-RC2 Candidate change for v3.1 (minor release) - 2nd pass label Apr 10, 2025
@keijipoon
Copy link
Contributor

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.

@richfab
Copy link
Contributor Author

richfab commented Apr 17, 2025

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.
Please note if you can commit to implementing the proposal.

Governance on the spec change process can be found here.

@keijipoon
Copy link
Contributor

+1 from OpenStreet

@richfab
Copy link
Contributor Author

richfab commented Apr 28, 2025

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!

@futuretap
Copy link
Contributor

+1 from Where To? / FutureTap. I passed on this vote at first because we currently don’t display fares. Nevertheless the proposal sounds useful.

@tdelmas
Copy link
Contributor

tdelmas commented Apr 29, 2025

+1 from Fluctuo (we will implement it)

@richfab
Copy link
Contributor Author

richfab commented Apr 29, 2025

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!

@keijipoon
Copy link
Contributor

@richfab

Thanks for your message.
I know I am late in calling for the vote, but I would like to once again encourage people I know and others to vote. I know there are only two days left, but when is the official closing time of the VOTE?

@richfab
Copy link
Contributor Author

richfab commented Apr 29, 2025

@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!

@richfab
Copy link
Contributor Author

richfab commented May 2, 2025

This vote has now closed, and it passes!

Votes in favor:

  • OpenStreet / Hello Cycling (producer)
  • Where To? / FutureTap (consumer)
  • Fluctuo (consumer)

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 🙏

@richfab richfab changed the base branch from master to release/v3.1-RC2 May 27, 2025 16:15
@richfab richfab merged commit b565e64 into release/v3.1-RC2 May 27, 2025
1 check passed
@richfab richfab deleted the fare-capping branch May 27, 2025 16:15
@richfab richfab mentioned this pull request May 27, 2025
richfab added a commit that referenced this pull request May 28, 2025
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v3.1-RC2 Candidate change for v3.1 (minor release) - 2nd pass Vote Passed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Could you add "upper_limit" field to system_pricing_plans.json ?
4 participants