Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LAMP stops id's slightly vary from those used by GTFS #15

Open
hamima-halim opened this issue May 8, 2024 · 3 comments
Open

LAMP stops id's slightly vary from those used by GTFS #15

hamima-halim opened this issue May 8, 2024 · 3 comments

Comments

@hamima-halim
Copy link
Contributor

hamima-halim commented May 8, 2024

The following stop_id's are report by LAMP

[   'Braintree-01',    'Braintree-02', 'Forest Hills-01', 'Forest Hills-02',
    'Oak Grove-02',    'Oak Grove-01', 'Union Square-02',  'Union Square-01']

GTFS, on the other hand, uses the numerical ID's for these stops in the stops.txt schedule (e.x., 70036 instead of Oak Grove-01). This messes up some of the GTFS-based merges we have to do on the stop_id column in this function

def _recalculate_fields_from_gtfs(pq_df: pd.DataFrame, service_date: date):

We need a map that translates LAMP's versions of these ID's to their numerical counterparts. Its pretty important because these are the first/last stops of their respective lines, and this can really screw over the route_starts calculations in this line

route_starts = pq_df.loc[pq_df.groupby("trip_id").event_time.idxmin()]

@hamima-halim
Copy link
Contributor Author

hamima-halim commented May 9, 2024

So, the stop_id that LAMP reports isn't consistent for these stops--sometimes the downstream processes will resolve the vehicle location's stop_id to the numeric id (ie, 70001) and sometimes they will use the alternate string one (ie, Forest-Hills-02)

@hamima-halim
Copy link
Contributor Author

(Thanks to @JNuss71 for walking through this with me!)

#18 adds a map that takes the Alpha stop_ids to their numeric counterparts (notice that in Union Square, tracks 1 and 2 actually differ.) This fixes issues with the Orange line, but trips starting from Alewife and Union Square are still showing odd behavior. For better or worse, this is also consistent with the behavior coming out of the GTFS-realtime API and indicates that whatever is coming out of the AVL's (and their light downstream processing) isn't guaranteed to be consistent with what's expected from GTFS's stop/trip information.

@hamima-halim
Copy link
Contributor Author

hamima-halim commented May 10, 2024

Alewife (Alewife-01, Alewife-02) trips are still behaving oddly, even outside of the fact that all southbound trips on the Red line during this planned outage aren't assigned a trip_id. I suspect theres some extra stop_id edge case we aren't picking up correctly that affects Alewife but not Braintree.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant