You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This ticket proposes two new fields on the TripCounts table:
adjustedCount
adjustedByHour
These adjusted values count "partial trips" that only run part of their route's usual length due to shuttling. For instance, if an RL-B trip is shuttling north of Harvard, then we'd only count that as 15/18 ≈ 0.833 trips (excluding the northernmost three stations). This means the reduction in service quality from shuttling will be reflected in this metric, and the trip counts will remain robust to shuttling edge cases (like where the line is split into two functional segments by downtown shuttling).
In the lastest GTFS feeds we can use trips from the fake CalendarService called canonical to determine how many stops an un-shuttled RoutePattern should have. In the historical feeds, I think we can use RoutePattern.representative_trip_id.
The text was updated successfully, but these errors were encountered:
This ticket proposes two new fields on the
TripCounts
table:adjustedCount
adjustedByHour
These adjusted values count "partial trips" that only run part of their route's usual length due to shuttling. For instance, if an RL-B trip is shuttling north of Harvard, then we'd only count that as
15/18 ≈ 0.833
trips (excluding the northernmost three stations). This means the reduction in service quality from shuttling will be reflected in this metric, and the trip counts will remain robust to shuttling edge cases (like where the line is split into two functional segments by downtown shuttling).In the lastest GTFS feeds we can use trips from the fake
CalendarService
calledcanonical
to determine how many stops an un-shuttledRoutePattern
should have. In the historical feeds, I think we can useRoutePattern.representative_trip_id
.The text was updated successfully, but these errors were encountered: