GTFS Scorecard
GTFS quality workflow
Public feeds checked daily · no loginRun status

Published feed evidence

Find the next fix in a published GTFS feed.

Search an agency to open its latest scorecard and first recommended fix. You can also check a GTFS ZIP before publishing it.

Correctness uses MobilityData's canonical validator. A missing realtime feed does not lower the grade.

Check to recheck

Where the scorecard fits in the work

  • Live
  • Your workflow
  • Pilot
  1. Identify the intended public feed

    Keep the source URL and feed identity attached to the record.

    Live
  2. Check the published data

    Run canonical validation plus freshness, rider-information, and optional realtime checks.

    Live
  3. Choose a concrete action

    Use the prioritized fix, affected field, rider relevance, and dated evidence.

    Live
  4. Change and publish the feed

    The agency, vendor, or support program works through its existing tools and channels.

    Your workflow
  5. Recheck the same feed

    The pilot tests feed identity and measurement comparability before calling a finding cleared.

    Pilot
  6. Preserve a closure receipt

    A verified closure requires an accepted action and a comparable recheck. This is not yet a proven service.

    Pilot

Choose the next job

Start with the work you need to do.

Each path uses the same dated feed evidence. The scorecard is one record in that workflow.

Example evidence record

Open the record behind a prioritized fix.

The example keeps the grade, measured categories, source finding, and next action together. Switch feeds or search above to inspect another published record.

Latest published scorecard

Examples are shown separately; measured category sets can differ.

Unitrans / Davis, California

Unitrans (ASUCD / City of Davis)

Published snapshot · Checked

Overall grade
Score across measured categories 80.8 of 100

Quality categories

Choose one

Correctness · 84.8

The MobilityData validator flagged 4 kinds of issue across 96 instances: 0 errors, 72 warnings, and 24 informational notices.

Prioritized fixes

Trace any one

01 / scorecard_wheelchair_boarding_unknown / stops.txt

State wheelchair boarding status for every stop.

What the feed says296 of 296 stops leave this field unknown.

Why a rider caresTrip planners cannot tell riders who use wheelchairs whether they can board there.

Likely your team · One column in stops.txt; start verification with the busiest stops.

Unitrans runs live bus tracking, but its data feed requires an access key the scorecard does not have. Realtime is excluded from this grade, with no deduction. Accessibility values describe what the feed publishes, not verified physical conditions.

Showing the Unitrans published snapshot.

Selected fix trace

Check the evidence before anyone acts.

Choose any fix above and this route changes with it: source field, check applied, finding identifier, and dated record. This establishes the starting point. It does not claim that anyone accepted or completed the work.

  1. 1 / Source field

    Wheelchair boarding in stops.txt

    The scorecard reads the same published stop records that rider applications receive.

    • stops.txt
  2. 2 / Check applied

    Direct field coverage

    The rider-experience rubric measures whether the published field states accessibility.

  3. 3 / Finding identifier

    Keep the code attached

    The identifier connects the plain-language fix to the dated record and rubric.

    scorecard_wheelchair_boarding_unknown

  4. 4 / Dated evidence

    Unitrans · July 10, 2026

    The dated snapshot keeps the source, check, and finding identifier together.

    Open the full evidence →

Where it fits

Use the scorecard between discovery and the next feed export.

GTFS Scorecard adds dated evidence and prioritized fixes around canonical validation. Agencies, vendors, editors, and support programs still make and publish changes through their existing tools. The accepted-action recheck remains a pilot.

  1. 1 / Discover

    Identify the intended feed

    Mobility Database and Transitland help people find public feeds and distinguish their sources or versions.

  2. 2 / Diagnose

    Apply canonical rules

    The MobilityData GTFS validator supplies the specification findings used for correctness. The scorecard does not reimplement them.

  3. 3 / Change

    Fix and publish the feed

    An agency, vendor, editor, or support program decides what to change and publishes the new export through its existing workflow.

  4. 4 / Verify

    Pilot the final recheck

    GTFS Scorecard is testing whether an accepted action can be linked to a comparable recheck of the intended published feed. This is not yet a proven service.

The California GTFS Quality Dashboard inspired this project's daily scorecard and support-program framing. GTFS Scorecard is independent and is not an official compliance determination.

Scope and limits

What the score does not establish

Worldwide quality core
Correctness, freshness, rider experience, and optional realtime quality use one disclosed rubric wherever a covered feed is published.
Coverage boundary
The registry spans dozens of countries and more than 2,000 curated feed records, with most published records still in the United States and Canada. It is not a census. A missing place means not covered, never poor performance.
Regional modules
Country-specific views appear only where their sources apply. U.S. NTD readiness and equity context do not change the worldwide quality grade.
Realtime and compliance
No realtime feed means “not measured” and does not lower the grade. The scorecard measures published data, not legal compliance or transit service quality.
Remediation boundary
A finding that disappears is a finding clearance. It becomes a verified closure only when an accepted action is linked to a comparable recheck of the intended published feed.

Pilot

Remediation workflow

A 90-day pilot is testing whether a finding can move through an accepted request and comparable same-feed recheck. This is not yet a proven service.

Pilot details