Blog · Maps & technology

Real-time maps: what 'live' really means when you look at a map

Open the map →

"Live." "In real time." "Updated now." These are among the most used -- and most poorly understood -- phrases on the internet. When you look at a real-time map with aircraft crossing oceans, ships entering port and traffic cameras blinking, it is natural to assume that everything you see is happening exactly now. The truth is more nuanced and, frankly, more interesting: every piece of data on that map arrives with its own delay, its own cadence and, sometimes, a dash of estimation. This article is an exercise in transparency: we want you to understand what "live" truly means, because a user who understands the data gets more from it and is less easily misled.

"Live" is a spectrum, not a switch

The first shift in thinking: real time is not a yes or a no -- it is a scale. On a single map, layers with radically different tempos can coexist:

• Aircraft and vessel positions: on the order of seconds. Aircraft broadcast their position continuously via ADS-B (on the 1090 MHz frequency) and ships via AIS; networks of ground receivers pick up those signals and serve them with small delays.
• Traffic cameras: from seconds to minutes, depending on the source. Each authority decides how frequently it publishes a new frame from each camera; there is no single universal standard.
• Satellite layers: days or months. As explained in free satellite imagery, the satellite mode of any map is a mosaic of past photographs, not a live feed.

Three layers, three clocks. Every data source has its own tempo, and a good live map is not one that pretends everything is instantaneous, but one that shows each layer at the real rhythm its source allows.

Where latency comes from: the data chain

Why is no data instantaneous? Because between an event and your screen there is a chain, and every link adds its own delay:

1. The sensor: the aircraft transponder, the ship's AIS equipment or the camera captures and broadcasts the data. There is already a first interval here: the sensor transmits at set intervals, not continuously.
2. The receiver network: ground antennas (many operated by enthusiasts) pick up the signal and forward it over the internet.
3. The aggregator: a service collects data from thousands of receivers, removes duplicates, discards errors and assembles a coherent picture. This processing takes time.
4. The map server: prepares the data to serve thousands of simultaneous users.
5. Your screen: your browser requests or receives the updates and renders them, with its own refresh cycle. How this final stage works is covered in how online maps work.

Adding up all the links, the full journey can range from a few seconds in the best case to several minutes in others. That total time is called latency, and it is inevitable: it can be reduced, never eliminated.

Open the map →

Cadence is not latency (and confusing them leads to mistakes)

Here is the nuance that almost nobody explains and that causes the most misunderstandings. They are two distinct concepts:

• Latency: how long it takes a data point to arrive after it was generated. "This image was captured 40 seconds ago."
• Cadence: how often a new data point arrives. "This camera publishes a new frame every minute."

And they can combine in any way. A camera can refresh every minute with only seconds of delay: you see few images, but very fresh ones. The reverse is equally possible: an aircraft can appear to move smoothly across your screen even though its actual positions arrive at intervals, because the map interpolates -- it calculates where the aircraft should be between two receptions, using its known heading and speed, and slides it smoothly along that estimated trajectory.

Interpolation is legitimate and universal -- without it, aircraft would advance in jerky jumps -- but it is worth knowing it exists: part of what you see moving "live" is a reasonable estimate between two real data points. When the next actual position arrives, the map corrects. Almost always the adjustment is imperceptible; occasionally you see an aircraft "teleport" slightly -- you have just caught the interpolation correcting itself.

Why two websites show the same aircraft in different positions

Try the experiment: open two flight-tracking services and look up the same aircraft. It will most likely appear at slightly different positions. Which one is wrong? Probably neither.

Each service has its own receiver network (one may have an antenna near that aircraft while the other does not), its own update cadence to your browser and its own estimation rules between data points. The result: two snapshots of the same reality taken with different cameras, clocks and assumptions. The same happens with ships, often more so, because AIS coverage varies considerably between coastal and satellite receivers.

Two maps that differ by a few hundred metres on a cruising aircraft are not contradicting each other: they are complementing each other. The discrepancy is latency made visible.

The practical lesson: if you need precision, do not rely on a single source, and always check the timestamp on each data point before making comparisons.

Open the map →

How to evaluate the honesty of a "live" service

As a user you have the right to know what you are looking at, and three questions separate honest services from those that sell smoke with the word "live":

1. Does it show timestamps? An honest service tells you when each data point was generated: the time of the frame, the seconds since the last position. If there is no timestamp anywhere, be sceptical -- the service is asking you to assume freshness without demonstrating it.
2. Does it declare its sources and cadences? Where does the data come from? How often does it update? A serious service documents this somewhere accessible, rather than hiding it behind marketing language.
3. Does it distinguish data from estimation? When a position is interpolated or a data point is stale, does the service signal this in some way, or is everything presented with the same visual confidence?

These three questions work for flight maps, ship maps, traffic maps or anything else advertised as "real-time." They also work in reverse: as design criteria for anyone building these services.

The Argos Atlas approach: each source at its own pace, with its name shown

This section is very much an in-house matter, so it is only fair to apply the same standard to ourselves. The Argos Atlas approach to real-time data comes down to two commitments: showing each source at the cadence the source itself allows, and always citing the origin of the data.

In practice that means aircraft and vessel positions update at the rhythm their open-data sources permit; each public traffic camera shows the latest frame published by the relevant official authority, at the cadence that authority decides -- which varies from one source to another, and that variation is acknowledged rather than glossed over; and satellite mode is presented for what it is, visual context for the terrain and not a live video feed. All of this with the source cited, without facial or licence-plate recognition, and without storing any image history.

This is not a list of virtues to boast about: it is exactly the transparency standard we just asked of any service. You can verify the details on the sources and methodology page, where every layer's origin is documented.

The intelligent live-map user

We close with the habit that changes everything and costs nothing: looking at the timestamp before drawing conclusions. It is the difference between "there is a traffic jam on the motorway" and "four minutes ago there was a traffic jam on the motorway." Between "the ship is in port" and "the last position received, half an hour ago, placed it in port."

For everyday use -- browsing, planning, learning -- the distinction barely matters. But there is one domain where it is absolutely critical: verification. When a camera image or a map position is used to confirm or refute that something is happening -- an incident, an event being discussed on social media -- the timestamp is half the evidence. A genuine image with a misread time produces false conclusions that look like truth. How journalists use live cameras precisely for this purpose is explored in live cameras and journalistic verification.

The intelligent live-map user is not someone who distrusts everything, but someone who knows what they are being shown: a fresh data point with a known delay, from an identified source, at a declared cadence. With that, the map stops being a spectacle and becomes a tool.

Frequently asked questions

Does "live" mean instantaneous?

No. Every live data point carries latency: the travel time from sensor to receivers to aggregator to server to your screen, where each link adds its share. At best we are talking seconds; in other cases, minutes. "Live" means "the most recent that the source's chain allows", not "at this exact instant." The distinction seems pedantic until the day it matters.

Why do two websites show the same ship in different positions?

Because they work with different sources, cadences and estimation rules. One may be receiving the signal from a closer receiver and have fresher data; the other may be interpolating the position between two receptions using heading and speed. Neither is necessarily lying: they are two snapshots of a moving reality, taken with different clocks. If you need precision, compare timestamps, not just positions.

How often does a real-time map update?

There is no single answer, because every layer has its own tempo. Aircraft and vessel positions typically refresh in seconds; traffic cameras publish new frames at intervals each authority sets, ranging from seconds to minutes; satellite layers renew with days or months between versions. An honest map shows each layer at its source's actual rhythm rather than promising a uniform freshness that does not exist.

How do I know whether I can trust a live data point?

Apply three checks: does the service show timestamps on its data? Does it publicly declare its sources and cadences? Does it distinguish in some way between received data and estimated positions? A service that answers well on all three gives you the elements to judge for yourself. One that evades them is asking for blind faith, and blind faith is not a sound data policy.

Conclusion

"Live" is neither magic nor a lie: it is a chain of sensors, networks and servers that brings the present to your screen with a small, known and honest delay -- when the service does its job well. The keys to reading it with informed judgment fit in one hand: every data source has its own tempo, latency is inevitable, cadence and latency are different things, interpolation exists and the timestamp is your best friend. If you want to see how all of this applies layer by layer -- which source feeds each data point and at what rhythm -- you can open the map and judge for yourself. That is exactly how it should be possible to assess any map that claims to be real-time.