# A statewide transit feed that stays current

> How a state publishes one current statewide transit feed by federating dozens of operators and monitoring freshness, instead of chasing each by hand.

Dozens of small operators, one current statewide feed. Veodyn aggregates every operator and watches for staleness, so a trip planner can point at the whole state.

## The setup

A state has dozens of small transit operators. A few midsize city systems, a long tail of rural and tribal providers, a couple of intercity routes. Riders want to find all of them in the trip planner on their phone. The state has to report on all of them. Federal and state programs increasingly expect open, standardized schedule data as a baseline.

The reality on the ground is messier. Half the operators publish a GTFS feed. Some of those feeds are years out of date. The smallest providers have no IT staff and no feed at all. There is no single statewide source a trip planner or a reporting tool can point at.

## The data problem

Schedule data is only useful when it is current, and keeping it current across dozens of independent operators is the part that breaks.

Each operator that does publish does so on its own, in its own way, on its own schedule. When a rural provider changes a route, the feed lags or never updates. The state has no way to see, at a glance, which feeds are fresh and which have gone stale. A trip planner that wants statewide coverage has to chase every operator separately, and a rider in a small town simply does not show up in the app.

Most statewide transit-data efforts stall here. Getting feeds published once is hard. Keeping forty of them current is harder.

## The Veodyn architecture

Veodyn federates the operators into one statewide feed and keeps an eye on freshness. Each operator runs a node, or for the providers with no IT capacity, the state hosts a node on their behalf. The hub normalizes every operator into one consistent statewide layer and publishes it through a single open API. A trip planner calls one endpoint and gets the whole state.

- **Schedules and stop geometry** (GTFS) normalized into one statewide dataset
- **Real-time arrivals and vehicle positions** (GTFS-RT) where operators produce them
- **Freshness monitoring** so the state can see which operator feeds are current and which need attention, instead of finding out when a rider complains
- **One open feed out**, so Google, Apple, Transit, and any other consumer read the same source

The operators keep running their service. The state gets one current statewide feed and a clear view of which providers need help keeping theirs up to date.

> **Diagram.** Operator nodes, including state-hosted ones, feed a statewide hub that normalizes and monitors freshness, publishing one feed to trip planners.

## What the statewide feed can do

| The capability | What powers it |
| --- | --- |
| **One statewide trip-planner feed** | GTFS from every operator, normalized into one dataset, one open API. |
| **Riders in small towns show up in the app** | Hosted nodes for operators with no IT staff. |
| **The state sees which feeds are stale** | Freshness monitoring across every node. |
| **Real-time where it exists** - live arrivals | GTFS-RT normalized alongside static schedules. |
| **Add an operator without rebuilding** | New node joins the existing statewide layer. |

## We don't author schedules

Veodyn aggregates and publishes. It does not author schedules.

The work of building and editing a transit schedule still belongs to the operator and to the scheduling tools they use. Veodyn does not replace those tools; it takes what they produce, normalizes it across every operator, watches whether it stays current, and publishes one statewide feed. Operators keep their scheduling tools. The state stops chasing forty operators by hand and stops finding out about stale data from rider complaints.

## Why the small operators get in

The long tail is the whole problem, and open-core is what reaches it. A rural provider with no budget can run a free Community node, or let the state host one, and still land in the statewide feed. Because the feed is open, every trip planner and reporting tool reads it freely, so coverage compounds instead of fragmenting. Add an operator, and it joins the same layer. That is the difference between a statewide feed that covers the three biggest cities and one that covers the whole state.

## See it on your network

Tell us how many operators your state covers and where the gaps are, and we will map the fit. [Book a call](https://cal.veodyn.com/sawinyh/30min).

## More solutions

Other programs Veodyn makes possible, walked end to end. Or browse [all solutions](https://veodyn.com/solutions/).

- [Regional coalition · multimodal - Regional rewards - One rewards program across a dozen operators](https://veodyn.com/case-studies/regional-rewards/)
- [State DOT · traffic management - Statewide traffic ops - One operating picture across every TMC](https://veodyn.com/case-studies/statewide-tmc-hub/)
- [State DOT · multi-jurisdiction - Local federation - Cities join without giving up their data](https://veodyn.com/case-studies/local-federation/)
- [Grant-funded mobility · continuity - The pilot cliff - Integrations that outlive the grant](https://veodyn.com/case-studies/pilot-cliff/)

---

Source: https://veodyn.com/case-studies/gtfs-clearinghouse/
This is the plain-Markdown twin of that page. Every page on this site has one at the same URL with ".md" appended, or by sending `Accept: text/markdown`. Site index: https://veodyn.com/llms.txt