Publishing a GTFS feed when you are a five-person agency

A plain walkthrough of what a GTFS feed is, the seven files that actually matter, how to get yours onto Google and Apple Maps, and what breaks it six months later.

GTFS is not a piece of software you buy. It is a zip file full of comma-separated text, and once you understand that, most of the intimidation goes away. If your schedule exists anywhere — a spreadsheet, a printed timetable, a wall — you already have almost everything a feed needs.

This guide is written for the agency where the same person schedules, dispatches, answers the phone and sometimes drives. It assumes no GIS staff and no budget line for a consultant.

What is actually inside the zip

A GTFS feed has a lot of optional files and a small number that carry the weight. If you get these right, you have a valid feed.

File	What it is	Gets wrong most often
agency.txt	Who you are, your URL, your timezone	Timezone left as UTC
stops.txt	Every place a vehicle picks up, with coordinates	Latitude and longitude swapped
routes.txt	Each named line riders would recognise	Internal run numbers used as public names
trips.txt	One row per individual departure	Direction IDs applied inconsistently
stop_times.txt	The times themselves — much the largest file	Times not increasing along the trip
calendar.txt	Which days each service pattern runs	End date already in the past
calendar_dates.txt	Holidays and one-off exceptions	Skipped entirely, so Christmas is wrong

The single most common reason a small agency's feed goes stale is calendar.txt. Service periods have an end date. When it passes, your feed does not warn anyone — it just quietly stops describing any service at all, and the trip planners drop you.

Coordinates before anything else

Get your stop coordinates right first, because everything downstream inherits them. A stop placed on the wrong side of a divided highway sends a rider across four lanes. A stop dropped in the centre of a town because nobody had a precise location makes every arrival estimate wrong.

Walk or drive the line with a phone and record the actual boarding point, not the intersection name.
Record latitude and longitude to five decimal places. That is about a metre, which is plenty.
Give every stop a stable ID you will never reuse, even if the stop closes. Riders' saved trips depend on it.
Name stops the way a rider would say them out loud, not the way your dispatch sheet abbreviates them.

Two hands at a wall of pinned paper notices in a small agency office, one pointing at a document while the other holds a pen. — **Plate 08**Where the schedule really lives, until somebody retires.

Validate before you publish, not after

The canonical validator is free and open source, maintained by MobilityData. Run it before anyone else sees the feed. It produces two things worth caring about: errors, which mean consuming apps will reject or mangle your data, and warnings, which usually mean a rider will be confused rather than stranded.

Fix every error. Read every warning and decide deliberately. It is entirely reasonable to accept a warning you understand; it is not reasonable to have never looked.

Getting onto the maps people actually use

Publishing a feed does not put you on Google Maps. You have to hand it to each consumer, and each has its own onboarding. The order that wastes the least time:

Host the zip at a permanent URL on your own site. Not a Dropbox link, not an email attachment — a URL that will still work in three years.
Register that URL with the Mobility Database so the wider ecosystem can find it without asking you.
Apply to Google through their transit partner programme. Expect weeks, not days, and expect a round of corrections.
Apply to Apple separately. It is a different queue with different reviewers.
Tell the regional apps in your state. They are often the fastest to add you and the most used by your actual riders.

Publish at a stable URL that always serves the current feed, and let consumers re-fetch it. Do not put a date in the filename and expect anyone to notice the new one.

What breaks it in six months

Almost every stale feed we have looked at went stale the same way: the schedule changed in the real world and the feed did not, because updating the feed was a separate job that belonged to a separate person who was busy.

A service period ended and nobody renewed the calendar.
A detour became permanent and the stop was never moved.
The person who knew how to regenerate the zip retired.
The schedule was corrected in the printed timetable but the feed was built from an older spreadsheet.

The structural fix is to stop treating the feed as an export and start treating it as a view. If the feed is generated from the same schedule your dispatchers actually work from, it cannot drift, because there is nothing for it to drift away from.

Source: GTFS reference and the open-source canonical validator — MobilityData

Questions

Do we need GTFS if we are demand-response only?

Not for classic fixed-route GTFS, no. But GTFS-Flex now describes demand-response and deviated-route service, and being visible in trip planners is how new riders find a dial-a-ride they did not know existed. It is worth doing.

How often should we republish?

Every time the real schedule changes, and at minimum whenever a service period is within sixty days of ending. If republishing is hard enough that you would not do it for a single stop change, that is the problem to fix first.

Is there a free way to do all this?

Yes. The spec, the validator and the Mobility Database are all free. Plenty of agencies maintain a good feed by hand in a spreadsheet and a text editor. What you are buying with software is not capability, it is the elimination of the drift between your schedule and your feed.