Flag to allow bike returns if no docks are available

[nbdh]

Both of the big bike sharing operators in Germany, nextbike and DB Call a Bike, normally allow a user to return a rented bike next to the station if there are no free docks available.

If no spaces are available, simply lock it close to the stand.
https://www.callabike-interaktiv.de/en/cities/hamburg

Thus there should be a way to make sure that a station never appears to be "full" (accepting no returns) to GBFS consumers.

Is there a combination of station_information capacity and station_status num_docks_available to achieve this?

[mplsmitch]

I don't think this case is explicitly covered maybe you could use is_returning in station_status.json. for example if num_docks_available = 0 and is_returning = 1 then users can leave bikes. This seems somewhat related to #81 and #86 in that @dsgermain wants to add geographic (geofenced) areas next to existing station for free floating bikes.

[nbdh]

Thanks for your reply, Mitch. In my understanding the combination of num_docks_available = 0 and is_returning = 1 generally just means that the station is operating normally and not in some kind of maintenance state.

 1/0 boolean - is the station accepting bike returns (if a station is full but would allow a return if it was not full then this value should be 1)

Are there any opinions whether this kind of information is important enough to cover it in the spec?
I'll reply to #86 directly.

[serialc]

This sounds like it can be solved on the front end alone without any changes to the GBFS specification. Simply put, for systems that allow free standing locking of bicycles adjacent to a full station there exists no concept of a 'full' station. It is therefore up to the operator's GUI/webmap to only show the location of bikes and stations. The number of spaces becomes irrelevant.

If I understand the OP correctly I don't think this requires changes to the specification. At most perhaps in system_information.json a variable called adjacent_docking_allowed could be optionally set to true (1/0 boolean).

[nbdh]

@serialc Introducing a field like adjacent_docking_allowed was exactly what I was going at, because otherwise the front end (for example an app that just consumes GBFS) has no way to determine whether adjacent parking is allowed or not.

I'd rather call it adjacent_parking_allowed (or adjacent_returning_allowed?) because the user definitely is not going to "dock" the bike somewhere.

The main question I see is whether system_information is the right place to put it or if the publisher should be able to allow or disallow adjacent parking for particular stations so we'd put it into station_information or if a system-wide switch is sufficent. So far I don't know systems that do not allow it for all stations, but it in case an operator want's to specify it for every station putting it in the station_information might be more future-proof?!

[jcn]

What is the client implication in systems like this? Do they show a number of docks available but that number doesn't really matter? Or do they never show available docks because the system doesn't really have the concept of being "full?"

[serialc]

Looking at the Berlin system by DB, which is present in many other German cities, only bicycles and stations are present - not dock spaces.

[heidiguenin]

@nbdh Does #175 meet your needs? One revision that came out of a recent GBFS developers' workshop is to allow virtual stations to have unlimited capacity, so you'll see that change coming this week.

[antrim]

I think that #175 should serve this case, but I don't understand all the facets of this use case. I tried to summarize the thread over there. In order to test out that proposal, could people in this thread react to #175 (including proposing any necessary changes)? To try to focus the discussion around that proposed solution, I'm going to go ahead and close this issue for now.