Possible Scenarios for Transit

Nobody has claimed this yet.

For public transportation, the literature defines a series of problems and scenarios. This ticket aims providing an overview over different scenarios as a basis to determine the scope of what we want to accomplish for traffic.

**Earliest Arrival Problem** (EAP)

In the earliest arrival scenario, a user could be at a location, for example Potsdammer Platz and wants to go to a different location e.g. Platz der Luftbrücke.
The transit planner should report the optimal path to get from the first location to the latter.

- Input: Origin + Destination
- Output: Earliest time the destination can be reached + route to destination

This scenario should be the first to implement. It suffers from a few shortcommings, though. The main is that the single route could be not to the liking of the user, even though it might be the fastest one. The number of transfers / complexity could be problematic.

**Multi Criteria Search** (MCS)

The problems of the EAP could be solved by supplying a few choices, just like alternative routes. We could imagine a list of possible criteria:

- walking distance
- number of transfers
- time taken
- cost (might be related to different transportation modes / transfers, probably most difficult to implement)

By reporting routes that optimise some/all of these criteria, we could provide a good selection of reasonable routes. This would likely be a reasonable service.

- Input: Origin + Destination
- Output: Optimal routes for all criteria

**Profile Search**

Profile searches are an advanced feature. They show the travel time throughout the day. They can be used to find the best time of the day to take a journey. In general I suspect this scenario to be of limited use, since usually the schedules should be most regular during normal working hours and the result would most often be that we suggest going around noon?

- Input: Origin + Destination
- Output: Possible optimal Journeys (travel time only?) over the timeframe of a period (e.g. alternative depart times)

**Isochrones**

For Mapbox cities/business usage, Isochrones would probably be a nice addition. Due to the small search space they should be easily calculated as well (on smaller networks at least). We could provide them to see how traffic behaves within the public transit network / show urban catchment. This could be a relevant tool for traffic planners / business decision (e.g. advertisement).

- Input: a single destination
- Output: a set of polygons that indicate reachability within a certain timeframe

**Distance Tables**

A service like the table plugin could be implemented based on the EAP, as long as we accept `N * |MAX(S,T)|` as cost and we do not optimise with any pre-computation. In many city scopes, this should be easily possible.
This could allow logistic usecases, similar to the normal distance table / trip planning for tourists. Timetable information needs to be somewhat stable for this, though, or we would need to compute a three-dimensional matrix.

**Extensions**
- likelihood to arrive on time (single low frequency connection with chance to miss over high frequency connections)

In general, it should be possible to combine with walking at begin/end in a `temporary augmentation to the input` (think phantom nodes in OSRM).

No files, tests, or entry points are named. Begin by locating the existing GTFS routing entry point, then confirm the earliest-arrival scope and acceptance criteria before implementation.

Written by the indexing model from the issue text.