Add pricing plans to vehicle types #335
Conversation
Adds pricing_plans and default_pricng_plan to vehicle types
gbfs.md
Outdated
| @@ -395,7 +395,8 @@ Field Name | REQUIRED | Type | Defines | |||
| \- `propulsion_type` | Yes | Enum | The primary propulsion type of the vehicle. <br /><br />Current valid values are:<br /><ul><li>`human` _(Pedal or foot propulsion)_</li><li>`electric_assist` _(Provides power only alongside human propulsion)_</li><li>`electric` _(Contains throttle mode with a battery-powered motor)_</li><li>`combustion` _(Contains throttle mode with a gas engine-powered motor)_</li></ul> This field was inspired by, but differs from the propulsion types field described in the [Open Mobility Foundation Mobility Data Specification](https://github.com/openmobilityfoundation/mobility-data-specification/blob/master/provider/README.md#propulsion-types). | |||
| \- `max_range_meters` | Conditionally REQUIRED | Non-negative float | If the vehicle has a motor (as indicated by having a value other than `human` in the `propulsion_type` field), this field is REQUIRED. This represents the furthest distance in meters that the vehicle can travel without recharging or refueling when it has the maximum amount of energy potential (for example, a full battery or full tank of gas). | |||
| \- `name` | OPTIONAL | String | The public name of this vehicle type. | |||
|
|
|||
| \- `default_pricing_plan`| Conditionally REQUIRED | ID | REQUIRED if `system_pricing_plans` and `vehicle_types.json` are defined. A `plan_id` as defined in `system_pricing_plans.json` that identifies a default pricing plan for this vehicle to be used by trip planning applications for purposes of calculating the cost of a single trip using this vehicle type. This default pricing plan is superseded by `pricing_plan_id` when it is defined in `free_bike_status.json`. | |||
| \- `pricing_plans` | OPTIONAL | Array | Array of all pricing plan IDs as defined in `system_pricing_plans.json` that are applied to this vehicle type. <br /><br />This array SHOULD be published when there are multiple pricing plans defined in `system_prcing_plans.json` that apply to a single vehicle type. | |||
There was a problem hiding this comment.
Typo, should by system_pricing_plans.json
heidiguenin
added
proposal:nonbreaking
v2.3
|
I hereby call a vote on this proposal. Voting will be open for 10 full calendar days until 11:59PM UTC on September 1st, 2021. 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. |
|
Google Maps supports this and would like to implement it for docked systems where currently using free_bike_status is unnecessary. It would be nice to have some guidance in the spec to prefer setting default_pricing_plan first for all producers and then override it in free_bike_status if needed. Nit: For consistency with other fields, would it make sense to rename to |
|
Entur supports this proposal and will implement it in our aggregation service |
|
Ito World supports this proposal. |
|
Nextbike supports this proposal, though we will probably keep publishing |
|
Dott approves this proposal, however I would argue that |
|
IBI Group supports this proposal, although we agree with @kanagy's suggestion to rename |
|
Spin supports this proposal. We likely will not immediately implement it. |
|
Superpedestrian supports this proposal. We don't currently have plans to add this to |
|
Voting is now closed, and it passes! Votes in favour: There we no votes against. Regarding @kanagy's and @evansiroky's comments: we will make those semantic changes when we merge into a v2.3-RC. |
Updates field name default_pricing_plan to default_pricing_plan_id, clarifies definition giving preference to defining default_pricing_plan_id
Add V2.3-RC label and clarify use of pricing_plan_id
…vehicle-pricing
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.
When
system_pricing_plans.jsonwas extended in v2.2 thepricing_plan_idfield was added tofree_bike_status.jsonto associate pricing plans with vehicles. The thinking was that doing this at the individual vehicle level would allow dynamic pricing based on the vehicle's location.This poses a challenge for station based systems in that they would be forced to publish the optional
free_bike_statusend point in order to surface pricing information. It also limits vehicles to a single pricing plan.What is the proposal?
This proposal adds a
pricing_plansarray tovehicle_types.jsonthat contains the plan IDs of all applicable pricing plans for that vehicle type. It also adds a field that defines a default pricing plan to be used by trip planners in calculating the cost of the a single trip.The ability to define pricing plans at the individual vehicle level is preserved, which would allow pricing to be set based on vehicle location or other factors. Any pricing plan assigned to individual vehicles in
free_bike_status.jsonsupersedes the default plan defined invehicle_types.json.Additional discussion of this can be found in issue #318
Is this a breaking change?
Which files are affected by this change?
gbfs.md: