You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am working on the project Intermodal Routing Machine for the city of Prague. Currently, I create common data format holding the data of all share mobility providers which should be consume by this routing machine.
What is the issue and why is it an issue?
There are missing important attributes in the pricing plans file or an extra file needs to be created.
I found the share mobility providers who are using different pricing plans valid in chosen day time (morning and night prices may differ) and valid in a week day (special weekend sales) and specials pricing plans.
To solve this problem in general we would need much more attributes to cover all business pricing plans. I would consider creating an extra file describing the services provided by a vehicle. It means if a bike rental company would decide to make specials for weekend users or provide a student sale or a long-time rental sale we can cover it in this service file. This solution would add one or more services to a vehicle and one or more pricing plans to a service.
The reason for creating an extra file and do not add all the attributes to the pricing plans file is keeping separated the business layer and the simple pricing plans. In other words from the point of view of a customer, the customer would be able to choose the service he/she wants to use (I am student, I am a member card holder) but the pricing plans are connected to the each of those services and cannot be impacted by the customer decision. It is possible to implements all the changes into the pricing plans file but it would break its format by a lot.
Is your potential solution a breaking change?
I do not need to implement those changes in the next version of GBFS format. I would like to discuss the suggestions with you, if it is the good way to develop and extend the GBFS if I base my own format on GBSF or if you plan to implement those changes in the future. Or we can consider any other suggestions how to cover the described problems.
Thank you.
Yes
No
Unsure
The text was updated successfully, but these errors were encountered:
Hi there! Thanks for bringing up this issue and welcome to the repository!
The initial proposal to extend system_pricing_plans.json did include fields to allow for plans that varied based on time, day, or month (albeit not to the level of detail you are suggesting). These were removed to simplify the minimum viable proposal. We would love to discuss this need with you in more depth and see how we can add this into the next phases of the pricing extension (or a whole new phase, see other planned phases here).
I encourage you to look at issue #289 which discusses moving to the OSM hours and dates format and see how that format can potentially be used for this issue as well.
We'd love to discuss this with you in more detail! Send us an e-mail at [email protected] and we can set up a time to chat.
This discussion has been automatically marked as stale because it has not had recent activity. It will be closed in 60 days if no further activity occurs. Thank you for your contributions.
Who I am
I am working on the project Intermodal Routing Machine for the city of Prague. Currently, I create common data format holding the data of all share mobility providers which should be consume by this routing machine.
What is the issue and why is it an issue?
There are missing important attributes in the pricing plans file or an extra file needs to be created.
I found the share mobility providers who are using different pricing plans valid in chosen day time (morning and night prices may differ) and valid in a week day (special weekend sales) and specials pricing plans.
Examples:
https://anytimecar.cz/rates.html
https://www.rekola.cz/en/pricing
Potential solutions I have considered.
The simplest possible solution is to add those attributes to the pricing plan file.
start_time_of_period: "Mon-Fri 09:00AM",
end_time_of_period: "Mon-Fri 09:00PM",
pricing_plan_description: "member card holders"
To solve this problem in general we would need much more attributes to cover all business pricing plans. I would consider creating an extra file describing the services provided by a vehicle. It means if a bike rental company would decide to make specials for weekend users or provide a student sale or a long-time rental sale we can cover it in this service file. This solution would add one or more services to a vehicle and one or more pricing plans to a service.
The reason for creating an extra file and do not add all the attributes to the pricing plans file is keeping separated the business layer and the simple pricing plans. In other words from the point of view of a customer, the customer would be able to choose the service he/she wants to use (I am student, I am a member card holder) but the pricing plans are connected to the each of those services and cannot be impacted by the customer decision. It is possible to implements all the changes into the pricing plans file but it would break its format by a lot.
Is your potential solution a breaking change?
I do not need to implement those changes in the next version of GBFS format. I would like to discuss the suggestions with you, if it is the good way to develop and extend the GBFS if I base my own format on GBSF or if you plan to implement those changes in the future. Or we can consider any other suggestions how to cover the described problems.
Thank you.
The text was updated successfully, but these errors were encountered: