Regional Transportation District (RTD)

NTD GTFS readiness Ready

Published at a public URL, valid, current, and identified with agency_id: the four feed checks for RY2026 all hold here. Only your own D-10 and P-50 filings make that official; this is a heads-up, not a determination.

Published Ready

Published at a public URL.

Valid Ready

Passes validation with no errors.

Current Ready

Service data covers the next 87 days.

agency_id provided Ready

agency.txt provides agency_id. For RY2026, keep one stable value for each NTD reporter represented in the feed and crosswalk each value on the P-50 form.

agency_id equals your NTD ID (optional) Different (allowed)

Your feed's agency_id is RTD; your National Transit Database ID is 80006. A feed that serves several agencies (a shared regional feed) can legitimately carry more than one agency_id. The values do not need to equal the five-digit NTD ID, so this difference is allowed and carries no score. Confirm that P-50 crosswalks agency_id RTD to NTD ID 80006, and keep the feed value stable. Do not change it solely to make the two values equal.

shapes.txt covers your trips Ready

All 21598 trips have a shape in shapes.txt.

In plain words: if you report to the federal transit database, you have to publish a working, up-to-date feed, provide a stable agency_id for each represented reporter, and confirm the feed and P-50 crosswalk each year. This box is a heads-up; your filings are the official check.

A readiness signal mapping this feed to the FTA National Transit Database GTFS requirement (Report Year 2023 onward: a public, valid, current feed, certified annually on the D-10). For RY2026, each represented reporter needs a stable agency_id, unique within the feed and crosswalked to its five-digit NTD ID on P-50; the values do not need to be equal. FTA also requires shapes.txt in the published GTFS: Full Reporters from Report Year 2025, and Reduced, Rural, and Tribal Reporters from Report Year 2026. Not an official determination; your certification is the official check.

Conformance mark Not yet

One requirement remains for this feed to earn the conformance mark. States wheelchair access on 98% of stops and 0% of trips; the mark needs 90% of each.

Valid Met

Passes validation with no errors.

Current Met

Service data covers the next 87 days.

Accessible Not yet

States wheelchair access on 98% of stops and 0% of trips; the mark needs 90% of each.

In plain words: earn this mark when your feed passes validation, has not expired, and says whether nearly every stop and trip is wheelchair accessible.

A pass credential for a feed that is valid, current, and states wheelchair access on nearly every stop and trip. Accessibility here measures what the feed publishes, not whether a stop is physically usable. How the conformance mark works.

Can riders use it?

Checks beyond structural validation: places where the feed is valid but a rider still could not travel.

• 590 of 8074 boardable stops are never served by any trip. Riders see these stops in apps and on the map but can never catch anything there, which erodes trust in the data. Remove stops no route serves, or add the trips that should call at them.

These do not change the grade. They catch trips with no rideable leg and stops no trip serves, the kind of gap a trip planner trips over.

Realtime reliability

The realtime feed responded on 100.0% of 200 checks in the 25 days to 2026-10-07, with 16s median lag.

Sampled on a schedule between full scores, so this tracks uptime and freshness over time rather than at a single moment. The window ends at the newest observation, which is not always today: if the monitor stops, this window stops with it.

Live predictions vs schedule

Arrival predictions ran a median 4s late versus the schedule, and stayed within 245s nine times in ten. They were on time (about a minute early to five late) 91.1% of the time. 99.4% of reported vehicle positions sat on or near the published route shape.

From the last full realtime sample: how far live arrival predictions sat from the schedule, and whether vehicle positions fell on the route. These feed the realtime score; they change no other category.

How this agency maps to the standards

The scorecard is a data-quality lens, not a compliance determination. Its universal references describe good GTFS and useful rider information. Useful references here are GTFS Schedule Best Practices, GTFS-Realtime Best Practices, MobilityData grading scheme, Google Transit publication guidance, FTA National Transit Database GTFS requirement. Read the full standards crosswalk.

A local transit-data support resource is CDOT Digital Transit Mobility. Colorado's program coordinating GTFS data across transit providers. This resource supports agencies; it is not a scoring authority.

Correctness 68 / 100

GTFS Schedule best practices, checked by the MobilityData validator. MobilityData grading covers stop locations, route names, and colors. Google Transit requires a feed to pass validation for publication. FTA NTD readiness also checks that the published feed is valid.

Freshness 100 / 100

GTFS Schedule best practices call for a dataset that stays current. An expired calendar can remove service from Google Transit and other rider trip planners. FTA NTD readiness also checks that the published feed is current.

Rider experience 70 / 100

GTFS Best Practices for rider-facing fields. MobilityData grading covers stop names and headsigns.

Realtime quality 99 / 100

GTFS-Realtime best practices: a stable URL, high uptime, and frequent updates.