Generalize kiss and ride mode as car_pickup mode

[gmellemstrand]

To be completed by pull request submitter:

• issue: Ride and kiss feature needed #2581
• roadmap: Not on the roadmap, but a refactor of existing functionality.
• tests: Have you added relevant test coverage? Are all the tests passing on the continuous integration service (Travis CI)?
• formatting: Have you followed the suggested code style?
• documentation: If you are adding a new configuration option, have you added an explanation to the configuration documentation tables and sections?
• changelog: add a bullet point to the changelog file with description and link to the linked issue

To be completed by @opentripplanner/plc:

• reviews and approvals by 2 members, ideally from different organizations
• after merging: update the relevant card on the roadmap

This relates to #2777 and #2581.

The kiss and ride is a mode where you started in a car and then you would exit the car by the street and walk the rest of the way. Basically it is the same as park and ride, except that you don't have to find a place to park. This could be someone driving you there, or taking a taxi.

In OTP1 we added a ride and kiss feature that was the opposite of this and allowed you to be picked up after riding transit, and then traveling by car to your destination.

This pull request generalizes the kiss and ride and ride and kiss features and renames it to car_pickup. Instead of starting or ending in a car, you will always start out walking, then get picked up by a car, and get dropped off so you can walk the rest of the way. In this way, the same option can be used for access, egress and direct searches.

We will probably eventually have to refactor the a star search in order to use a more general state machine implementation for these street modes. This pull request follows the pattern already in place, where the StateData class is used to keep track of which phase of the search we are in (carParked, bikePark etc. booleans). The car_pickup mode is changed to use a new CarPickupState enum, which contains the three possible states (WALK_TO_PICKUP, IN_CAR, WALK_FROM_DROP_OFF).

The StreetEdge class is then changed from 2 to 4 possible transitions (2 in each direction), while keeping the existing pattern.

To test this with the built-in client you have to change QualifiedModeSet.getRequestModes to return StreetMode.CAR_PICKUP as either directMode or egress/access mode, as there is currently no option in the REST API that maps to car_pickup.

You also should change the maximum walk field in the client to a higher number.

Try setting the start/end locations inside parks to test the walking at the ends.

[barbeau]

@gmellemstrand Would it be possible to set a wait time in the itinerary for being picked up by the taxi (both before and after the transit leg) via an API parameter? This would allow you to get an estimated wait time from an external system (e.g., a taxi API) and pass it into OTP for comparison against other trip modes.

[gmellemstrand]

@barbeau It would absolutely be possible. What we need to decide is how this ties into functionality like #2986. All this does now is replace the existing kiss and ride functionality, which we have been using as a simple taxi functionality at Entur.

This functionality assumes you can be picked up and dropped off at any street that allows both driving and walking.

[gmellemstrand]

I have changed the name of the mode from taxi to car_pickup to avoid confusion. I think it describes the functionality a little bit better.

Walk to a pickup point along the road, drive to a drop-off point along the road, and walk the rest of the way. This can include various taxi-services or kiss & ride.

[gmellemstrand]

I'm keeping this as a refactor/generalization of the kiss and ride mode. If someone wants to use this in the manner described by @barbeau , it is just a matter of adding a new car_pickup_wait_time parameter to the API and adding that time when the appropriate transitions happen in the StreetEdge.traverse method.

[abyrd]

Looks good, just requesting that a few identifiers be renamed.