adding reservation time info to vehicle_types #257
Conversation
|
This is useful and something we'd also like to see. I am not sure if this is modelled in the best way, since your solution implies that reservation time is based on the vehicle type. While this would work on our use case, I'm not sure if there're systems where reservation time does not depend on the vehicle type but rather a booked tariff. |
|
In #255, there is a proposed extension to |
|
@Empty2k12 Good point, the option for reservation might depend on the used tariff, too. And I think it's not an either or but rather that both dependencies (bike_type & tariff) should be possible. Since PR #255 is in discussion too I would rather wait what the outcome is and do not open another PR on this right now. But I will add a hint in the description that reservation options might depend on the used tariff. |
|
I hereby call a vote on this proposal. Voting will be open for 7 full calendar days until 11:59PM UTC on Friday, November 20th. |
|
+1 from PBSC |
gbfs.md
Outdated
| @@ -276,6 +276,7 @@ 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. | |||
| \- `reservation_time_minutes` | Optional | Non-negative integer | Time in minutes the vehicle can be reserved before rental is started. If set to values >0 the vehicle can be reserved for the specified amount of time. The vehicle remains locked until a rental is started. During this time the vehicle can not be reserved or rented by other users. If the reservation time is elapsed and no rental has been started, the reservation is terminated automatically and the vehicle is available for other users. If set to 0 then the vehicle can not be reserved. Note that a given reservation_time might only be one prerequisite and that in addition only specific tariffs might allow a reservation. | |||
There was a problem hiding this comment.
There might be a typo here for "reservation_time" in "Note that a given reservation_time" (should be "reservation_time_minutes").
There was a problem hiding this comment.
Thanks for pointing out. I corrected the typo.
|
+1 from RMV |
|
The vote has closed with 2 votes in favor. Since 3 are needed in addition to the proposer’s, it does not pass. As per the governance, this does not mean the PR must be abandoned. We'd like to better understand your needs and how to address them going forward. @matt-wirtz & @sfaubert1 - could you please take another look at the proposed reservations model in #255? Then, could you email me at josee@mobilitydata.org to set up a time to chat so that we can work together towards a solution that brings these two proposals together? |
|
@josee-sabourin Looks like the new change process was applied here when stating that three votes in favor are needed. The vote on the PR was called before the change process was modified. Why wasn't the old process applied? |
|
Hi @matt-wirtz - just wanted to clarify. The earlier change process also did call for three votes in favor - with at least one consumer and at least one producer. It was not clear on whether the proposer's vote counted in those three, so that was clarified to make it more in line with GTFS during the recent move from pilot to official governance. But three votes have always been required. |
|
Hi @josee-sabourin. Thanks for the clarification. When calling the vote I think I was looking here to see how the process looks like: |
|
Hi @matt-wirtz, before the new change process PR we had been testing out a pilot governance (#163) which outlined the need for 3 votes in this comment. Hope that helps! I'm happy to chat over e-mail if things are still fuzzy! |
|
@josee-sabourin Ah, a pilot governance with a pilot change process in it I assume. Really confusing to me. Looks like I missed that one out. Thanks for the Info. |
|
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. |
|
@matt-wirtz @Empty2k12 We're planning to revisit this and try to pass something. I'm working an a needs assessment and wondering if you know of any examples where there are dependencies related to reservation of vehicles based on tariff or other factors as discussed above. |
There a bike sharing systems which offer a reservation option. Users can reserve a bike upfront for a specific amount of time. The bike stays locked until a rent is started. If a rent is not started within the maximum reservation time the reservation is released. During the reservation time the bike can't be reserved nor rented by other users.
As a consumer we currently have to hard code the information if a vehicle can be reserved or not. So far the bike sharing systems we integrated differentiate the reservation option on the level of bike types not the individual bikes. So I think the information makes most sense on the bike type level.