The changes here use existing trip data to model actual TTC routes and adjacent stops, which is more desirable than the incomplete route data from Nextbus. The idea is that, when fetching predictions from NextBus, the predictions show a list of stops (not just the immediate one but all subsequent ones up to a limit) and the expected amount of time it would take to arrive at each of those stops. The list is a great source of adjacent stops and their relative duration from each other. By aggregating all those data, it is possible to model a graph structure of the stops and hence the actual routes.
The following steps were taken to make this work:
Identify starting and terminal stops. This is a quick manual step. This makes it easy to traverse the graph from a limited number of points, and ensure the route do not traverse endlessly (eg. the route should stop at terminal stops)
Aggregate trip predictions to get adjacent stop data. For each stop, determine the next stop and the average duration to reach the next stop. Take out outliers but account for splits in the routes. (see PathNode.js)
Traverse stops to compute routes. Start from the starting stops (identified earlier) and traverse the stops until a terminal stop is hit.
The resulting data then are used to validate existing paths:
For if it is possible to travel from from to to (and they do not have to be immediately adjacent stops) from any existing routes. For example, if somehow from is on a westbound route and to is on a eastbound route, then this would not be valid.
Determine the number of hops and the total duration between from and to. The current algorithm requires at most 5 hops and a maximum total duration of 10 minutes for the path to be valid. The criteria may be adjusted in the future.
Check all routes for validity check, or if there is no hit, then the path is invalid too.
Update validity on all path statuses with matching paths
This is a fix for #4
The changes here use existing trip data to model actual TTC routes and adjacent stops, which is more desirable than the incomplete route data from Nextbus. The idea is that, when fetching predictions from NextBus, the predictions show a list of stops (not just the immediate one but all subsequent ones up to a limit) and the expected amount of time it would take to arrive at each of those stops. The list is a great source of adjacent stops and their relative duration from each other. By aggregating all those data, it is possible to model a graph structure of the stops and hence the actual routes.
The following steps were taken to make this work:
The resulting data then are used to validate existing paths:
fromtoto(and they do not have to be immediately adjacent stops) from any existing routes. For example, if somehowfromis on a westbound route andtois on a eastbound route, then this would not be valid.fromandto. The current algorithm requires at most 5 hops and a maximum total duration of 10 minutes for the path to be valid. The criteria may be adjusted in the future.