How Live Train Tracking Actually Works: GPS, GTFS-RT and Official APIs

01

Where train positions really come from

Watch a dot glide along a live map and you might picture a GPS unit beaming from the roof. Sometimes that is exactly right: Amtrak fits GPS across its fleet, Irish Rail streams coordinates from its trains, and Finland publishes satellite positions for nearly every service in the country. Most European tracking, though, never touches a satellite. The railway already knows where every train is, because signalling cannot function otherwise. Track circuits sense a train short-circuiting the current between the rails; axle counters tally wheelsets into and out of each block section. Every time your train passes a signal, the infrastructure manager's train describer steps its identity from one berth to the next, and that timestamped event is what feeds the data pipeline. The resolution equals the block length: 200 metres in dense suburban zones, several kilometres in open country. On lines fitted with ETCS, balises between the rails add precise fixes. GPS dies in tunnels. Track circuits never do.

02

GTFS and GTFS-Realtime, the standards underneath

In 2005, Google and TriMet, the transit agency for Portland, Oregon, sketched a plain-text format for timetables so journey planners could read any operator's data. That became GTFS, the General Transit Feed Specification: a zip of CSV tables listing stops, trips, stop times and calendars. It now describes tens of thousands of networks worldwide. The realtime companion arrived in 2011. GTFS-Realtime is a compact Protocol Buffers stream carrying three things: trip updates with predicted times at each stop, vehicle positions with latitude, longitude, bearing and speed, and service alerts. Each realtime entity points at a trip identifier in the static feed, which is how an app knows a moving dot is your 14:32 departure rather than anonymous hardware. When that matching breaks, because a train was renumbered or replacement stock took over, the dot vanishes even though the train is running fine. Journey planners and aggregators merge hundreds of these feeds into one queryable layer.

03

The national data feeds worth knowing

A handful of official sources power most of what you see. In Germany, the VBB region around Berlin was an early GTFS-Realtime publisher, the national DELFI initiative aggregates timetables for the whole country, and Deutsche Bahn exposes its timetable and disruption systems through the DB API Marketplace. Britain runs on Darwin, the Rail Delivery Group engine behind every departure board, while Network Rail separately publishes signalling-level feeds that report berth-by-berth movements. Irish Rail offers a realtime API with GPS positions. Finland is the quiet champion: Digitraffic, run by Fintraffic, streams the location of practically every train over open interfaces, with updates arriving every few seconds. Amtrak publishes GPS positions behind its Track a Train map. Switzerland consolidates everything at its open transport data portal. Coverage elsewhere is patchier: India's NTES reports trains at stations and control points rather than continuously, and much of Southeast Asia publishes timetables but no live positions at all.

04

No GPS? Then the dot is a calculation

Plenty of live maps show trains that carry no working position feed. The trick is schedule-based interpolation. The system takes the last confirmed report, say departed station A four minutes late, reads the timetable's 23-minute run to station B, and slides the dot along the route geometry at the implied speed. Between reports, the position is an educated guess, and its confidence decays with every minute of silence. India illustrates both ends of the spectrum: locomotives fitted with satellite-linked RTIS units report roughly every 30 seconds, while unfitted trains surface only when they pass reporting points, so an estimate can drift by kilometres on a long section. You can often spot the difference yourself. A dot that glides with perfect smoothness is usually interpolated; one that jumps forward in small steps is reporting for real. Deep tunnels force the same fallback everywhere: through the 57-kilometre Gotthard Base Tunnel, positions come from the signalling system, not from satellites.

05

Why two apps disagree about the same train

Open two apps and you may see the same train four minutes late, seven minutes late and on time. Nobody is lying. One app consumes vehicle positions, another consumes trip updates, a third scrapes a departure board, and each source sits at a different point in the pipeline. Polling intervals differ, caches differ, and matching logic differs, so a renumbered or divided train can survive in one dataset and vanish from another. The deeper split is measurement versus prediction. Raw lateness says the train left the last stop seven minutes down; a forecasting engine, like the rules Darwin applies in Britain, says it will be four down at your station because the schedule ahead is padded. Both numbers are honest answers to different questions. After a December timetable change, disagreements spike for days as feeds resynchronise. As a rule, the app closest to the operator's own systems wins arguments about the next ten minutes.

06

What updated 30 seconds ago actually means

That reassuring refresh badge measures the last hop, not the whole journey. A position is born on the train or in an interlocking, waits for the operator's backend to aggregate it, gets republished by a national feed on its own 30-to-90-second cadence, then sits in an app's cache until the next poll. Chain those latencies together and a freshly fetched position can describe where the train was two or three minutes ago. GTFS-Realtime carries a timestamp for the measurement itself; honest apps surface that rather than the fetch time. Prediction has its own ceiling. Short-horizon estimates are solid, but timetables deliberately contain recovery allowance, so a train eight minutes down at mid-route often arrives three down, and naive projections overstate delays. What no engine can see coming: a points failure, a medical emergency, a crew connection missed two stations back. Treat any delay figure as a rolling estimate, tightest within the next half hour.

07

What live tracking does not know about you

The subject of all this monitoring is the train, never you. A vehicle feed carries a service identity, coordinates, bearing, delay and occasionally crowding estimates derived from bookings or weight sensors. There are no names in it, no seat numbers, no phones. A tracking site does not know you are aboard, and it works perfectly with your phone's location switched off; granting location merely sorts nearby stations to the top. Nothing links the map to your ticket purchase, which lives in a separate retail system. The exception is the one you opt into: crowdsourced check-in apps, where you volunteer your position to improve someone's dataset. Payment details never enter tracking pipelines at all. When trainstracking.com ingests data from 76 operators and 19 realtime APIs, the payload is train identities and geometry, full stop. If a service claims it needs your contacts or precise location to show a departure board, that is a product decision, not a technical requirement.

FAQ

Frequently Asked Questions