bike network service name should be added to root csv file.

[rolinger]

In the root file the vendors bike network should be an added column. There are a more than a few bike rental company's that do not list, or have as a part of their URL or domain name, the name of their service network.

Example: Coast Bike Share. There is no information anywhere that suggests or shows they are a part of Social Bicycles. SoBi has their own API with more extensive data than is found here on the GBFS. I also forsee other bike networks, as they grow, coming up with their own API too. The GBFS for SoBi and the other API's would therefore be a secondary data pull.

With the "network" identified here we can differentiate between those with more populated APIs versus those that only have the GBFS data.

[rolinger]

Maybe this should be categorized as a Pull Request instead of an issue.

[serialc]

Everything about GBFS is about providing information to the user (see What is GBFS or Files) so I think this is beyond the scope of the purpose of the GBFS:

"GBFS will make real-time data feeds publicly available online in a uniform format so that map and transportation based apps can easily incorporate this data into their platforms."

I understand your desire to link GBFS to a specific API however. I could imagine an optional field being added to system_information.json titled "api" or "api_url" linking to an API that then provides vendor specific options/interactions.

If you want to make this a pull request then fork GBFS, make the desired changes and then make a pull request.

[fruminator]

@serialc and @rolinger please recall the informal policy/strategy we've adopted for changes to the spec: before bothering to make a pull request we would like to see it implemented somewhere in the real world so that everyone can be sure it meets real world use cases. hopefully you can find a GBFS provider to prototype this with you first.

[jcn]

@serialc I could see an optional api_url (to go along with purchase_url and the main system url) along with a vendor field since the two will be needed to know what type of API you're dealing with. I do think it's something that goes in the GBFS feed itself though, and not in the systems.csv file, which at this point is intended simply as a convenience.

The complexity then involves API versioning - e.g. if some systems are using an older version of an API, does this get codified in its own field? Does it just get parsed out of the URL somehow? These are the types of questions that we would like people to try to work out as we're thinking about evolving the spec and why it would make sense to work directly with a vendor to try to implement it before just making the changes.

[rolinger]

I am new to all this GBFS...however, I am a 3rd party app in need of the data provided here. Thus I am sharing my experiences on what is useful for deploying a national/multi-city app that spans all the various bikeshare vendors.

[mplsmitch]

Closing this - see Improvement of systems.csv #249 for the latest