Add alerts for free-floating bike networks

[leonardehrenfried]

Depends on https://github.com/opentripplanner/OpenTripPlanner/pull/3370

Stadtnavi has modified OTP to include free-floating bike sharing but with a speciality for a Herrenberg specific use case: whilst OTP routes free-floating you cannot (as per T&C of the rental company) drop off the bike anywhere. We therefore add a warning informing the user that she needs to return the bike to a dock.

[flaktack]

I took a quick look at the above PR, and it doesn't support renting from a station and ending with a floating drop off -- which will be required here.

[flaktack]

There could be two solutions:

• modify the GBFS feed to use free_bike_status.json so that "free floating bikes" are created for the stations where only "round trips" are possible, which would allow one-way bike rentals with the current code.
• modify the code to either allow station-to-free-floating, or roundtrip rentals

[flaktack]

This was discussed in the OTP2 developers meeting. From a high-level the round-trip bicycle rentals could be handled by two changes:

• allowing for trips to end / start with the vehicle on-hand which could be a RoutingRequest parameter
• even if allowed, adding a cost (weight) when ending trips with the vehicle so that leaving it at a nearby rental station could still be preferred

How was this implemented in OTP1?

Thoughts :thought_balloon:

• this would only be allowed at the "ends" of trips (from or to) -- not when boarding or alighting transit. The bike would need to be taken from / returned to the bike rental station before boarding / alighting.
• the weight for ending the trip with the vehicle could be applied at the final TemporaryFreeEdge, which would allow the existing logic for state domination to be used. This probably needs more thought.
• would this be a per-station / per-updater property so that enabling it doesn't allow it in all places?
• ...

[flaktack]

I thought about this a bit, and the simplest solution to support the use case would be to:

1. Add allowKeepingBicycleRentalAtDestination, keepingBicycleRentalAtDestinationCost parameters to RoutingRequest.
2. TemporaryFreeEdge and StreetTransitEntityLink would be extended to allow dropping of floating bikes, and disallow traversal with rented bikes unless allowKeepingBicycleRentalAtDestination is set. If the bike is kept than keepingBicycleRentalAtDestinationCost would be added.
   1. This would mean State#getInitialState() would not create an arriveBy state for floating bikes, but would create a state when keeping the bike. Instead StreetTransitEntityLink and TemporaryFreeEdge would create RENTAL_FLOATING states when traversing in reverse.
   2. For access searches allowKeepingBicycleRentalAtDestination will always be false, it would only be allowed for direct and egress searches.
3. Add a flag to Itinerary - arrivedAtDestinationWithRentedBicycle so that an alert may be displayed.
4. this could be limited to certain stations (updaters), by:
   1. Adding a boolean BikeRentalStation#isKeepingBicycleRentalAllowed(), the value of which may be filled out by the updater using BikeRentalUpdaterConfig.
   2. When renting a station bike in BikeRentalEdge fill out StateData#mayKeepBicycleRentalAtDestination, which would influence isFinal() and whether the bike may be kept at the end of the trip. For arriveBy / egress searches BikeRentalEdge would need to verify if a kept bicycle may be picked up from the station.

This would not support starting a trip with a rented bike and returning it to the bike to a station. Is that needed?

If this sound good than I'll create an upstream issue.

[leonardehrenfried]

As always, this is a really good summary of the problem and a way forward.

Add allowKeepingBicycleRentalAtDestination, keepingBicycleRentalAtDestinationCost parameters to RoutingRequest.

If this is a feature that can be added in the updater is the request parameter still necessary?

This would not support starting a trip with a rented bike and returning it to the bike to a station. Is that needed?

There are some mixed-mode rentals in Germany that have both stations and free-floating bikes but our use case isn't one of them, so this is ok.

[flaktack]

In Herrenberg's case the request parameter is not required -- in cases where it could be possible to drop off the bike, I believe it is useful since it allows to differentiate between "temporarily" visiting a place (-> and so it is possible to continue the trip later with the bike), and "permanently" (-> I would prefer not to have to do anything with the bike once at the destination).

An alternative instead of the parameter could be to show multiple options ~~ it would allow having multiple access / egress for each trip (-> this bus may be reached by 15 minutes of walking, 5 minutes of biking, or 10 minutes if renting a bike), but would require larger changes. :smile:

This would not support starting a trip with a rented bike and returning it to the bike to a station. Is that needed?

There are some mixed-mode rentals in Germany that have both stations and free-floating bikes but our use case isn't one of them, so this is ok.

I probably wasn't clear enough -- I was thinking of the use case possible in Herrenberg: it is possible to plan a bike rental trip to your destination, but it is not possible to plan the reverse of that:

 I've arrived at my (intermediate) destination and kept the rental bike.
 Now, I want to continue on to my final destination and return the bike, how do I do that?

In Herrenberg it is clear where to return the bike -- there is only one bike rental station. But if there are more stations, than it could be useful to know which one would be the best taking into account the actual destination.

This would be a more complex feature, and so I only wanted to be explicit that currently it won't be an option.

[leonardehrenfried]

In Herrenberg's case the request parameter is not required -- in cases where it could be possible to drop off the bike, I believe it is useful since it allows to differentiate between "temporarily" visiting a place (-> and so it is possible to continue the trip later with the bike), and "permanently" (-> I would prefer not to have to do anything with the bike once at the destination).

Ok, I see. That's fine by me.

In Herrenberg it is clear where to return the bike -- there is only one bike rental station. But if there are more stations, than it could be useful to know which one would be the best taking into account the actual destination.

That's also ok since we cannot make an itinerary using a bike that may or may not be there.

What would be super-nice are via searches (intermediate places) but since OTP2 doesn't have them generally, that's a lot to ask for.

[flaktack]

I've created an upstream issue: https://github.com/opentripplanner/OpenTripPlanner/issues/3459

[leonardehrenfried]

@hbruch Upstream said that they are happy to accept the PR for this.

[leonardehrenfried]

I've just merged this in and you can see the feature in action: https://dev.stadtnavi.eu/reiseplan/Ehningen%3A%3A48.6592556%2C8.9405097/Jettinger%20Stra%C3%9Fe%2C%2071083%20Herrenberg%3A%3A48.61078142875835%2C8.842406272888185/?time=1620758700

Make sure to deactivate the bus though.