Pricing plans per vehicle type

[davidlewis-ito]

What is the issue and why is it an issue?

The extended system_pricing_plan.json introduced in V2.2 represents a great improvement to enabling pricing schemes to be described in a machine readable form. It also enables a pricing "plan" to be applied to a specific vehicle instance via free_bike_status.json. However it seems that it is not possible to apply a pricing scheme to all vehicles of a particular class (which is a common use case).

Please describe some potential solutions you have considered (even if they aren’t related to GBFS).

Adding an optional attribute to vehicle_types defining the "default_pricing_plan_id",

Is your potential solution a breaking change?

• Yes
• No
• Unsure

[mplsmitch]

When system_pricing_plans.json was extended in v2.2 the pricing_plan_id field was added to free_bike_status.json to 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_status end point in order to surface pricing information.

The addition of a default_pricing_plan_id in vehicle_types.json would allow providers to set a default plan for a class of vehicle, which could then be overridden by any plan id published in free_bike_status at the vehicle level. This would preserve the ability to set dynamic pricing based on location.

This idea could also be extended to the station level by adding a field to station_information.json or station_status.json which would allow operators to set different pricing at individual stations but I'm not aware of systems currently doing that.

[madupras]

At PBSC we are currently in the process of implementing the system_pricing_plans.json (version 2.2) in GBFS. In our solution, we don't plan on using the free_bike_status.json and this solution is exactly what we need to be able to link a pricing structure to a vehicle model.

[mplsmitch]

I was planning to move this to a PR this week but in looking at pricing we've found a problem with how this is currently done in free_bike_status.json. The problem is that only one pricing plan can be associated with a vehicle using free_bike_status.json#pricing_plan_id.

Ideally there would be an array that would contain all available pricing plans for the vehicle. This could also be done in vehicle_types.json, adding an array of all available plans for that class of vehicle. In both cases we would need to have a field designating a default pricing plan for use by trip planners as discussed above. The arrays would be optional for systems that only offer a single plan and the default plan could be required of any system where system_pricing_plans.json is defined.

If we used the existing free_bike_status.json#pricing_plan_id as the default for that file I think it's questionable whether or not this could be considered a breaking change. If not, then we could get it into MINOR version more quickly.

Thoughts anyone?

[kanagy]

Can you ellaborate for why a vehicle would have different pricing plans and how planning apps should deal with that?

[richtaylor-ito]

@kanagy a scheme might have, for example, "light use" and "heavy use" plans which have different one-off fees and per-km/per-minute rates. Both of these plans could be published, and then the planning app could either show both as options, or even compute which is optimal for the end user's journey.

[mplsmitch]

In bike sharing it's still common practice to have multiple pricing plans for the same vehicle type. They typically offer a 24hr or 7 day pass for example. We're not modeling anything beyond a single trip fare now but in the future I expect we will. Unfortunately things seems to be getting more complicated over time as you can see in how Chicago is pricing their e-bikes here: https://www.divvybikes.com/pricing/ebikes

My thinking was that we would use the default plan fields to indicate which should be used for trip planning purposes - if there are other plans listed in the arrays maybe you could give them options. The hard part is clearly defining what constitutes a default plan.

[kanagy]

Understood. I forgot that in MVP we decided to only include the typical pricing plan, with the intention of extending that later (which is happening here).

[mplsmitch]

This issue has been moved to PR #335 - I'm closing this issue. Please continue the conversation on the PR