Remove poor transit results for short trips, when walking is better

[t2gran]

In OTP2 the street search and transit search is done as to separate searches, then the results are merged and filtered to remove none optimal itineraries. But, when the client do NOT provide a ´directMode´ OTP do not do the streetSearch and the removal of none optimal results do not happen. In other words OTP is forced to return at least one itinerary with at least one transit leg. So, instead of walking maybe 100 meters, the OTP suggest you need to walk to the closest buss stop, take the bus on stop and walk back - with much more walking.

Let say OTP produces these internal results:

• Itinerary-1: Origin ~ Walk 100m ~ Destination (Street search)
• Itinerary-2: Origin ~ Walk 120m ~ Stop A ~ Bus 10:00 10:05 ~ Stop B ~ Walk 200m ~ Destination (Raptor search)

API level results

• Request 1: { directMode:WALK, access/egressMode: WALK, transitModes:[TRANSIT] }, OTP returns [ Itinerary-1 ]
• Request 2: { directMode:null, access/egressMode: WALK, transitModes:[TRANSIT] }, OTP returns [ Itinerary-2 ]

In this case Itinerary-1 is clearly better in all ways compared to Itinerary-2. Some OTP clients run a separate searches for WALK-ALL-THE_WAY, BIKE-ALL-THE-WAY, and WALK+TRANSIT. In this case it would be best for the client that Request 2 above just return an empty set, not the silly Itinerary-2.

Version of OTP used (exact commit hash or JAR name)

Current OTP2

Purposed solution

• If no directMode is set, always filter away itineraries with a generalized-cost that is higher than the WALK-ALL-THE-WAY.

Why use generalized-cost, and not walk distance or a full pareto comparison?

In general we assume that walking can be time-shifted; hence we can exclude arrival and departure time from the comparison. The transit might have a higher cost and shorter travel time than the walk-all-the-way itinerary, but this is theoretical and I have not managed to construct a good transit alternative.

If we compared just on walking distance we would still get silly results. E.g. if the only stop reachable within walking distance is a train station, we could get a itinerary like this:

• Origin ~ Walk 50m ~ Stop 1a ~ Train 10:00 10:15 ~ Stop B ~ Train 10:20 10:35 ~ Stop 1d ~ Walk 50m ~ Destination -
• NOT: Origin ~ Walk 120m ~ Destination