allow walk access or egress for ride_hail_transit #3818
Conversation
|
Test! |
|
Test! |
|
Test! |
|
Test! |
…h-transit # Conflicts: # src/main/scala/beam/router/r5/R5Wrapper.scala
…ce to happen too early????
…te pre-filtering before sending out rh requests
|
Test! |
There was a problem hiding this comment.
Maybe it's time to refactor ChoosesModeData. Instead of multiple requestIds and Optional responses that also may contain a virtual "Error" not requested, we could have a map similar to parkingResponses map. That map contains all the responses from the router and the RHM. And when all the required keys are presented in the map then we can do our caclulation and finish the mode choice?
src/main/scala/beam/agentsim/agents/modalbehaviors/ChoosesMode.scala
Outdated
Show resolved
Hide resolved
| ): Vector[EmbodiedBeamTrip] = { | ||
| if ( | ||
| rideHail2TransitAccessResult.error.isEmpty && | ||
| ): Option[EmbodiedBeamTrip] = { |
There was a problem hiding this comment.
This method was supposed to return multiple RH2T itineraries including pooling/solo for access/egress combinations.
There was a problem hiding this comment.
Aah, that makes sense, thanks. Hopefully the updates should capture that behavior now
src/main/scala/beam/agentsim/agents/modalbehaviors/ChoosesMode.scala
Outdated
Show resolved
Hide resolved
| // really need to send separate RH requests for each RH_TRANSIT itinerary if we wanted to do it correctly. This | ||
| // sounds too complicated and costly, so instead we just run a route choice on the RH_TRANSIT itineraries returned | ||
| // by R5. These don't necessarily have correct wait times, but R5 has been updated to give them appropriate costs. | ||
| // Once we've chosen the best itinerary we can send requests to the RHM to fill in true costs and wait times |
There was a problem hiding this comment.
If we generally have the same response from the router (except it may contain WALK as access or egress) then the rest of the ChoosesMode should be the same (except we don't need to send RH requests for WALK legs).
There was a problem hiding this comment.
I'm imagining a situation where the router returns two separate WALK->TRANSIT->RH itineraries, where the two egress RH legs pick up in different locations (e.g. at different transit stops). As I, understand it doing this would allow for only one RH request for the egress leg in this case, even though it could start from multiple locations. I'm not actually sure what the consequences of that would be (only having a maybe incorrect estimated wait time for the egress leg?), but it seems to me like we'd still be missing something.
| choosesModeData.rideHail2TransitEgressResult.nonEmpty | ||
| choosesModeData.copy( | ||
| rideHailResult = Some(theRideHailResult), | ||
| routingFinished = choosesModeData.routingFinished || routingFinished |
There was a problem hiding this comment.
I remeber introducing this routingFinished but I don't see it is used now. Am I missing something?
There was a problem hiding this comment.
It seems like it's still used here, although I haven't fully understood the logic
|
Test now! |
Previously we only allowed itineraries of rh -> transit -> rh when the mode
ride_hail_transitwas selected. This should allow for either the access or egress leg to be walk. There's nothing explicitly preventing the router from constructing awalk_transititinerary as well, but that one should be filtered out in ChoosesMode if it is not allowed based on the agent's input plans.This PR also captures RH cost in router so that we don't have as many routes with really long ride-hail legs and short transit legs
This change is