Home / Platform / GTFS & GTFS-Realtime
The format the industry agreed on

RouteSync reads GTFS, writes GTFS, and tells you which one you actually have.

Most agencies own a GTFS feed they have never read. It arrived from a supplier, it validates, and nobody has checked whether the schedule inside it is the schedule being run. Both directions matter here: consuming a feed you were given, and publishing one you can defend.

Consuming

Importing a feed is the easy half.

Any tool can parse a zip. The question is what the feed is fit for once it is in.

Static import

Agency, routes, stops, trips, stop times, calendars, shapes and fares, with a validation pass on the way in. Re-importing replaces rather than duplicates.

What the feed is for

A feed whose trips all start at 00:00:00 and carries no frequencies.txt is a route geometry, not a timetable. The platform says so on import instead of drawing schedule charts from it.

Corrections stay yours

Rename a stop, fix a coordinate, hide a route that no longer runs — the corrections live in master data and come back out on export, so the better copy is the one you hand on.

GTFS-Realtime in

Vehicle positions, trip updates and service alerts decoded natively from binary protobuf. No external service sits in the path.

Does the live feed match the static?

A realtime feed naming trips the imported schedule has never contained is a different vintage of data, and no amount of correct code downstream reconciles it. The platform measures the match rate and says when it collapses.

Scheduled pulls

Static re-import on a schedule and realtime polling every twenty seconds, with a log of what changed and what it cost.

Publishing

A feed you can hand to Google.

Publishing is where a feed stops being an internal artefact and starts being read by people who will not ask you what you meant.

Built from master data

The package is assembled from the network as the platform holds it, with your corrections applied — not from whatever the last supplier shipped.

Two validation passes

The MobilityData canonical validator for the specification, then a rule set for the content policies a transit aggregator enforces: name quality, translations, forward calendar coverage, timezone against city.

Versioned and approved

Every build is checksummed, diffed against the last published version file by file, and published by a named person. A build with blocking findings cannot be published at all.

Hosted for collection

Served at one stable URL per feed, optionally behind a credential, and mirrored to S3, SFTP or Cloud Storage where an authority's own policy requires it.

Realtime out

Vehicle positions, trip updates and service alerts as binary protobuf, keyed to the published static so nothing references a trip the schedule does not define.

Future-dated changes

A timetable change is staged with feed_info dates and sent days ahead, so the consumer switches to it on the day it takes effect rather than the morning you remembered.

Scope

What GTFS cannot tell you.

A valid feed is not a true feed. GTFS validates structure, not accuracy: a feed can pass every check and still describe services that stopped running two years ago. The specification also has no opinion on operational reality — a trip in the file says nothing about whether a bus was available, a driver was rostered, or the route was diverted that week. Where the platform can check a feed against what actually happened, it does, and where it cannot, it says the figure is what the feed claims rather than what the network did.

Send us the feed you already have.

We will import it and tell you what it is fit for — a timetable, a route geometry, or a file that validates and describes nothing that runs.

Thanks — we'll be in touch shortly.