Clarification of vehicle type capacity fields

[mplsmitch]

This change is based on discussion in #251 . vehicle_capacity becomes vehicle_type_area_capacity and vehicle_type_capacity becomes vehicle_type_dock_capacity. Also corrects an error changing is_valet_station from ID to Boolean.

[mplsmitch]

I hereby call a vote on this proposal.

Voting will be open for 7 full calendar days until 11:59PM UTC on October 13th, 2020.

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.

[sfaubert1]

+1 from PBSC

[evansiroky]

Hello, we have some concerns about this PR regarding how it interacts with the changes in #261 and would like some further clarification.

It seems that there is a field to show the current availability of docks by vehicle type. However, with the addition of the field station_information#vehicle_type_area_capacity it seems that there is no corresponding additional entry in station_status such as station_status#vehicle_type_area_spots_available like there is with the station_status#vehicle_type_docks_available. It seems like this should be added here in order for consumers to be able to figure out how many station area spots are available for a particular vehicle type if there is a fixed capacity. And with the changes in #261 (our apologies for not commenting there before voting), there is no way to distinguish whether a vehicle is parked within a dock at the station or within a station area at the station, so we couldn't use information from that file to indirectly calculate availability for either the docks or the station area.

Also, while discussing this we thought of two other clarifying items that might be useful to be added to the spec, but not necessarily via this PR.

1. It would be good to have the docs for the field station_information#vehicle_type_area_capacity or other fields related to station areas explicitly state that the applicable capacity of this station area overrides all applicable geofenced zones with an applicable ride_allowed restriction that covers a part or the whole of the station area.
2. It would be good to get clarification about whether a vehicle is at a dock or at a station area at the station. If it's at a dock, maybe a dock code (human-readable identifier) could be provided. If a vehicle is in the station area, maybe it would be good to include GPS coordinates in addition to the station ID to help users find the vehicle.

[mplsmitch]

@evansiroky Just to be clear, this PR doesn't add any additional fields or change their definitions, it only renames fields introduced in #136 .

I agree there is a gap in that there is no equivalent to station_status#vehicle_types_docks_available for station areas. Since this proposal has already been voted on, I'd like to handle that in a separate PR.

And with the changes in #261 (our apologies for not commenting there before voting), there is no way to distinguish whether a vehicle is parked within a dock at the station or within a station area at the station, so we couldn't use information from that file to indirectly calculate availability for either the docks or the station area.

I think this can be this can be done by amending the definitions of station_id and lat/lon in free_bike_status so that station_id is required when vehicles are docked and lat/lon is required for when vehicles are not docked. If station_id is provided, the vehicle is docked, if lat/lon is provided the vehicle is free floating. This could also be part of the PR for the issue above.

It would be good to have the docs for the field station_information#vehicle_type_area_capacity or other fields related to station areas explicitly state that the applicable capacity of this station area overrides all applicable geofenced zones with an applicable ride_allowed restriction that covers a part or the whole of the station area.

I'm not sure I understand this comment. Why would station.information#station_area be defined within a geofenced zone where rides are prohibited from starting or ending? If a station_area were inside an geofence where ride_allowed is FALSE then the number of vehicles available and number of parking spaces available should both be zero if the operator were following the restrictions set in the geofence.

[evansiroky]

@evansiroky Just to be clear, this PR doesn't add any additional fields or change their definitions, it only renames fields introduced in #136 .

...and also #219.

I agree there is a gap in that there is no equivalent to station_status#vehicle_types_docks_available for station areas. Since this proposal has already been voted on, I'd like to handle that in a separate PR.

Ok, I see that now. We can go ahead and +1 this for now with the expectation that this will be resolved in a future PR.

And with the changes in #261 (our apologies for not commenting there before voting), there is no way to distinguish whether a vehicle is parked within a dock at the station or within a station area at the station, so we couldn't use information from that file to indirectly calculate availability for either the docks or the station area.

I think this can be this can be done by amending the definitions of station_id and lat/lon in free_bike_status so that station_id is required when vehicles are docked and lat/lon is required for when vehicles are not docked. If station_id is provided, the vehicle is docked, if lat/lon is provided the vehicle is free floating. This could also be part of the PR for the issue above.

This seems to match the existing state of the definitions in #261. It seems like additional info is needed to communicate that a vehicle is parked in a station area.

It would be good to have the docs for the field station_information#vehicle_type_area_capacity or other fields related to station areas explicitly state that the applicable capacity of this station area overrides all applicable geofenced zones with an applicable ride_allowed restriction that covers a part or the whole of the station area.

I'm not sure I understand this comment. Why would station.information#station_area be defined within a geofenced zone where rides are prohibited from starting or ending? If a station_area were inside an geofence where ride_allowed is FALSE then the number of vehicles available and number of parking spaces available should both be zero if the operator were following the restrictions set in the geofence.

In here, we're asking for clarity when a geofenced zone and a station area overlap. There could be instances where a provider defines both and there could be ambiguity as to which information should take priority. Consider the case of a geofenced zone having ride_allowed = TRUE and an overlapping station_area that is at capacity and therefore not accepting any more vehicles. Would a user say that "since this geofenced area says I can park here, that means that technically I'm not dropping off my vehicle at this full station area, instead it's just free-floating"? I'm guessing no, but it would be good to have that clarification written into the spec.

[mplsmitch]

The voting has closed.. With only 2 votes in favor the proposal does not pass. We will take up the naming clarifications in again at a later date The correction of is_valet_station from ID to Boolean will be done as a patch that won't require a vote.