Include all direct transit trips in search result

[habrahamsson-skanetrafiken]

Feature

When searching between two stops/stations, we want to include "all" direct transit connections between the stops even if they are non-optimal. We only want to add the direct transit trips from and to the actual stops, no access/egress.

This would be an opt-in feature that is disabled by default.

Reasons

One of the most common complaints from our commuters is that they know of a specific train/bus they want to take from stop A to stop B, but our search results does not include the trip they are looking for because it is non-optimal. This is most often a regional bus/train that is shadowed by a faster express bus/train. Another example is when it is a faster + cheaper to walk to a nearby stop and take a trip from there.

The reasons that a user would like to take a non-optimal trip could be:

• They know the regional trains are less crowded than the express trains.
• They prefer the view from a specific bus.
• It's raining and they would rather sit on a bus than wait at a bus stop.
• etc

Example 1

The highlighted slower trains would not be shown by OTP (note that itineraries are sorted by arrival time).

Example 2

The highlighted bus is not shown by OTP because it is suboptimal in relation to the one above with 199m access walk (note that itineraries are sorted by arrival time).

Circular routes etc

It's not always reasonable to show all direct transit. For example a circular route if searching between two adjacent stops we wouldn't want to show the direction that goes the long way. The way we would solve this is by relying on the regular itinerary filter-chain to remove the more costly trips.

In order for this to work correctly we would have to assign costs to the itineraries.

Alternative solutions

• Transit group priority solves a similar issue. But this would require us to decide upfront which of the slower trains/buses we would like to promote and this would be intractable (and impossible for the realtime cases).
• Alter the raptor pareto calculation to make this kind of direct transit always be optimal. This would be a more complex solution and it would probably have performance implications.
• Create a separate endpoint for fetching the trips between two stops. Merge this with our regular search results outside of OTP. This is undesirable since we couldn't use OTPs filtering logic and would be difficult to maintain.
• The user could try to find the specific trip they are looking for using filters. This would require our users to understand the reason for why their trip doesn't show up. We cannot expect our users to know about OTPs optimality criteria.

Implementation / Architecture

This would be implemented as a separate router DirectTransitRouter that would generate itineraries like the DirectStreetRouter, DirectFlexRouter and the TransitRouter. That way it would be a totally independent module that can easily be enabled/disabled.

We would use the implementation of the search from the AlternativeLegs class by generalizing it a bit. The current implementation has some restrictions and has a lot of duplicate code with the StopTimesHelper. This would be cleaned up as part of the work.

I think this feature would be a good fit in OTP. It wouldn't add a lot of complexity. It follows the general philosophy of generating many itineraries and then filtering them down.

Prerequisites:

• Improve on the transit data filtering. Changes to TransitDataProviderFilter #6850, Create builder for TransitDataProviderFilter #6974
• Improve on the test framework in order to be simplify writing sufficient tests for the feature. Repurpose the RealtimeTestEnvironment into a TransitTestEnvironment #6899
• Generalize the implementation in AlternativeLegs. The implementation should be cleaned up, it has a lot of duplicate code with the StopTimesHelper.
• Implement alternative cost calculation.

This is related to #6227

[miklcct]

I think that the use of a new API endpoint is better because the use case is to specifically ask what direct services are available from A to B, not that you are finding a good way to travel from A to B.

There is no reason why you want to take a slow train from A to B in a journey planner. For example, it is undesirable to show a Lioness line train between Euston to Watford Junction which takes 3 times as long as the LNR train, while those who really need to use Lioness line (because e.g. they have pass which is only valid on that) would have already set it in their preferences.

If it is faster + cheaper to walk to a nearby station to take a train, a sensible traveller should do that unless there is a specific reason why he doesn't want to do that, which should be set as part of the input (for example, increasing walk reluctance).

[habrahamsson-skanetrafiken]

@miklcct

I think we have slightly different use cases. As I understand it you put a lot of emphasis on customization, but our ambition is to have a general purpose travel search that fills the use-cases of most of our users without any customization. That is one of the main reasons to use OTP, because it has multi-criteria search over a time-window. So OTP already returns results that fit different preferences (fastest, least number of transfers, generalized cost, departure time etc). If there was only one measure of what is desirable it would always be enough to return only a single itinerary because there wouldn't be any reason to consider any alternatives.

As it turns out there are many reasons to want to take a slightly slower train or bus. And finding these by customizing the search is often difficult and sometimes impossible. We've already tried this feature out as a proof of concept and the feedback was overwhelmingly positive.

I agree with you that usually the best solution is to use the already existing configuration parameters and cost factors. But we've thought long and hard about this and we are pretty sure this feature would be an improvement for us.

For other use cases one might want a separate endpoint for listing all direct transit between two stops and that should be trivial for whoever wants it to implement as a variation of this feature.

[t2gran]

In order for this to work correctly we would have to assign costs to the itineraries.

Clarify, itineraries have cost today.