Skip to content

Conditionally require fields for MDS Stops #929

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

Open
mschwartzie opened this issue Apr 8, 2025 · 4 comments · May be fixed by #934
Open

Conditionally require fields for MDS Stops #929

mschwartzie opened this issue Apr 8, 2025 · 4 comments · May be fixed by #934
Labels
minor update A change that is minor and should require little discussion, or is a maintenance/readme/typo update. Provider Specific to the Provider API
Milestone

Comments

@mschwartzie
Copy link

Is your feature request related to a problem? Please describe.

In trying to use the stops endpoint to support cities in monitoring SLAs related to docked bikeshare, there are needed/useful fields listed as optional in the spec. In particular:

  1. num_places_available or num_places_disabled are needed in order to understand how many docks are empty and available for use.
  2. devices would be helpful for being able to look back historically in the event of data interruptions. This will also allow for looking at specific vehicles at the station since num_vehicles_available and num_vehicles_disabled do not include a propulsion type in the response so unable to differentiate for example an ebike from a classic pedal bike.

Describe the solution you'd like

Make num_places_available conditionally required, matching the GBFS spec.
Make devices conditionally required.
Optional: make num_places_disabled conditionally required. This field can be derived if num_places_available is already included.

M

Is this a breaking change

  • No, not breaking

Impacted Spec

For which spec is this feature being requested?

  • provider

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

@jiffyclub
Copy link
Contributor

I think this is a good idea! I'd argue that making something conditionally required is a breaking change since it fundamentally changes how people implement the spec.

@schnuerle schnuerle added this to the 2.1.0 milestone Apr 16, 2025
@schnuerle schnuerle added Provider Specific to the Provider API minor update A change that is minor and should require little discussion, or is a maintenance/readme/typo update. labels Apr 16, 2025
@schnuerle schnuerle modified the milestones: 2.1.0, 2.0.2 Apr 16, 2025
@schnuerle
Copy link
Member

@jiffyclub I think it depends on the condition, right? If the condition is 'Stops endpoint is implemented' then yes it's breaking, but if it's more limited and specific, like if 'the city asks for this data as part of operations or via MDS Policy Requirements' then I would not consider that breaking.

Related to this is issue #904.

@schnuerle
Copy link
Member

Thanks for the #934 PR @mschwartzie. I think the conditional requirement you have written looks good and clear:

"Required if [the field is required] as part of contract compliance or service level agreement."

It only affects those that are already requiring it, but makes it clear it should be included in those cases.

@geneorama
Copy link
Collaborator

As written I thought this would be a breaking change, but really I think this is a patch and correcting an oversight. This should have been in the original spec by the business logic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
minor update A change that is minor and should require little discussion, or is a maintenance/readme/typo update. Provider Specific to the Provider API
Projects
None yet
4 participants