How to Compare Two GTFS Feed Releases

A GTFS feed is republished again and again: a new timetable, a fixed stop name, a new season. Each release replaces the last one, and nothing in the zip tells you what is different. This guide covers what to compare, how to do it with plain files, why raw totals mislead, and how to read the answer in TransitLens.

Why releases need comparing

Most feed mistakes are not in a single file. They show up only when you put two releases side by side:

• A route disappears because an export step dropped it, not because the service ended.
• A stop moves a few hundred metres after a coordinate cleanup, and trip planners now send riders to the wrong corner.
• A day of service vanishes because a calendar.txt row lost its Sunday flag.
• Accessibility data regresses when wheelchair_boarding values are blanked during an update.

Checking the new release on its own will not catch any of these, because every file still looks valid. You need the previous release next to it.

What to compare

Five things cover most of the risk. Work through them in this order.

Routes

Compare the set of route_id values in routes.txt. Routes only in the old release are removed, routes only in the new one are added. Then look at the survivors: did a name, colour or type change, and did the number of trips change?

Stops

Compare stop_id values in stops.txt the same way, then check the same stop in both releases for a changed stop_name or a moved stop_lat and stop_lon. A stop that moved more than about 100 metres deserves a human look.

Trips per day type

Count how many trips run on a typical weekday, Saturday and Sunday in each release. This is the best single sign of whether service really changed. See Understanding GTFS Calendars for how calendar.txt and calendar_dates.txt decide which trips run on a date.

Service dates and feed_info

Read feed_start_date, feed_end_date and feed_version in feed_info.txt, and the date range in calendar.txt. A release that ends sooner than the one it replaces, or one that starts later than today, is a problem on its own.

Accessibility fields

Compare wheelchair_boarding on stops and wheelchair_accessible on trips. Losing accessible markings between releases is easy to miss and costly to riders.

The manual way and its limits

You can do all of this with the files. Unzip both releases, open routes.txt and stops.txt in a spreadsheet or a diff tool, and compare the ID columns. For trips, join trips.txt to calendar.txt and calendar_dates.txt and count trips for a chosen date.

That works for a one-off check on a small feed. It gets slow when:

• the feed has hundreds of routes and thousands of stops, so the ID comparison alone is a long list;
• you need trip counts per date, which means resolving calendar exceptions by hand;
• you want the answer on every release, not once, so the work repeats.

Running a line-by-line text diff on stop_times.txt is usually the wrong tool: a shifted trip ID makes thousands of rows look changed.

Compare typical days, not raw totals

The most common mistake is to compare the size of two releases. Here are the real TIB Mallorca releases, counted directly from the files (earlier: the Mobility Database snapshot of 22/04/2026; later: the release of 20/10/2026):

By raw total, the newer release has about 29% more trips, which looks like a big expansion. On the same real weekday the two releases are within 1% of each other. The April release was about to expire, so it simply held fewer future services. Comparing totals would have reported growth that never happened.

The fair test is to pick dates both releases cover and count what runs on a weekday, a Saturday and a Sunday. The reverse trap also exists: a new release that starts later than the old one can make a route look cut when it is only missing past weeks, so stay inside the weeks both releases share.

The same pair shows what a route-level comparison finds. By route_id, the October release has one route that April did not (A33, Port d'Alcúdia - Aeroport) and is missing two that April had (131, Santa Ponça - Banyalbufar, and 425, Cala Bona - Portocristo). By stop_id, 6 stops were added and 3 removed. Whether those are intended is exactly the question a maintainer wants raised before publishing.

Walkthrough in TransitLens

TransitLens compares two versions of the same feed. Each time you open a feed, it saves a compact summary of that version on your device, so an earlier version is there when the next release arrives. Nothing needs to be uploaded for the comparison.

1. Open the earlier release. Open the April 2026 TIB Mallorca release. The feed opens on the map and its summary is saved.
2. Open Feed Versions. Use the Feed Versions card in Insights, or the Compare two versions of a feed link on Home.
3. Add the later version. Choose Add a version and give it a ZIP file or a link, for example the 20/10/2026 release from the Mobility Database page. It is read without opening it on the map and saved as a second version of the feed.
4. Read the Summary. It shows counts for routes, stops and trips, change chips by type of change, the service dates, and a Worth a closer look panel of release checks.
5. Pick two versions. Use the two version pickers to compare any pair you have saved.

The release checks

The checks run on every comparison and flag the changes that are most often mistakes:

• a route that lost a whole day of service;
• service down by half or more;
• stops moved over 100 m;
• wheelchair access lost;
• routes no longer in the feed.

What you get on each plan

The Summary, its change counts and the release checks are free. Free and Basic accounts see the first 3 rows of each list of changes. Pro shows the full route and stop detail, the changes on the map, and an Excel or CSV export of every change.

A release-day checklist

1. Download the previous published release before you replace it. Keep it.
2. Compare the route and stop lists. Explain every removed route and every removed stop.
3. Check trips on a typical weekday, Saturday and Sunday, over weeks both releases cover.
4. Look for any day type that dropped to zero or lost half its trips.
5. Read feed_start_date and feed_end_date. The new end date should be later than the old one.
6. Look at stops that moved more than 100 m and at lost wheelchair markings.
7. Fix what is wrong, regenerate, and compare again before you publish.

What it does not do

• It is not a validator. It tells you what changed, not whether the feed follows the GTFS specification. For rule checks see how to check a GTFS feed for errors.
• It compares versions of one feed, not two unrelated feeds side by side.
• It cannot tell intent. A removed route may be a planned change. The release checks point at what to ask, and you decide.

To learn what each file contains before you compare them, read How to Read GTFS Data.