How Belgium’s Live Transit Map Actually Works

At 7:48 on a wet weekday morning, a map full of tiny moving symbols can feel like a window into the whole country. You see a bus edging toward a stop in Flanders, a tram crossing Brussels, and a train moving between cities. The picture looks effortless. The data behind it is not.

ovlive brings De Lijn, STIB-MIVB, TEC, and NMBS/SNCB into one map, with stops, schedules, delays, and vehicles. But the word “live” needs a footnote: some markers come directly from an operator’s position feed, while others are calculated from a timetable and a reported delay. That small distinction is the key to reading a live transit map well. (openbaarvervoerbelgie.be)

One country, four data languages

Belgium’s public transport network is divided among several operators. De Lijn covers buses and trams in Flanders, STIB-MIVB runs Brussels buses, trams, and metro lines, TEC serves Wallonia, and NMBS/SNCB operates the national railway network. A single map has to bring all four systems together even though each organization maintains its own operational data. (data.belgianmobility.io)

The common language is GTFS, short for General Transit Feed Specification. It is an open data format for describing public transport. A basic GTFS schedule is a collection of text files packed into a ZIP archive. Those files describe agencies, routes, stops, trips, stop times, and service calendars. In other words, they explain what should happen on a normal day, without showing what is happening this minute. (gtfs.org)

The Belgian Mobility data catalog currently presents daily-updated static GTFS feeds for the four major operators. That gives a map a dependable skeleton: where the lines run, which stops they serve, and when each trip is scheduled to arrive. The map still needs another data layer before it can show delays or disruptions.

Two clocks: the timetable and reality

That second layer is GTFS Realtime, often shortened to GTFS-RT. It carries changes to the scheduled picture, including predicted arrivals, cancellations, service alerts, and vehicle positions. The data is encoded with Protocol Buffers, a compact binary format designed for fast transmission between a server and an application.

A trip update might say that a bus is expected at a stop five minutes late. A service alert might say that a station is closed or a route has been diverted. A vehicle-position update can provide the latitude and longitude of the vehicle itself. These are different kinds of information, and a well-built map keeps them separate instead of pretending that every delay is a precise GPS reading.

The Belgian catalog lists the main GTFS-Realtime feeds as updating every 30 seconds. That is the feed refresh interval, not a promise that every dot on screen is exactly 30 seconds old. The vehicle may report late, the operator may publish a prediction rather than a position, or the data may be temporarily missing.

Why every dot is not a GPS dot

Is the bus dot on a live transit map really live? Sometimes. ovlive explains that STIB-MIVB and TEC publish real-time vehicle positions, so those vehicles can be shown directly. De Lijn and NMBS/SNCB provide timetable and delay information rather than the same kind of vehicle-position feed, so their markers are calculated from the schedule and corrected with the delay data that is available.

Imagine a train scheduled to travel from one station to the next between 08:10 and 08:22. At 08:16, a five-minute delay suggests that the train may be roughly where the timetable expected it to be at 08:11. A map can place the marker along the railway path at that estimated point. It is useful, but it is still an estimate.

A simplified version of that calculation might look like this:

function estimatePosition(trip, nowMs, delaySeconds = 0) {
 const scheduleNow = nowMs - delaySeconds * 1000;
 const leg = trip.legs.find(
 leg => scheduleNow >= leg.startMs && scheduleNow <= leg.endMs
 );

 if (!leg) return null;

 const fraction =
 (scheduleNow - leg.startMs) / (leg.endMs - leg.startMs);

 return interpolateAlongShape(leg.shape, fraction);
}

The function first moves the current time backward by the reported delay. It then finds the section of the route where the vehicle should be and calculates how far through that section it has progressed. interpolateAlongShape would place the marker along the line geometry. The result can look wonderfully smooth on a map, but it should be labelled as calculated rather than observed.

The difficult join happens underneath

A real-time feed does not usually contain everything needed to draw a map. It refers back to the static schedule using identifiers such as a trip ID, route ID, or stop ID. The application must match those identifiers to the correct operator, route, trip, and geometry before it can update the right marker. GTFS documentation also makes an important distinction: when a trip update is missing, that means real-time information is unavailable. It does not prove that the vehicle is running on time. (gtfs.org)

A practical pipeline looks something like this:

• Load the latest static GTFS schedules and route shapes.
• Poll each operator’s real-time feed on its own schedule.
• Match live updates to the correct agency and scheduled trip.
• Mark each vehicle as directly observed, calculated with delay, or calculated from schedule alone.
• Draw the result over a background map, such as OpenStreetMap.

That last label is more important than it may seem. It tells the person looking at the map how much confidence to place in a moving dot. A direct position is evidence of where a vehicle reported itself. A calculated position is a helpful model of where it is likely to be.

How to use the map without overtrusting it

The most useful habit is to read the legend before reading the vehicles. On ovlive, the three statuses make the difference visible: Live means the operator supplied a position, Calculated + delay means the route has been adjusted using a reported delay, and Calculated means the marker follows the schedule without a real-time correction. (openbaarvervoerbelgie.be)

The map is an independent project, not the official app of any Belgian transport operator. For tickets, fares, customer service, or travel information that must be guaranteed, the operator’s own channels remain the authoritative source.

The larger lesson reaches beyond Belgium. A live map is not one magical stream of truth. It is a careful conversation between schedules, updates, geometry, identifiers, and uncertainty. Once you know which parts are measured and which parts are inferred, the moving dots become more useful—and much easier to understand.