Stop predictions show wrong routes or are missing

[chosak]

Clicking on a stop to get real-time predictions can show predictions for routes that don't actually go to that stop. Additionally, routes that do go that stop may be missing even though real-time predictions should be available. This is because of inadequacies in the logic used to match stops defined in GTFS datasets with stops defined in real-time APIs.

An example from transitnearme.com, using data from WMATA's GTFS feed and real-time APIs:

Clicking on the "Q ST. NW & 30TH ST NW" stop located at latitude 38.910477, longitude -77.058964 brings up a popup that lists services for 3 eastbound buses: the D1, D2, and D6. The popup correctly shows real-time predictions for those buses (if running at that time), but it can incorrectly also show predictions for other buses, including the westbound D1, D2, D3, D6, and G2. These buses don't actually stop there, but instead stop at two nearby stops: "NW Q ST & NW 30TH ST" at 38.910567, -77.0596 (westbound D1, D2, D3, and D6) and "NW P ST & NW 30TH ST" at 38.909378, -77.059101 (westbound G2).

Similarly, clicking on those two nearby stops correctly lists the services running from them, but don't list any predictions. This is because the real-time predictions have been incorrectly matched to the wrong stop.

The matching between GTFS stops and real-time API stops currently occurs when the database is built via the manage.py builddb command (see /tnm/api/management/commands/builddb.py). The logic currently uses a combination of stop name and location in order to do the matching. It has to support cases where names specified in the GTFS ("NW Q ST & NW 30TH ST") are slightly different from those in the API ("Q ST NW + 30TH ST NW"). It also has to support cases where the stop locations are slightly different. In addition, the logic should support cases where multiple API stops (say, from different agencies) are mapped to the same place.

The above constraints get complicated, and fixing things in one area may cause the matches to break in other places. Better logic should be incorporated to handle this, either automatically or semi-automatically with a way for administrators to review ambiguous matches and correct problems.