Use cases
The rest of this documentation is organized by surface: here is the query editor, here is the feed page, here is what each field does. These guides are organized by goal instead. Each one takes a single goal an agency has and walks it from the data you already hold to something a reader outside your team can use.
There are eighteen guides here, in five groups. Nearly all of them are written to the same five parts, in the same order:
| Part | What it holds |
|---|---|
| What has to be true | The requirement, stated as the consumer or the regulator states it, not as the product states it |
| Before you start | What must already exist. Usually a query that has run at least once, and a credential |
| The steps | The path, in order, naming the page each one happens on |
| How you know it worked | The check that settles it, run from outside the instance wherever one exists |
| What takes it off the air | The failure modes, written down before you run into one |
The short ones collapse that to steps and honest limits, leaving out the middle sections where they would have nothing to say.
The guides come in two kinds. Some drive a product feature end to end, and every step is a page in this documentation. Others are recipes over data that is yours, where the product handles the ingest, the schedule, the query and the board, and the credibility of the numbers rests on your own systems. Each guide says which kind it is, and what it will not do for you.
Unless a step says otherwise, everything described is in the community edition. Steps that need the enterprise edition say so where they appear, and where a capability is split down the middle the guide states which half falls where: reading a private feed is community, issuing the token it is read with is enterprise; ingesting trip updates and service alerts is community, publishing them is enterprise.
Publishing a feed
| Guide | What you end up with |
|---|---|
| Publish a GTFS-Realtime feed | Vehicle positions at a public address, in protobuf, validated before every publish |
| Publish a GBFS feed | A whole GBFS system, docked or free-floating, at an address a city permit or an aggregator can be pointed at |
| Query a static GTFS archive | The schedule tables behind both of those, queryable beside the realtime feeds and checkable before anything depends on them |
| Take a feed back from a vendor | The same feed served from your own node, proven equivalent before anyone is asked to move |
Reporting and evidence
| Guide | What you end up with |
|---|---|
| Assemble a monthly ridership pack | UPT, VRM, VRH and VOMS by mode and type of service, from the systems of record, reconciled against a month you have already filed |
| Derive NTD service data from your GTFS archive | Route, trip and service-day counts read off the schedule you already publish, with the archive checked first |
| Report on demand-response service | Denials, missed trips, untimely pickups and ride length out of the dispatch system, on definitions written down once |
| Build a service equity board | Stops and service assigned to your own tract or district boundaries, shaded on a map, on attributes you bring |
| Prove your captures are current | A declared cadence on every capture, so freshness is a verdict the product reaches rather than a claim the data makes about itself |
Operating pictures
| Guide | What you end up with |
|---|---|
| Put a traffic management center on your board | Active events and sign status from a TMDD center, on dashboards of your own |
| Read a DMS fleet over NTCIP 1203 | Every sign's identity, status and current message, with unreachable signs visible as rows rather than as a failed query |
| Build an incident and air quality picture | Traffic alerts, air quality and weather on one auto-refreshing grid, with a reliability floor that keeps the noise out |
Analysis over time
| Guide | What you end up with |
|---|---|
| Build a history you can trend | Query results accumulating into a warehouse table, which is what every recipe below is built on |
| On-time performance | OTP% by route and day, computed from the delays your own trip-update feed reports |
| Track fleet utilization from telematics | Vehicles in service by hour, and the list of vehicles that have not moved in a week |
Getting data back out
| Guide | What you end up with |
|---|---|
| Ask your data from an AI client | Claude Desktop or an IDE reading your instance over MCP, read-only, scoped to your own permissions |
| Publish an open-data page | A dashboard the public reads without an account, and an embed that survives being pasted into another site |
| Distribute a feed to a named partner | One consumer reading a private feed on a credential you issued them and can revoke on its own |
What these guides do not do
They do not author your schedules, your fares or your service, and they do not count passengers. Veodyn moves, normalizes, stores, draws and republishes data that some other system is the source of. Where a guide's real answer is "fix it upstream", it says so rather than routing you through a workaround that hides the defect one layer down.