Pricing Plans: replaces integer with float in interval

[cmonagle]

Note: If your PR is to add, remove, or correct a system in systems.csv, please delete this template.

If you are new to the specification, please introduce yourself (name and organization/link to GBFS). It’s helpful to know who we're chatting with!

I'm Cameron with Transit app. We consume (a lot!) of GBFS.

What problem does your proposal solve? Please begin with the relevant issue number. If there is no existing issue, please also describe alternative solutions you have considered.

Currently, the intervals in pricing_plans don't allow floats. This means it is impossible to represent a system that, for example, bills a fixed amount for each mile (1.7km) travelled, but does not prorate by kilometre.

For example:

• The vehicle costs $2 per mile. The rider travels 10.75 miles.
• Currently, the producer would define a $1.24274238 "rate" with an interval of 1.
• Since the rider traveled 17.300448 km, the price would be calculated as $21.13. (17 kilometer-long intervals * $1.24274238)
• In reality, the price would be $20 even.

Another example would be pricing plans that prorate per meter or 100 meter, not by full km.

What is the proposal?

For per minute and per km pricing plans, the interval should allow float values.

Is this a breaking change?

• Yes
• No
• Unsure

Which files are affected by this change?

[josee-sabourin]

I hereby call a vote on this proposal. Voting will be open for 10 full calendar days until 11:59PM UTC on Friday, October 27th.
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.

[futuretap]

+1 from FutureTap / Where To? – btw, I don’t think this is a breaking change. In JSON, every int can be parsed as a float.

[richfab]

Thank you Ortwin (@futuretap) for this comment.
Question: Isn't it a breaking change given that consumers of v2.3 feeds and below expected integers, but would now start receiving floats instead?

[futuretap]

@richfab you’re right, it’s breaking for consumers, non-breaking for producers.

[cmonagle]

I forget if the advocate is expected to vote or not, but if so: Transit +1

[richfab]

Thank you @cmonagle. Anyone can vote.

UPDATE:
According to the governance, the vote from Transit would not count in this quorum as Transit is the Advocate.

A vote passes if there is unanimous consensus with at least 3 votes in favor.

• At least one of these votes MUST be from a producer and at least one MUST be from a consumer.
• The producer and consumer votes MUST come from stakeholders other than The Advocate.
• MobilityData serves as facilitator but does not vote on proposed changes.

Sorry about the confusion.

[josee-sabourin]

Tagging for more visibility: @viestat @ArashMansouri @AntoineAugusti @ezmckinn @fbouchPBSC @Carl-NM @bdferris-v2 @kulovan @gajayraghav @hynick4 @PierrickP @tdelmas @tobsesHub @tstrubel @HannesOlszewski @simonsolnes @testower

[PierrickP]

fluctuo: +1

---

+1 because it's kind of blocking for you if you want to display on miles instead of km 😸
If we want to go really further, we could keep the Integer but instead of the value in the currency, pass the value as "cents".
In many programming languages, handling floats can lead to rounding errors (0.2+0.1 = 0.30000000000000004 in js https://0.30000000000000004.com/).

Some sources:

• https://news.ycombinator.com/item?id=20575702
• https://stripe.com/docs/currencies#zero-decimal
• https://blog.agentrisk.com/you-better-work-in-cents-not-dollars-2edb52cdf308

[testower]

+1 from Entur,

As for quorum, given that there are at least 1 vote each from a producer and a consumer, the third vote can come from the Advocate

[josee-sabourin]

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.

[ezmckinn]

+1, Superpedestrian supports this. We use time-based pricing, so this specific use case doesn't apply to us right now, and we therefore are unlikely to implement it. But it's a fine change to the standard to support different implementations.

[josee-sabourin]

This vote has now closed, and it passes!

Votes in favor:
Whereto.app (consumer)
fluctuo (consumer)
Entur (consumer)
Superpedestrian (producer)


There were no votes against.

This change will be added to v3.0-RC2, which will be released in the coming weeks.

[richfab]

LGTM

[richfab]

As of v3.0-RC2

[richfab]

Hi @cmonagle,
We have not found a producer interested in publishing a pricing plan in miles at the moment. If you don't mind, this change will be delayed to the next version to allow v3.0 to become the official version.
Thank you for your continued involvement in the GBFS spec. 🙏
Fabien