-
Notifications
You must be signed in to change notification settings - Fork 287
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
Question: Stability of systems.csv? #28
Comments
Early in the discussions, it was decided that the maintainers of the spec did not want to take on the burden of ensuring the uptime of a global GBFS registry. This has a couple of implications:
With those caveats in mind, the columns names will probably not change now that it's actually starting to get some use, and we will make our best effort to not change the order of the columns either. |
@drewda Any thoughts on maintaining a global GBFS directory? Would the |
I am planning on accessing this programmatically. However, I prefer to use SoBi's API for their network of bike shares. Thus in order to do that this service.csv file needs to have a column parameter that defines who the bikeshare network is - otherwise I have to statically map Sobi networks shares and parse that against this GBFS csv file to weed out the duplicates leaving only a list of none Sobi networks. But...since a network ID does not exist...i must manually and statically compare the Sobi list against the none SoBi GBFS locations. |
@jcn - I am not sure I follow. What is "/networks.json" file? We have unique system_id in every system_information.json, and every SoBi landingpage have proper header in the section. |
Let me explain, the GBFS specifically does not list "Social Bicycles" or "Sobi" anywhere. "Bcycle" includes their name in their URL but not in the systems.csv or in the top level json per bikeshare (ie: system_information.json. Half of the GBFS listed sites are Sobi sites, a handful are Bcycle sites - but there is virtually no way of telling one from the other. In some Sobi json files you will see "socialbicycles" in the domain/url - but in other cases like "Coast Bikes" there is no mention of Sobi/socialbicycles" anywhere thus there is no way for me to decipher that they are in fact a part of the SoBi network. Now, if I go access the specific SoBi API...then yes, I can extract that info. But not everyone has their own API and only rely on the GBFS. And for those that do, there is no way for me to tell if they are part of a larger network or if they are independent. Being able to group by Network provides useful for a variety of coding AND informational uses for users. |
@rolinger Are you specifically saying that you're intending to use the If that's the case, that's probably not the best use of the |
@jcn - I will use systems.csv as one part of trying to find/define all, or as many, bikeshares as possible. Sobi, GBFS, api/citybik.es - a composite list from multiple sources so I can represent as many as possible in my app. But with GBFS no defining the shared network (ie: socialbicycles, or bcycles) it become programmatically impossible to group the various bikeshares by network and/or decipher overlaps (or independents) from other sources. Its like just naming all cars by Ford...but never actually defining the manufacturer name "Ford" anywhere. Some just so happen to mention Ford, while others do not. Without specifically naming the network service ("Ford"), then its impossible to determine who some of the city bikesahres (the "cars") belong to. |
As a standard, I don't see GBFS ever dictating a naming scheme for the vendors / operators. That said, there are some proposals in #34 that might work (specifically including vendor in the system information file). But I'd imagine that would always be optional. |
Any place is better than no place. and I agree, having it in the standard top level json makes more sense. |
Found this thread while learning how to aggregate all available GBFS data. just FYI. |
We're considering the benefits of moving systems.csv to its own repo - to be able to have a different set of maintainers, to make the change logs easier to parse, etc. Before making that decision, it would be helpful to know how that would affect consumers of the file and get your feedback on the best path forward for communicating that change. |
Still looking for feedback on my last comment. As of today 83 of the 127 PRs (open and closed) related to systems.csv rather than to the GBFS itself. |
No consequences on this change for us, we'd be in favour. |
Pro this change, this is also a huge headache for us in maintain the
similar listing inside mobility-data-specification, can see the needs to
have it be governed / controlled / monitored differently.
…On Mon, Dec 30, 2019 at 7:51 AM Guillaume Campagna ***@***.***> wrote:
No consequences on this change for us, we'd be in favour.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#28>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANHXYW3GQQR2YLPWPNPZI3Q3IKILANCNFSM4CDSFEYQ>
.
|
Closing this issue - this topic has been taken up in #249 |
It seems like
systems.csv
would be a nice source for discovery of GBFS-compatible systems.Questions:
System ID
guaranteed to be unique?The text was updated successfully, but these errors were encountered: