God's Eye View: what is live, what is delayed, and what is only animation?

In God's Eye View, a plane glides across the globe. Cars stream through a city. A rocket climbs into space. It all moves, so it all feels live. But only some of it is close to live. Some of it is shown a little late on purpose. And some of it is just animation.

We wanted to know which is which. The idea came from Bilawal Sidhu's demonstration with Matt Wolfe. We looked at how the free public version handles planes, camera pictures and moving traffic. We read the code and ran three small tests of our own.

This is the fourth article in our series on God's Eye View. Earlier we wrote about what it does and what you need and what you may share in screenshots and video.

Three things that all look "live"

When something moves on screen, three different clocks are at work. We keep them apart in this article.

• How often the app asks. The app asks for new data on a schedule, for example every 30 seconds.
• How old the answer is. The data source may send a position from half a second ago. Or it may send a camera picture that last changed minutes ago. The code cannot tell you this. You have to measure it.
• What the app does in between. To avoid jumpy movement, an app can wait. It can draw a smooth line between two known points. Or it can animate something that was never measured at all.

Smooth movement alone tells you none of these times.

Planes: real positions, shown one step behind

In the video, Matt Wolfe asks how up to date the planes are. Sidhu answers, in our own words: the screen runs one step behind, so planes can follow a smooth path (around 8:40). That matches what we found.

The app asks for normal (civil) flights every 30 seconds. It asks for military planes every 15 seconds. Then it draws every plane one step behind real time. The setting is called RENDER_DELAY_SEC. It is 30 for civil flights and 15 for military ones. With two known positions, the app can glide a plane from one to the other. It does not have to guess where the plane is now.

The project's README, its main help file, says this openly: "Live feeds arrive every 15–30s; the globe renders one interval behind real time and interpolates between known fixes. Dead reckoning fills the gaps." Dead reckoning means guessing a position from the last known speed and direction. The code only does this for short gaps: one minute as a rule, five minutes at most.

So how old is the data itself? We tested the military layer for six minutes on 17 September 2026. This layer only uses one source, adsb.lol. The app got 26 answers, about one every 15 seconds. Each answer had 415 to 444 planes.

Two numbers matter here, and you add them up. First, each answer says how long ago each position was updated. The middle value was 0.3 to 0.5 seconds. Second, the answer needs time to reach the browser. For 21 of the 26 answers, a typical position was about one second old when it arrived, between 0.8 and 2.2 seconds. Every answer also had some positions up to a minute old. These numbers depend on our laptop's clock. When we checked afterwards, it was within a tenth of a second of internet time.

So for most of this short test, the data was much fresher than the 15 seconds the app adds on purpose. But not always. For the other 5 answers, the app's server sent the same, older answer again. Then a typical position was 15 to 45 seconds old when it arrived. This happened twice, for about half a minute each time. The app noticed. Its layer panel changed from "just now" to "STALE · adsb.lol · 18s ago", then 33 and 48 seconds. We did not cause this, and we cannot say why it happened. But we can say the warning worked.

We did not turn on the civil flights layer in this test. It uses the OpenSky Network. We describe OpenSky's rules in our third article. OpenSky sent a short reply to our questions, but did not answer them one by one. The code shows that the app normally keeps OpenSky's answer for 9 seconds. When the free daily allowance runs low, it keeps it for up to 5 minutes. When OpenSky's data is more than two minutes old, the app switches to adsb.lol. We did not measure any of that.

Some things you see are not based on the flight data this app uses. The cockpit view uses a fixed camera angle. We found no data anywhere in the flight code on whether a plane points its nose up or down, or leans sideways. The 3D planes turn to face the way they fly. But we found nothing in the code that leans them over in a turn.

Cars: the dots are always animation

This layer looks the most real, but it is the least real. In his own tour of the app, Wolfe says the traffic layer shows where cars are driving right now (around 18:35). That is easy to think when you look at the screen. But earlier in the same video, Sidhu explains what is behind it. TomTom tells the app how busy each piece of road is, and he colours the roads to match (around 10:55). The code supports Sidhu's description.

No dot on the map is a real car, with or without a key. The README says it plainly: "Simulated vehicles on OSM roads. With TomTom, live flow speeds drive the simulation and congestion colors below ~8 km; individual vehicle positions are not live observations."

Here is what is real and what is not:

The code says each dot is put "at a random position along the road" with "a randomized speed". It also stops dots near the end of a road "to simulate stop-light behaviour".

The app does label this. Without a key it shows a banner: "SIMULATED — ADD TOMTOM KEY FOR LIVE". You can see it in our cover image. We do not have a TomTom key, so we did not test the live mode.

Our own test showed something else. Even fake traffic needs real road data. That data comes from free community servers for OpenStreetMap. On the evening of 17 September 2026, those servers did not answer the app in any of our three tries. The app said "Road data temporarily unavailable" and drew no dots at all. That is why our cover image shows a label but no traffic.

Update, 4 October 2026. Version 0.2.0 of God's Eye View came out on 2 October. By default, it no longer uses the public Overpass servers (the free road-data servers above) for street traffic. The project's list of changes says roads now come from TomTom traffic data, from OpenFreeMap, or both. When something fails, the app now names the source that said no. We tested the earlier version. We have not tested this change yet.

Cameras: reloaded every 10 seconds, changed every few minutes

In the video, Sidhu says the public cameras in Austin send about one picture every ten minutes. He only says this about Austin (around 10:27). We could not find anywhere in the project how often Austin sends new pictures. So we measured it.

First, the app's side. When you pick a camera, the app reloads its picture every 10 seconds. When you do nothing, it reloads every 60 seconds. The small camera cards around the map reload every 3 to 10 minutes, depending on the provider. The project only knows the rhythm of one provider: Fintraffic in Finland, which sends a new picture every 600 seconds.

Then, the source's side. On 17 September 2026 we asked the app for the same pictures it shows. We did this every 30 seconds for 30 minutes. We used two cameras each in Austin, London and Finland. For each picture file, we only kept a fingerprint in memory: a short code that changes when the file changes. We stored no pictures and did not look at them.

For five of the six cameras, the picture file changed about every five to ten minutes. Between two changes, every check gave a file with the same fingerprint. With a reload every 10 seconds, that is about 30 reloads per change for Austin camera 2 and London camera 1. For Finland it is about 60.

We want to be exact about what this shows. A changed file tells us the provider sent something different. It does not tell us when the picture was taken. A change might also be in the file's data and not in the scene. And we cannot see if a cache, a stored copy somewhere between the camera and the app, changed the rhythm. So we measured how often the file changes, not how old the picture is.

Finland matched its known 600 seconds. That gives us some trust in our method. For one Austin camera, we saw no change in half an hour. We do not know if it was frozen, being repaired or just slow. The project's own code notes something similar from July. In five minutes, a London camera sent a new picture once, and an Austin one not at all.

We found about 5 minutes for one Austin camera. The video mentions about 10 minutes. That does not make either number wrong. We checked two cameras for half an hour, and a city can change its settings.

Two more things are good to know. The project says pictures are fetched when you look, and are never stored. The picture we checked was marked "no-store", an instruction not to keep a copy. And where a camera points is a guess: the README calls the camera positions "estimated priors" that you can adjust yourself.

Rockets and satellites: real events, calculated paths

The launches in the Space Missions view are real. They come from Launch Library 2, a public list of rocket launches. But the path you see in a replay is not a recording. The project's help pages say Launch Library 2 "supplies launch context and event timing, not continuous ascent telemetry or live orbital state". In plain words: it gives the launch details and times, not the rocket's real path. The app draws a likely climb. Then it draws a ring at a standard height for that type of orbit.

Sidhu says this in the video too. He calls the path approximate (around 12:50). Even better, the app says it on screen. In our screenshot, the mission panel says "ASCENT PATH · RECONSTRUCTED ESTIMATE". The label on the globe says "PROJECTED ORBIT".

Satellites work in yet another way. The app does not get live position reports for them. Instead, it works out where each satellite is from published orbit data. It gets that data from CelesTrak. Then it calculates each position itself, many times a second, with a standard method. The orbit data is updated every six hours. That is normal for satellite trackers.

How to read the screen

• Open the data layers panel. Every layer shows where its data comes from and how long ago it was updated, like "CelesTrak · 44s ago". That line tells you more than the movement does.
• Look for the app's own warning words: SIMULATED, STALE, UNAVAILABLE, ESTIMATE, PROJECTED. In our tests, they showed up when they should.
• Movement between updates is drawing, not data. A plane gliding smoothly is the app joining two known points.
• Think of cars as a weather map for traffic. The colour and number of dots can be real. Single dots never are.
• A reload is not a fresh picture. A recent reload does not tell you when the picture was taken.
• Be careful with words like "real time" in a caption or a video. The app shows normal flights 30 seconds late on purpose, and military flights 15 seconds late. The data can be older still. For cameras, "a still from a public camera" says enough.

How we checked

We read the project's README, its DATA_SOURCES.md file and its code at version 531ef52. We link to the files we quote. Settings in code can change with any update.

For the video, He Built The Ultimate Spy Tool (Free and Open-Source), we used YouTube's automatic captions. Matt Wolfe published it on 16 September 2026. The video has no other captions. Automatic captions contain mistakes, so we do not quote them. We describe what is said in our own words and link to the moment. The times are approximate.

We worked out who is speaking from what is said and from the video description. In the description, Wolfe writes that he shows the installation himself. For that part we also used the picture, which shows one presenter using the app. Before publishing, we listened again to the five moments we mention. We checked both the speaker and what was said. Where something is said by Wolfe and not Sidhu, we say so.

We ran our tests on 17 September 2026, on the Windows laptop described in our first article. For the flight test, we turned on only the military layer, for six minutes. For each answer we wrote down two values. The first was the age the data gives for each position ("seen_pos", counted back from the moment the answer was made). The second was the time from that moment until the answer reached our browser. We added the two. The second value depends on our laptop's clock.

For the camera test, we asked the app for six cameras every 30 seconds for 30 minutes. We compared fingerprints of the picture files. No picture was stored or viewed. Two changes within 30 seconds of each other would have counted as one. Before the test, we read the rules of the three camera providers: the City of Austin's open data terms, Transport for London's open data terms and Fintraffic's CC BY 4.0 licence. These results come from one evening, two cameras per provider and one laptop. They are not a full test score.

We took the screenshots ourselves on 17 September 2026, without any API keys (access codes for paid data services). We only made them smaller, except for the two cut-outs from the cover screenshot. We drew the charts from our own measurement files. The two diagrams are our own explanations. None of the images is AI-generated. We took the provider names in the captions from the app's Data attribution panel.

Our review covers planes, street traffic, cameras, launches and satellites. It does not cover the civil flights layer in practice, the TomTom live mode, ships, or the event replays shown in the video. This is an editorial review of the sources we read and the tests we ran.