Add an aggregated feed that includes station data + status about gbfs HOT 6 CLOSED

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.

from gbfs.

@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.

from gbfs.

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.

from gbfs.

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.

from gbfs.

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+

from gbfs.

I'm closing this.

from gbfs.