The Run-Times Analysis view gives you a deep understanding of how your routes are performing in accordance with their scheduled run-times. This view provides insights into whether trips' schedules are too tight or have extra slack that can be cut. In the Run-Times product, the analysis view hosts trip specific information and clearly breaks down how each trip on each route compares to your scheduled run-times.
The analysis tab includes both trips with complete data (complete trips) as well as trips with enough data that Swiftly can infer the run-times (incomplete trips). Captured trips represent the set of complete trips + included incomplete trips.
For ease of analysis, trips are grouped into the same row if they have the same scheduled start time, scheduled runtime, next trip scheduled start time, trip pattern. If two trip are different in any of those dimensions, they will be in different rows.
Complete Trip: A trip observation that has an arrival or departure observed for every scheduled stop and:
- The stop observations are in order (each arrival or departure time is greater than or equal to the one for the previous stop)
- The observed departure time for the stop is greater than or equal to the observed arrival time of the stop
Incomplete Trip/Partial Trip: A trip observation that is missing both an arrival and departure for at least one stop.
- If an arrival or departure is observed for every stop, but in the wrong order, the trip will still be considered “incomplete” in the Run-Times product, and it will not be available in the trip-level analysis views.
- Paths from the stops that were observed on the trip will be available in the single trip analysis views (path-observations and path-stats).
Captured Trip: A trip with an observed first stop departure, last stop arrival, and was completed by a single vehicle. Regardless of whether the mid-trip stops are observed, the trip will be available in the trip-level analysis views.
- Paths from the stops that were observed on the trip will be available in the single trip analysis views.
Run-times data from the dashboard can be exported using the download button in the header. This gives users the flexibility to dive deep into the data and create custom visualizations. The returned data includes travel time, run-time and dwell time information for observed trips, and scheduled runtime information for all scheduled trips, regardless of whether they were observed. Note: Only captured trips will return a value for observedRuntimeSeconds, otherwise observedRuntimeSeconds will be null.
Filters
With the Analysis view, you can look at a certain route in a specific direction. On that route and that direction, you can either look at "All Trips" or a specific trip on that route to get a trip's stop by stop comparison of scheduled versus observed run-times. You can also look at run-times for a single day or over a longer date range. In this specific view, you can exclude dates that may impact on-time performance (snow days, events that disrupt service, etc.).
You can customize parameters and add filters –if a certain route has multiple trip patterns, you can select which trip pattern you want to analyze. In the percentile view, specifically, you may adjust the percentiles - the defaults are 10th, 50th, and 90th percentile - to better match how your agency looks at run-time percentiles.
The Three Charts:
The route- and trip-level reports are available in three views:
- Components (described above) – the median breakdown of shortest observed travel time, variable travel time, and dwell.
- Distribution – shows a distribution of the overall run times recorded during this time period.
- Percentile – sorts the distribution into 10th, 50th, and 90th percentile breakdowns. These percentiles are customizable from the gear icon in the upper-right corner.
Components
Dive deep with route - and trip-level run-times reports– Click on any route (or select it from the Filters panel) to view run-times data for each trip on a given route. Click on any trip to see run-times data between stops for a single trip.
These run-time reports are broken up into 3 components:
-
Shortest observed travel time is represented by light blue – Conceptually, this represents the fastest possible run time for a trip if a vehicle were to have perfect light timing, no traffic, and no boardings. The shortest observed trip travel time (in minutes) in the selected date
range. If the date range is less than a week, then it’s the shortest trip travel time observed in the week prior to the selected end date. - Variable travel time is represented in dark blue. This is time added that is related to congestion, traffic lights, or other delays while the vehicle is in motion.
- Dwell times are represented in purple. This is time spent stationary at stops, likely spent loading or unloading passengers. (note: any time spent stationary at a traffic light that is not also a bus stop would be considered variable time).
Collectively, these distinctions may reveal certain patterns, such as a specific stop with high dwell due to heavy boardings, a higher variable time during the morning peak, etc.
If there are no complete trips for a given start time, Swiftly is unable to differentiate each component and thus will show a single bar which shows the total run-time.
Distribution
Be able to quickly decipher problem areas with scheduled run-times by understanding if certain trips in a schedule are always behind or ahead of schedule, or if there are one or two vehicles that tend to skew the average scheduled run-time.
On the chart, each trip on a route will have blue dots that represent a vehicle's observed run time and show the scheduled run-time (green bar) and next trip start for that vehicle (brown bar). The dots will be laid out according to the observed run time. If all the blue dots are clustered on the distribution chart, then it shows that each vehicle in that trip has a similar observed run time, and if all the vehicles are scattered on the chart then the trips have very different scheduled run-times.
These patterns can help you pinpoint where actionable run-time readjustments could have a big impact (on distributions that are very close together and one change can make a big difference), or can shed light on one vehicle's observed run-time that could be skewing the data.
Hover over the blue dots to get more information on:
- Trip Number
- Scheduled run-time
- Next trip start time
- Observed run-time
- Longer or shorter than scheduled by
- Day
- Date
- Vehicle ID
Percentile
Hone in on what percentile your trips' observed run-times fall into. Many agencies understand scheduled run-times through percentiles, and with this chart, you can quickly gauge whether your percentiles fall within the scheduled run-time, under the scheduled run-time, or above it. This chart helps you view whether the majority of your trips fall within the range of your scheduled run-times and whether the outliers (10th or 90th percentiles) fall outside of the scheduled ranges.
The colored dots represent the set percentiles - defaults being 10th, 50th, and 90ths, and the green and brown bars are scheduled run-times and the next trip start.
Hovering over a dot will give you more information on:
- Trip ID
- Number of trips
- Scheduled run-time
- Next trip start
- [x] percentile time
- Longer or shorter than scheduled by
FAQs
Why are timebands slightly different from trip start times
Swiftly is looking at the trip schedules and grouping all consecutive trips with the same scheduled run-times into the same timeband. We try to round the timeband start times to nearest 15 minutes when we can so that the display time is cleaner. We set the displayed endtime of the previous timeband to end 1 minute before the start of the next so that it is obvious which timeband a 6:00 trip belongs to, for example.
Comments
Article is closed for comments.