-
Notifications
You must be signed in to change notification settings - Fork 232
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
Add GBFS Feed Url to providers.csv #205
Add GBFS Feed Url to providers.csv #205
Conversation
* 0.2.1: (61 commits) updating release notes for 0.2.x fix for required properties in generated schema add WIND as a dockless mobility provider (openmobilityfoundation#185) add Spin as a dockless mobility provider (openmobilityfoundation#184) Reverts PR openmobilityfoundation#146, moving Timestamp change into future release (openmobilityfoundation#180) wheels (openmobilityfoundation#177) adding info about mailing list. (openmobilityfoundation#175) Adding Release guidelines (openmobilityfoundation#147) Update providers.csv (openmobilityfoundation#174) Add `next` link requirement (openmobilityfoundation#166) Add OAauth client_credentials auth guidelines section update JUMP provider URL (openmobilityfoundation#164) allowing null for links.next (openmobilityfoundation#162) Agency vs Provider Clarification. [openmobilityfoundation#148] (openmobilityfoundation#150) Add LADOT Guidelines for the Handling of MSP Data (openmobilityfoundation#154) allowing for null links properties Suggestion: Add Clarification to Propulsion Types fix versions remove oneOf when required is being added regenerate the schemas ...
From the README > All MDS compatible `provider` APIs must expose a public [GBFS](https://github.com/NABSA/gbfs) feed as well. As part of being MDS compliant providers MUST provide this information and make it available to the public. Making GBFS URLs available to the public encourages researchers and developers to be able to access this data and use it to improve transit services for members of the public Currently there is no way to discover MDS provider URLs to ensure compatibility and make this information available to the public. For today, the best way to do this is to add it to the `providers.csv` and have providers put the URL there as part of their fulfillment of the MDS specification This feels like it should be added to the 0.2.1 release tag rather than waiting for the 0.3.0 release as it is a current requirement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like a good change, agreed that there isn't really a better place to put it now and this file makes sense.
A 0.2.1 release might make sense, but I don't know that it would be any faster than 0.3.0 - we'd want to give each provider the chance to fill this in, for example, instead of releasing a partial registry.
I think at bare minimum you'll want to add a comma to the rest of the providers who have not yet provided their GBFS API URL. |
@hunterowens you raise a good point but I actually think GBFS has indicated what the solution to this is. Providers should provide a single discovery endpoint from which all of their feeds can be accessed.
See: GBFS Let me know if it would be helpful to amend the provider |
@asadowns yeah, let's amend the realtime data section in provider to add that you should have the single entrypoint inside |
@hunterowens I've amended the Realtime data section. Let me know if there's an additional tweaks you'd like. |
Thanks @asadowns. Merging! |
Add GBFS API url to providers.csv
From the README
Currently there is no way to discover MDS provider URLs to ensure compatibility and make this information
available to the public.
As part of being MDS compliant providers MUST provide this information and make it available to the public.
For today, the best way to do this is to add it to the
providers.csv
and have providers put the URL thereas part of their fulfillment of the MDS specification
This feels like it should be added to the 0.2.1 release tag rather than waiting for the 0.3.0 release as
it is a current requirement