Data & Analytics for Transit & Transportation
Data and Analytics for Transit and Transportation Agencies
Reconciling ridership, on-time performance, asset, and federal reporting data into one set of definitions everyone can use.
A transit agency produces more counts of the same thing than anyone outside the agency expects. Ridership can come from the farebox, from automatic passenger counters, or from fare media transactions, and the three rarely match. On-time performance depends on which timepoints are measured, how wide the early and late window is, and whether missed and short-turned trips are included. The National Transit Database submission, the asset inventory, and the safety plan each carry federal definitions that may differ from what operations uses day to day. The result is a reconciliation exercise every reporting cycle, handled by a few people who know where the discrepancies come from, and a board that sees whichever number was assembled most recently.
On the roadway side the pattern repeats with different data. Pavement and bridge condition, crash records, traffic counts, and travel time datasets all describe the same network, but only if they are referenced to it consistently. A linear referencing system that has drifted from the field means two condition reports about the same corridor cannot be compared, and the performance measures required under federal transportation performance management rules become an annual assembly project rather than a byproduct of normal work.
What these environments look like
- Scheduling, runcutting, dispatch, and vehicle location systems from specialized vendors, each with its own database and its own export path
- Automatic passenger counters, farebox records, and account-based or mobile fare systems that can produce three different ridership figures for the same day
- Maintenance and asset management systems holding fleet, facility, and in rail agencies guideway condition, feeding transit asset management targets and reporting
- Paratransit scheduling and eligibility data with its own on-time, denial, and trip length measures
- Federal reporting on several calendars at once, including monthly and annual National Transit Database modules, safety plan measures, asset condition, and grant reporting
- Roadway data in separate custody: pavement and bridge management systems, the state crash repository, continuous and short-duration traffic counts, signal and ITS devices, and probe-based travel time data
- GIS as the shared spine for routes, stops, segments, mileposts, and assets, maintained by a team that is usually smaller than the demand on it
Where HQT helps
- A data platform that brings vehicle location, passenger count, fare, maintenance, and asset data together, with vehicle, route, and service date keys reconciled once instead of inside every report
- A written metric dictionary covering unlinked passenger trips, revenue hours and miles, on-time thresholds, missed trips, and mean distance between failures, so internal dashboards and federal submissions trace back to the same rules
- Reporting pipelines with validation applied before submission rather than after a file comes back rejected, including the counter validation practices that apply when sampled or automated counts feed federal ridership reporting
- Operations, planning, and board dashboards built on those definitions, validated by the people who run service before anything is published externally
- Spatial analysis on a maintained linear referencing and GIS foundation: stop and segment level performance, service coverage, asset condition by location, and the demographic analysis that supports Title VI service and fare equity review
- Open data and feed quality work, including monitoring that schedule and real-time feeds match the service actually operated, and publication of ridership and performance data with privacy review applied to fare account records
- Machine learning where it earns its place, such as running time estimation, demand forecasting, and maintenance prediction from vehicle telematics, documented so staff can see how a model behaves and so decisions about service and safety stay with people
How an engagement usually starts
Work of this kind usually begins at a pressure point rather than with a platform decision. A reporting cycle consumes weeks of senior staff time. A submission comes back with validation errors nobody can trace. A board member, a funding partner, or a reporter asks a question about ridership or reliability and three parts of the agency answer differently. A fare collection or dispatch system is replaced, the data moves somewhere new, and every report downstream of it breaks at once.
The first step is narrow and largely clerical: list the numbers the agency actually publishes, trace each one to the system and the query that produces it, and write down the definition in use. That exercise tends to surface the real problems, which are usually disagreeing definitions, an uncalibrated counter fleet, or data the agency cannot reach without a vendor request. HQT's people have professional experience doing this work inside transportation organizations, and the inventory is deliberately scoped small enough to finish before any platform or tool is chosen.