Support for configurable parameter for minimum flex access/egress duration in trip search

[andtry]

In a scenario where you combine a transit leg with flex access and egress legs we need support for a configurable parameter for minimum flex access/egress duration in trip searches.

A flexible door-to-door service gives very low cost and even a very short flexible leg will most likely "win" over a foot leg for access or egress. This is not desirable for most client implementations as you will get very short flex rides as your primary suggested itinerary.

example - https://otp2debug.dev.entur.org/?module=planner&fromPlace=59.90790988572098%2C10.756967067718508&toPlace=59.68342804259536%2C10.659742355346681&time=1%3A39pm&date=04-13-2023&mode=FLEX_ACCESS%2CFLEX_EGRESS%2CTRANSIT&arriveBy=false&wheelchair=false&showIntermediateStops=true&debugItineraryFilter=false&additionalParameters=numItineraries&numItineraries=2&locale=en&baseLayer=OSM%20Standard%20Tiles

[leonardehrenfried]

I think for this we probably want to have a flexReluctance or flexBoardCost or perhaps apply the regular boarding cost to flex, too.

[t2gran]

Having a flexReluctance or flexBoardCost will be problematic, because there is a great variation in what a flex service is. Some are almost a like a regular trip, and should have the same reluctance and board cost as scheduled transit. In other cases we would like to restrict the usage much harder.

I think we should consider filtering access/egress and consider doing it based on information about the flex service. For example we could have a minDistance on each service/Line/Route.

[tormoseng]

@andtry As promised, I've got a use case from AtB on this issue. Please follow up with questions/comments if you want us to describe something better.

Use case

AtB has two different scenarios related to trips going in and out of a zone where flexible transport is used for direct trips (address to address). Since the same trip can include arrival/departure to/from a zone where flexible transport is only used as the first or last stage in a connection with other scheduled transport, we will have to query OTP with "flexible" as access and egress mode.

The traveler will receive many travel options where flexible transport can be the first/last leg on several of these options. If either there was a query parameter that the client could use or information about a minimum distance was available on the line with flexible transport from the data source of OTP, short legs within the address-to-address zone could have been replaced with a walking leg.

Scenario 1

If a traveler wishes to travel from a location within an address-to-address zone to a location outside the zone, flexible transport cannot provide a direct journey. The proposed itinerary here is that flexible transport will be used as the first leg to a transit stop and later legs are scheduled transport. If the departure being searched for is relatively close to the transit stop, the traveler may be advised, for example, to take flexible transport for 2 minutes / 500 meters. This is a distance that is best walked by most people.

Scenario 2

Scenario 2 is the same as scenario 1, but in opposite direction.

If a traveler wishes to travel to a location within an address-to-address zone from a location outside the zone, flexible transport cannot provide a direct journey. The proposed itinerary here is that flexible transport will be used as the final leg from a transit stop and earlier legs are scheduled transport. If the destination being searched for is relatively close to the transit stop, the traveler may be advised, for example, to take flexible transport for 2 minutes / 500 meters. This is a distance that is best walked by most people.

Addition

An addition to the described scenarios is that in some cases it is desirable to actually display short legs with flexible transport. AtB has a service within an address-to-address zone for elderly people. For these users, it is relevant to actually be offered short legs with flexible transport. How could this be supported given the needs of scenarios 1 and 2 that apply to the vast majority?

[tormoseng]

@andtry What is the status on this one? Is it https://github.com/opentripplanner/OpenTripPlanner/pull/5180 that is the current plan?

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days

[tormoseng]

Solved by #5180, I guess!

[vpaturet]

Indeed this is solved by #5180

[tormoseng]

@vpaturet Is this feature now out and available in OTP "Prod", or is it still a beta feature and not ready for use?

[vpaturet]

This is available in the production environment.