Add an aggregated feed that includes station data + status

[marianosimone]

One of the current uses of the legacy json feeds is to show the stations of CitiBike NYC in DuckDuckGo:

The legacy feed works great for this, because by making only one call, we can get the stations' names, locations and number of total/available bikes.

We would love to switch to the new GBFS feeds, but that would imply either making two calls (one to get station_information.json and another for station_status.json), or periodically getting the station information, and then updating only the statuses on demand.

Ideally, there could be an aggregated feed that includes all the fields from both of them.

[fruminator]

@marianosimone we had this discussion when designing GBFS. We recognized that this is a downside of the GBFS as designed but we had already discussed and ruled out the aggregated feed. The expectation is that consumers of the feeds are going to deal with this.

Given that we've treaded over this ground before, I propose to close this issue.

[marianosimone]

Is it possible to reconsider this. It seems to me that any real time use case would be benefited from an aggregated feed.

This is specially true when new stations are added regularly (a lot of the systems are growing), making the caching possibility impractical.

Given that the customers expectations night be different from those of the designers, it could be interesting to give this topic another shot.

[serialc]

While having one file/request provide location and state together may make things easier for those using the data for maps or whatever else, it will also reduce the number of requests for operator servers. In fact I think that having two files as is currently the case isn't a big deal for those calling the API, the burden currently or in the future is likely to be on the servers.

This is perhaps something to share with NABSA operators and get their input.

[fruminator]

A number of NABSA operators had input into the design of the standard. The feeds are typically going to be served by the servers of the bike share system suppliers, all of whom have already thought through the implications and bought into the standard as is. Serving twice as many basic HTTP requests that aren't querying huge amounts of data is not a concern for modern web applications.

[serialc]

I understand @marianosimone's desire for one request but once your application's GBFS protocol is coded to make both requests it's abstracted and never needs to be worried about again. A+

[fruminator]

I'm closing this.