Statistics Canada now publishes a national database of public transit schedules built from agency GTFS feeds, and its documentation shows where data quality stands: all agencies supplied the six required GTFS files, but some feeds carried validation warnings, and the data was accepted as is. For a Canadian transit operator, the lesson is that GTFS data quality is now visible to researchers and planners, so it is worth checking your own feed before someone else does.
What is the Canadian Public Transit Network Database?
The Canadian Public Transit Network Database (catalogue number 23-26-0003) was released by Statistics Canada on January 31, 2025, with a correction on May 7, 2025. It consolidates GTFS static schedule data from transit agencies across the country, and Statistics Canada states that it lets users compare transit networks between municipalities and supports evidence-based decisions about transit infrastructure. It is produced by the Urban Data Lab at Statistics Canada, supported by Housing, Infrastructure and Communities Canada, and released under the Open Government Licence - Canada.
The download includes GTFS files for each agency feed (agency, stops, routes, trips, stop times and service calendars), a geospatial dataset combining stops and routes, data validation files for each feed, and metadata on sources and columns.
The agency count differs between pages. The catalogue entry refers to 150 transit agencies, while the data report dated July 30, 2025 counts 139 feeds covering the 10 provinces and 2 territories, including some interregional bus, rail or ferry services. We therefore use neither as a precise count of agencies, and we recommend checking the current documentation before quoting a number.
What does the validation step reveal about GTFS quality?
According to the Statistics Canada data report, each feed was checked with the Canonical GTFS Schedule Validator, a static GTFS validator maintained by MobilityData, which sorts findings into errors, warnings and information notices. The report states that all agencies included the six required GTFS files, but that some feeds produced validation warnings. It does not publish counts or shares of errors and warnings.
Other points from the same report are worth noting for operators:
- Apart from the standards-compliance check, data quality was accepted as is, and no attempt was made to fix errors or warnings.
- Some optional GTFS files were missing from certain providers.
- A small number of agencies had GTFS data that was not openly accessible online, so they were contacted by email.
- Shape geometries in the geospatial file were simplified using a 250 metre tolerance to reduce file size.
- Coverage gaps are to be addressed in future cycles by partnering with agencies that do not currently publish GTFS data.
The download also contains a CSV summarising errors, warnings and information notices for each feed, designed so that researchers can assess quality or report problems. In practice, this means an agency's validation results can be read by people outside the agency.
Why is GTFS-Realtime outside the database?
The report says that real-time data goes beyond the scope of this first cycle, and that the Urban Data Lab is assessing whether to offer it in future cycles. That is a reminder of a distinction that matters in procurement: static GTFS describes the plan, GTFS-RT describes what is actually happening, and the two have different owners and different failure modes. A real-time feed is only as good as the schedule it refers to, because trip updates must be matched to scheduled trips. Our article on common GTFS-RT mistakes describes where that matching goes wrong.
What does one large Canadian agency say about its own real-time data?
OC Transpo's developer page for Ottawa is a useful example of candid documentation. It states that a GTFS-RT next arrivals feed and service alerts feeds are published, that the previous stop-based API 2.0 was retired on April 30, 2025 and replaced by GTFS-RT, and that GTFS data has been public since 2008. Registered developers may use the GTFS-RT data for non-commercial and commercial purposes.
The page also describes how the data is produced: under normal operation, bus GPS data is sent every 30 seconds over cellular, and about 5% of the time exact bus positions are unavailable. OC Transpo states that it does not guarantee the accuracy or completeness of the data.
We cite this not as criticism but as a reference point. A published statement about update frequency and position availability is the kind of transparency that app developers, researchers and passengers can build on. It also shows that real-time data has a measurable availability rate, which an operator can track.
What should a Canadian operator check in its own feeds?
Because validation output can now be read outside the agency, a short self-audit is worthwhile. The checks below are general GTFS practice, not findings from the Statistics Canada report.
- Run a validator on every published schedule. Errors should be fixed before publication. Warnings deserve a decision: fix, or document why they remain.
- Check the optional files. Missing optional files, such as shapes, mean less useful maps and weaker analysis. If a file is missing, decide whether to produce it.
- Check calendars and exceptions. Service changes, school terms, summer timetables and public holidays are the most common sources of mismatch between the schedule and the street.
- Publish a stable location for the feed. The Statistics Canada report notes that some agencies' data was not openly accessible online and had to be requested by email.
- Measure real-time availability. If your GPS positions are unavailable for some share of the day, know the figure and tell developers.
How do Pysae modules fit into this workflow?
The modules below are described on the Pysae platform page, and we list only what the page states.
Pysae Network lets planners add a stop, shift a timetable or reconfigure a line directly on the map, with an AI agent that translates the change into plain language and applies it before validation. It manages calendars and exceptions such as back-to-school, summer timetables and public holidays without re-entry, and produces certified GTFS and NeTEx exports to regional journey planners. That makes the schedule feed a by-product of planning, not a separate spreadsheet exercise.
Pysae Operations then provides the real-time layer: a live map with delays, advances and regularity per line calculated automatically, alerts and incidents, and automatic GTFS-RT, SIRI and ITxPT exports to regional calculators and transport authorities. Pysae Fleet supplies the onboard box and the continuous field data behind it, with punctuality, mileage and journey time reports generated automatically.
What does this mean for Canadian transit providers?
A national database changes the audience for GTFS. Besides journey planners, a feed can now be compared across municipalities, validated by third parties and used in planning studies. Agencies and contractors that already treat the feed as a managed product will find that attention helpful. Those that treat it as an afterthought will find it harder to explain warnings they have not looked at.
The practical steps are modest: validate every publication, keep calendars current, make the feed easy to find, and measure the availability of real-time positions.
To see how Network, Operations and Fleet generate consistent GTFS and GTFS-RT feeds for a transit network, use the "Request a demo" button on this page.
Frequently asked questions
What is the Canadian Public Transit Network Database?
It is a Statistics Canada database (catalogue 23-26-0003), first released on January 31, 2025, that consolidates GTFS static schedule data from Canadian transit agencies, with validation files for each feed.
Does the database include real-time data?
No. The Statistics Canada data report says GTFS-Realtime is outside the scope of the first cycle and that the Urban Data Lab is assessing whether to include it in future cycles.
How was feed quality checked?
Each feed was validated with the Canonical GTFS Schedule Validator maintained by MobilityData. The report states that all agencies supplied the six required GTFS files, that some feeds had warnings, and that no attempt was made to correct them.
How often does OC Transpo's bus GPS data update?
OC Transpo's developer page states that bus GPS data is sent every 30 seconds under normal operation, and that exact positions are unavailable about 5% of the time.
Which Pysae modules generate GTFS and GTFS-RT?
Pysae Network produces certified GTFS and NeTEx exports, and Pysae Operations produces automatic GTFS-RT, SIRI and ITxPT exports.