Closed tedder closed 5 years ago
While practical for those interested in analyzing trips, the purpose of GBFS feed is to better serve customers by allowing a variety of apps and transportation systems to get the present state of bicycle sharing systems.
See the introduction:
This specification has been designed with the following concepts in mind:
- Provide the status of the system at this moment
- Do not provide information whose primary purpose is historical
Historical data, including station details and ride data is to be provided by a more compact specification designed specifically for such archival purposes. The data in the specification contained in this document is intended for consumption by clients intending to provide real-time (or semi-real-time) transit advice and is designed as such.
If you're interested in looking for data you can check out (and participate) in a list of data I curate as part of my PhD research: https://bikeshare-research.org/
There's also an API so you can see all the data links provided - just search for the ltype values of 'data' in the following query: https://bikeshare-research.org/api/v1/categories/links/fields/ltype,linkurl
Hey @tedder thanks for your inquiry, and thank you @serialc for you helpful description. To further the goals of NABSA's 2019 GBFS upgrade, I've included serialc's BSS research in micromobility-tools-and resources. serialc if you have any requests or suggests regarding this inclusion please let me know.
Unless either of you have any objections I'd like to close this issue.
There's a lot of 'pre-trip' data (station availability, etc) but nothing about the public trip data. These are provided in a variety of formats, but it'd be nice to have them included in the GBFS and
systems.csv
so they are discoverable. Perhaps it's more complicated than the normalname
/url
in agbfs.json
(for instance, daily/weekly files, zip/csv/json, anonymized), but starting to normalize/enumerate these would be helpful.Some examples: