Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify num_bikes_available and num_docks_available definitions #195

Merged
merged 7 commits into from
Jan 27, 2020

Conversation

heidiguenin
Copy link
Contributor

Addressing issue #94.

I've updated the language for num_bikes_available and num_docks_available. Does this create enough clarity?

Addressing issue #94
@heidiguenin heidiguenin changed the title Update gbfs.md Clarify num_bikes_available and num_docks_available definitions Nov 22, 2019
@mplsmitch
Copy link
Collaborator

@heidiguenin I would say this is backwards or unnecessary. If a station contains X bikes and is_renting is false (0) then num_bikes_available would be zero and num_bikes_disabled would be X. Same would apply to docks if is_returning were false

@heidiguenin
Copy link
Contributor Author

@mplsmitch Did you have the chance to look through the conversation over at #94 again? This is the solution that was agreed upon after quite a bit of back and forth.

@mplsmitch
Copy link
Collaborator

@heidiguenin you're correct- disregard my previous comment

@kanagy
Copy link

kanagy commented Nov 24, 2019

While you're here, can you change num_docks_available to be optional? That would allow better handling of virtual stations. Comment could say: Required, except for stations that have unlimited docking capacity (e.g. virtual stations). I found at least one feed that does not set num_docks_available because of this.

@heidiguenin
Copy link
Contributor Author

Updated based on @kanagy's comment.

@heidiguenin
Copy link
Contributor Author

@kanagy Thinking on this more, shouldn't num_docks_available then be Conditionally required? Am I understanding your use cases correctly?

@madupras
Copy link
Contributor

madupras commented Dec 3, 2019

+1 from PBSC

Changed to conditionally required to reflect feedback about virtual stations
@heidiguenin
Copy link
Contributor Author

I hereby call a vote on this proposal. Voting will be open for 7 full days, until 11:59PM UTC on December 11th.

Please vote for or against the proposal, and include the organization for which you are voting in your comment.

@heidiguenin
Copy link
Contributor Author

@maduprasPBSC @kanagy I have updated the proposal and opened the vote. Let me know if that works for you!

@madupras
Copy link
Contributor

madupras commented Dec 4, 2019

@maduprasPBSC @kanagy I have updated the proposal and opened the vote. Let me know if that works for you!

Still works for us. Thanks for the update

@evansiroky
Copy link
Contributor

+1 from IBI Group

@kanagy
Copy link

kanagy commented Dec 5, 2019

+1 from Google Maps. We've noticed that some systems with virtual stations already treat num_docks_available as optional.

@kanagy
Copy link

kanagy commented Dec 5, 2019

@kanagy Thinking on this more, shouldn't num_docks_available then be Conditionally required? Am I understanding your use cases correctly?

Yes, sorry for the late reply. Thanks for updating.

@gcamp
Copy link

gcamp commented Dec 5, 2019

+1 from Transit

@charlesjump
Copy link

+1 JUMP

@mdwestervelt
Copy link

  • 1 Bird

@heidiguenin
Copy link
Contributor Author

Voting has closed and this changed has been passed. Six votes were in favor:

PBSC (Vendor / GBFS producer)
IBI Group (Developer of OpenTripPlanner, GBFS consumer)
Google Maps 9GBFS consumer)
Transit App (GBFS consumer)
JUMP (GBFS producer)
Bird (GBFS producer)

There were no votes against or neutral votes.

@MobilityData is refining how we'll implement the versioning scheme (#188). We'll merge this once we arrive at a sensible release process (see #163).

@jcn
Copy link
Contributor

jcn commented Dec 10, 2019

Just for clarification @mdwestervelt, was that a vote for or against from Bird? (I see that you had typed "-1 Bird" and I wasn't sure if that was a negative vote or if that was intended to be markdown formatting).

@mdwestervelt
Copy link

mdwestervelt commented Dec 11, 2019 via email

@antrim antrim added the v2.0 Candidate change for GBFS 2.0 (Major release) label Jan 3, 2020
add back in the description that was removed
Eliminate new spaces that were showing up in the diff
@antrim antrim merged commit 643d735 into master Jan 27, 2020
@antrim antrim deleted the heidiguenin-patch-1 branch January 27, 2020 00:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gbfs.md v2.0 Candidate change for GBFS 2.0 (Major release) Vote Passed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet