Real-Time Data vs. Timetable Data: Why Every App Shows Something Different

Updated: August 2026 – You open two apps, search for the same train – and get two different positions and two different delays. The difference between real-time data and timetable data explains almost every one of these discrepancies. This article goes deeper than the usual explanation: we look at the data layers, at report points and interpolation, and at which display you should trust in which situation.

The difference in two sentences

Timetable data describes the plan; real-time data describes reported events from live operations. Everything you see in an app as a minute figure is a third thing: a forecast calculated from the plan and the last actual-time report.

This three-way split is the key to the whole topic. Anyone who only thinks “timetable versus real-time” doesn’t understand why a delay suddenly jumps by four minutes, or why a train sits on the map at a spot it demonstrably isn’t. The answer is almost always: you’re seeing a calculation, not a measurement.

Data type	What it contains	How it’s created	Typical weakness
Timetable data (planned)	Workings, stops, planned times	published in advance, often annually	knows nothing about today’s disruption
Actual-time reports	actual passing of an operating point	from the operator’s operations system	only at report points, not in between
Forecast	expected times at following stops	calculated from plan, actuals and operating rules	jumps with every recalculation
Map position	symbol on the route map	interpolation between two reports	looks more precise than it is
Cancellation/platform report	operational decision	set by the control centre	sometimes reaches third parties with delay

How timetable data is structured

Static timetable data describes a network of stops, lines and workings with their planned times. The most widespread exchange format for this is GTFS – a set of simple tables in which each working consists of a sequence of stops with arrival and departure times.

Two properties matter for understanding this:

• Timetable data is complete, but old. It knows every scheduled working for the whole year, but nothing about this morning’s disruption.
• It contains no positions. A timetable says when a train should stop where – not where it is between two stops.

That’s exactly why a pure timetable display at a station is so stable, and at the same time so useless when something goes wrong. It’s the printed board in digital form. How differently transport associations handle this is shown in the overview of regional transport associations and their live departures.

How real-time data is generated in rail traffic

This is where the biggest difference from buses lies. A bus locates itself via a GNSS receiver and reports its position at short intervals – the mechanism behind this is explained in the guide on how GPS bus tracking works. Rail operations work differently: there, actual-time data classically arises from operational events at operating points – stations, junctions, block posts. When a train passes such a point, an actual-time event with a timestamp is created.

An important property follows from this: between two report points there is no new information. On a line densely packed with operating points in a conurbation, the gap is small; on a long stretch without intermediate stops it can be considerable. That’s exactly where map displays are at their least accurate.

GTFS-Realtime, SIRI and the VDV interfaces

Several standards exist for passing on this actual-time data. GTFS-Realtime extends the static timetable with three types of update: trip updates with delays, vehicle positions and service alerts. In German-speaking countries, the interfaces of the Association of German Transport Undertakings and SIRI are also common, coming from the public transport world and serving similar purposes.

For you as a user, this mainly means one thing: not every app gets the same fields. Some sources only supply delay values, others also positions, and others still detailed service alerts. So the differences between displays begin before the app itself.

Interpolation: why the map lies without lying

When an app smoothly moves a train across the map, it’s doing that almost never based on live position reports. It knows two points – the last actual-time report and the next expected stop – and calculates the bit in between linearly or with a route model.

Three typical effects follow from this:

1. The train “jumps”. When a new actual-time report arrives and the train is further along, or less far along, than estimated, the display corrects itself abruptly.
2. The train “stands still”. If a report fails to arrive, the position freezes – but the train keeps moving.
3. The train appears to move too smoothly. Interpolation knows nothing of speed restrictions, overtaking moves or signal stops.

Anyone who knows these three patterns reads map displays correctly: as orientation, not as tracking. That applies to all the common tools, as the comparison of the best train radar tools shows.

Why two apps interpolate differently

Interpolation isn’t a fixed quantity, it’s an assumption. A simple implementation spreads the distance between two report points evenly over time – the train then moves at a constant calculated speed, even though in reality it accelerates, brakes and might be standing at a signal. A more elaborate implementation takes into account the route layout, permitted speeds and the planned running-time profile. Such route models mostly come from planning software, such as that developed by the PTV Group.

Both approaches are legitimate, but inevitably lead to different symbol positions for the same working. On top of that comes the polling cycle: if one app fetches new data every 15 seconds and another every 60, they show different states purely because of that. Neither is faulty as a result – they’re telling the same story at different resolutions.

This matters most in practice in two places: on long sections without intermediate stops, and during diversions. If a train runs over a route that isn’t stored as its planned path in the route model, the projection can be completely off – the symbol then wanders along the planned route while the train is running somewhere else entirely.

Timetable display or real-time display – which is better?

The practical answer is: timetable data for planning, real-time data on the day of the trip. Anyone putting together a spotting tour for next Saturday works with the planned timetable. Anyone standing at the spot on Saturday looks at the actual and forecast values – and keeps in mind that they can still change.

Which display should I believe, and when?

For that last case: freight traffic systematically barely appears in journey planners, because it isn’t part of the passenger timetable. How to track it anyway is described in the guide to tracking freight trains live.

How to work cleanly with both data types

What to watch out for

• A position isn’t tracking. Between two report points, every app shows an estimate, no matter how smoothly the symbol moves.
• A delay isn’t a measurement. The minute figure is a forecast that’s allowed to change with every new actual-time report.
• Differences between apps aren’t an error. Different polling intervals, forecast models and data scopes inevitably lead to different displays.
• Missing data doesn’t mean cancelled. Especially outside passenger traffic, many workings exist for which simply no public actual-time reports are published.
• During disruptions, the operator’s source counts. Operational decisions such as platform changes or cancellations originate there and reach third parties with a delay.
• Safety stays independent of data. No forecast, however precise, justifies staying in the track area – operational railway land is off limits, always.

Conclusion

The argument “timetable or real-time” misses the actual point: both describe different things, and only come together through a third layer – the forecast. Anyone who understands that actual-time reports are generated at operating points and everything in between is calculated can make sense of any discrepancy between two apps without despairing over either one. For spotters, that means concretely: plan with timetable data, adjust with actual-time data, work with a buffer, and treat your own observation as an independent source. What this feels like day to day is also shown in the guide on how to follow a moving train, the instructions for long-distance traffic on tracking the ICE live, and for choosing tools the overview of live tracking for trains and buses.