Add OpenBikeBox bike parking updater

[leonardehrenfried]

Depends on #48

Introduction

48 has already created a vehicle parking updater and we want to add the first bike parking updater.

Their location and availability should regularly be retrieved via the OpenBikeBox API (https://backend.openbikebox.de/documentation).

An example JSON to test is available at https://backend.openbikebox.next-site.de/api/v1/locations?format=list

Note: resource_count should not be used at it is apparently going away. Check https://github.com/openbikebox/backend/issues/4 for more instructions.

Check availability

The bike lockers should only be considered for inclusion into a route if they contain free spaces at the time of arrival. If the search is in the future or past then disregard this information and add the bike locker.

Add to routing result

The routing result should output the information about the bicycle locker so that the frontend can display something like "Lock bike at BikeBox Herrenberg Bahnhof".

Request parameter

Add a request parameter to only route to lockable bike parking facilities. I'm personally not sure about what the param should look like as I'm a bit wary of add yet another boolean to the RoutingRequest please.

On idea is to pass the list of vehicle parking types that you want to use but I welcome a discussion about this.

Follow up

59

[flaktack]

The bike lockers should only be considered for inclusion into a route if they contain free spaces at the time of arrival. If the search is in the future or past then disregard this information and add the bike locker.

Is the task of "disregarding" the availability an OTP side task, or a client task? There is already a useBikeRentalAvailabilityInformation which could be extended to a generic useAvailabilityInformation (or a useVehicleParkAvailabilityInformation).

Or -- an alternative could be to configure a time window during which availability is taken into account. This could be specified per updater, or for the whole graph in router-config.json. The advantage of this could be that it could take into account the actual time that the parking place is visited, and not the time that the trip is planned at.

[leonardehrenfried]

Maybe I should have been more clearer. What I meant was

"The bike lockers should only be considered for inclusion into a route if they contain free spaces at the time of arriving at it. However if the route arrives at the locker sufficiently in the future or the past a meaningful availability information cannot be derived so it should be included in the route."

I took a look at how it is implemented at the moment. I assumed it was a core OTP feature to disregard availability information when searching in the past/future but it turns out it's something that Helsinki added in their GraphQL layer: https://github.com/HSLdevcom/OpenTripPlanner/blob/master/src/main/java/org/opentripplanner/index/GraphQlPlanner.java#L294-L296

In such a case we ought to design a system that is least surprising to users and that may mean shifting the responsibility to the client.

Perhaps this is worth a discussion in the Slack channel, GH ticket or dev meeting?

[flaktack]

An OpenBikeBox specific updater is not needed, since OpenBikeBox has a ParkAPI endpoint.

[flaktack]

Correction -- currently ParkAPI is always for cars, so some changes will be needed.

[leonardehrenfried]

Estimation: 1/2/1.5 days