God’s Eye View: How an Open-Source AI Turns Public Data Into a Live 3D Earth
God’s Eye View: How an Open-Source AI Turns Public Data Into a Live 3D Earth
At first glance, God’s Eye View looks like something taken straight out of a military intelligence command centre.
A photorealistic Earth fills the screen. Aircraft move across the sky, ships travel through the oceans, satellites circle the planet, and earthquakes, weather systems and public cameras appear across the globe. The interface combines these elements into a cinematic, interactive 3D environment that feels more like an intelligence console than a conventional mapping application.
Then comes the interesting part: much of the information comes from publicly available data.
Created by Bilawal Sidhu and maintained with Sameh Khamis at Halfpixel, God’s Eye View is an open-source project that brings geographic information, live data feeds and AI-powered interaction into a single browser-based experience.
Rather than building a secret surveillance network, the project demonstrates what becomes possible when information from independent public sources is combined and presented on one interactive globe.
The result is a new way to explore the physical world — and a compelling example of how artificial intelligence, geospatial computing and open data can work together.
What Is God’s Eye View?
God’s Eye View is a browser-based 3D geospatial visualization platform built around a photorealistic globe.
Its purpose is straightforward: bring different kinds of geographic information into the same environment so users can explore them together.
Aircraft become moving objects. Ships become maritime contacts. Satellites occupy orbital paths. Earthquakes appear as geographic events. Fires and weather systems become environmental layers. Public cameras and infrastructure can be explored in their physical context.
The project combines these layers instead of requiring users to switch between separate tracking websites and mapping tools.
Its official GitHub repository describes the experience as an explorable globe that brings public signals together, allowing users to move between a global overview and individual aircraft, ships or locations.
That is the central idea behind the project: turn scattered public information into a shared spatial interface.
Why Does It Look Like a Military Intelligence Console?
One reason God’s Eye View attracted attention is its visual presentation.
Instead of looking like a standard map, the application uses cinematic 3D terrain, tracking overlays, information panels, object trails and tactical-style visual effects.
The project includes a cockpit view for tracked flights, nearby-object tracking, metadata panels and visual modes inspired by CRT displays, night vision, thermal imaging and monochrome surveillance interfaces.
Some features are designed to make the experience feel closer to a simulation environment. Users can follow a tracked aircraft from an onboard perspective, inspect nearby contacts and switch between different rendering styles.
These features are part of the project's visual and interaction design. They should not be mistaken for evidence that the application has access to classified sensors or military intelligence.
The underlying information comes from documented data providers and geographic datasets.
For developers interested in how the experience is assembled, the repository’s README provides the project's feature overview and technical context.
The Real Technology Is Data Fusion
The globe is the part people notice first. The more interesting engineering challenge is bringing together information that was never designed to live in the same application.
Aircraft tracking, maritime data, satellite positions, weather forecasts and earthquake records all have different formats, update schedules and limitations.
God’s Eye View connects these sources to separate geographic layers and presents their information through a common visualization system.
Its data-source documentation identifies sources and attribution requirements for many of these layers, including NOAA weather products, ECMWF forecasts, USGS earthquakes, NASA fire information, aircraft feeds, satellite orbital data and other geographic services.
This architecture matters because the application is not dependent on one enormous database.
Instead, it combines specialized sources, each responsible for a different part of the picture.
The difficult work is coordinating their data, representing it accurately, handling missing information and making the resulting scene useful to explore.
Aircraft Tracking: From a Marker to a Cockpit View
Aircraft are among the most immediately recognizable objects on the globe.
God’s Eye View can display tracked flights, let users select aircraft and present additional information when the necessary data is available.
The project documents aircraft sources including OpenSky Network and adsb.lol. These services provide aircraft-related information from their respective data networks and have different coverage and limitations.
The application can also move beyond the familiar overhead tracking view. Its cockpit mode follows a selected aircraft from an onboard-style perspective, keeping the surrounding terrain in view.
The project includes nearby-contact functionality that can show tracked objects around a selected target, creating a more immersive way to explore movement through the airspace.
However, public flight data is not a guarantee that every aircraft will be visible or correctly identified. Coverage, transponder availability, data quality and provider restrictions can affect what appears.
The experience is therefore best understood as a visualization of available aircraft information rather than a complete picture of global aviation.
Ships and Maritime Movement
Aircraft are only one part of the system.
God’s Eye View also supports maritime information, allowing vessels to appear alongside other objects on the globe.
One of the documented providers is AISStream, which offers access to AIS-based vessel data.
AIS, or Automatic Identification System, is used by vessels to broadcast information that can help other ships and maritime services understand their positions and movements.
By placing maritime contacts into the same geographic environment as aircraft, satellites and environmental events, God’s Eye View makes it easier to explore different forms of movement together.
This is a simple but important shift in how the information is presented.
An aircraft tracker usually focuses on the sky. A vessel tracker focuses on the ocean. God’s Eye View treats both as layers of the same world.
As with aircraft, vessel visibility depends on the availability, freshness and accuracy of the underlying data.
Satellites Add Another Dimension
The application also extends beyond the Earth's surface.
God’s Eye View uses orbital information from sources such as CelesTrak to represent satellites around the planet.
Satellite positions can be calculated from orbital elements using propagation methods such as SGP4. This turns published orbital information into a representation of where a satellite is expected to be at a given time.
The result is a globe where users can move between roads, cities, aircraft, ships and objects in orbit.
Satellite visualization is not the same as receiving live imagery from every satellite. Orbital tracking and satellite observation are different capabilities, and the application should not be interpreted as having direct access to every spacecraft’s sensors.
That distinction becomes especially important when a realistic interface makes calculated positions look like direct observation.
Earthquakes, Fires and Environmental Events
Not every layer represents a moving vehicle.
Some layers represent events that happen at particular locations.
God’s Eye View can display earthquake information from the USGS Earthquake Hazards Program and active-fire information from NASA FIRMS.
These sources serve different purposes. USGS distributes earthquake information, while NASA FIRMS provides active-fire detections based on satellite observations.
Presenting them on the same globe makes it possible to explore environmental events alongside transportation and infrastructure.
The broader idea is that geographic location becomes a common reference point for information that would otherwise remain scattered across different systems.
A plane is a moving object. An earthquake is an event. A fire is an environmental observation. All can be represented within the same spatial environment.
Weather and Recent Satellite Imagery
Weather adds another layer to the application.
The project's data documentation includes forecast wind information from the NOAA Global Forecast System and ECMWF Open Data, alongside observed weather products such as radar and satellite imagery.
These sources do not all describe the same thing. A forecast represents modeled future conditions, while radar and satellite products represent observations or derived products from particular times.
That distinction matters when interpreting the globe.
Recent satellite imagery adds another way to explore geographic information. The project's changelog documents a Recent Imagery layer using NASA GIBS products, including imagery associated with Sentinel-2, Landsat and VIIRS.
Depending on the selected source and layer, users can examine imagery and compare different dates or views.
This creates a workflow that goes beyond watching moving objects: locate an area, inspect the imagery and compare what is available across time.
The imagery is still subject to the resolution, coverage, acquisition times and processing limitations of the original dataset.
Public Cameras and Geographic Infrastructure
God’s Eye View also incorporates public-camera locations and other geographic infrastructure.
The project's data documentation describes camera information that can be placed into the 3D environment. Camera positions and orientations may be estimated or calibrated, so a marker should not automatically be interpreted as an exact representation of a camera’s field of view.
The repository also documents an optional ALPR camera-location layer based on OpenStreetMap information.
That is an important distinction: displaying a mapped camera location is not the same as accessing its video feed, retrieving license-plate records or confirming that the camera is currently operating.
The project’s data-source documentation is the appropriate reference for understanding what a particular layer represents and where its information comes from.
What Is Actually Live?
This is one of the most important questions to ask about God’s Eye View.
The interface is realistic enough that it can be tempting to assume everything on screen is a precise, live observation.
That would be incorrect.
According to the project's own documentation, most feeds are live or regularly refreshed, but some experiences are modeled or estimated. Traffic can be simulated along real roads using aggregate location data. Camera positions and orientations can be approximate. Rocket-launch trajectories may be reconstructed estimates rather than live telemetry.
These are different kinds of information:
Live or refreshed data: Information retrieved from a source and updated according to its refresh schedule.
Calculated data: Values derived from available inputs, such as satellite positions calculated from orbital elements.
Estimated data: Values inferred or approximated when exact information is unavailable.
Simulated data: A model used to represent behavior without directly observing every object.
Reconstructed data: A representation created from available information about an event.
A realistic animation does not automatically mean the underlying information is live.
God’s Eye View explicitly warns that its data may be delayed, incomplete, modeled, inferred or wrong. It should not be used for navigation, emergency response or other safety-critical decisions. Important information should be checked against authoritative sources.
That warning is essential to understanding the project accurately.
The AI Voice Interface
The globe would already be an interesting visualization tool without AI. The voice interface changes how users can interact with it.
God’s Eye View includes hands-free voice control powered by a realtime AI agent. Rather than manually opening every panel and filtering every layer, users can interact with the application conversationally.
The project also documents voice-driven geographic annotations, allowing users to add marks, routes and other visual elements to the globe through supported commands.
This changes the interaction pattern from manually searching, clicking and inspecting toward asking a question and exploring the resulting view.
The important point is that the AI operates within the capabilities of the application and its available data. It cannot reliably answer questions about information the underlying sources do not contain.
God’s Eye View Can Now Work Through AI Agents
One of the project's most notable recent developments is its Model Context Protocol integration.
According to the official changelog, versions 0.2.0 and 0.2.1 introduced an MCP server and support for displaying God’s Eye View scenes inside compatible AI conversations.
MCP, or Model Context Protocol, provides a standardized way for AI applications to connect to external tools and services.
In this case, those tools are geographic. The project documents queries and capabilities involving aircraft, ships, satellites, earthquakes, fires, cameras, weather, routing, traffic, places and other geographic layers.
The integration also provides a way for compatible clients to display a requested globe state through the show_in_gods_eye_view capability.
The changelog identifies MCP Apps support in clients including Claude Desktop and the Codex and ChatGPT desktop applications. Availability depends on the client’s current MCP support and configuration.
This is an important change in the project's direction. An AI assistant can potentially do more than describe a location in text: it can request a relevant spatial view and present that view through God’s Eye View.
The division of responsibilities is straightforward:
The AI handles the conversation. God’s Eye View provides the spatial interface.
That approach could be useful beyond this project. Specialized applications may become visual tools that AI agents can operate rather than systems that users must always control manually.
The Technology Behind the Globe
Underneath the visual experience is a web-based application.
The project's package configuration identifies CesiumJS, Vite and other geospatial and visualization dependencies. The contribution guide describes a modular structure for the application, user-interface controllers, data layers, sources and services.
The repository also specifies supported Node.js versions. Developers should check the current package configuration and contribution documentation before installing because runtime requirements can change.
The architecture is interesting because the globe is not the entire system. It is the rendering layer that brings together information acquired and processed by different modules.
For developers, this makes the project a useful example of combining data providers, geographic calculations, browser rendering and AI interaction without treating them as one indivisible component.
Can You Run God’s Eye View Without API Keys?
The project is designed to offer a keyless starting path.
Its contribution guide explains how to clone the repository, install dependencies, run the setup checks and start the application locally. It also documents a keyless map experience with fallback behavior.
Additional services can be configured when a developer wants capabilities that require specific providers or credentials.
The documented setup uses Node.js 24.14.x or Node.js 26.x. A basic terminal workflow is:
git clone https://github.com/bilawalsidhu/gods-eye-view.git
cd gods-eye-view
nvm install 24.14.0
nvm use 24.14.0
npm install
npm run doctor
npm run devCheck the current repository instructions before running these commands, as setup details can change between revisions.
Some features require provider credentials, and usage may be subject to rate limits, billing and provider terms. A keyless installation does not imply that every feature is available without configuration.
Security Matters When AI Can Trigger API Requests
An application that combines multiple data providers has to manage more than visualization.
API credentials must be protected. Requests need limits. Local services should not be exposed carelessly. External pages should not be able to trigger cost-bearing operations without appropriate controls.
The project's changelog records security improvements in version 0.2.1, including host validation, protections around cross-site requests, rate limits and safeguards for MCP-related functionality.
The security documentation and changelog are the best places to review the project's current approach.
These details are especially relevant to developers building AI-powered tools. Giving an AI agent access to external services creates new interaction possibilities, but it also makes credential handling, request validation and usage controls more important.
Open Source Does Not Mean Every Dataset Is Free to Reuse
God’s Eye View is released under the MIT License, which permits broad use of the project's source code subject to the license terms.
However, the source-code license does not automatically apply to third-party datasets, imagery or services.
The repository's license explicitly states that third-party data remains subject to its own licensing terms. Its data-source documentation provides additional attribution and usage information.
For example, the repository identifies non-commercial licensing restrictions for its bundled TeleGeography submarine-cable dataset. Some other datasets have their own attribution or share-alike requirements, while live providers can impose separate API and commercial-use conditions.
This matters if you want to build a product using the project.
Open-source software and open data are not the same thing.
Before redistributing datasets or deploying the application commercially, review the terms for the specific data and providers you intend to use.
What God’s Eye View Does Not Do
The name and cinematic interface can make the project sound more powerful than its documented capabilities.
It is not a classified intelligence network. It does not automatically provide access to private surveillance systems. It does not make every displayed object continuously observable, and it cannot turn incomplete public data into perfect intelligence.
Some layers are directly sourced, some are calculated, and others are modeled or estimated.
The project itself describes the application as an exploratory visualization of public and third-party data and advises against using it for flight or maritime navigation, emergency response or other safety-critical purposes.
That is not a minor limitation. It is central to understanding what the software actually provides.
Its value lies in the way it connects different information sources, not in any claim that it can see everything.
Why God’s Eye View Matters for Developers
God’s Eye View is interesting because it combines technologies that are often treated separately.
A conventional mapping application focuses on geographic navigation. A dashboard focuses on charts and metrics. An AI assistant communicates through language. God’s Eye View brings these ideas into a shared interface.
The globe provides spatial context. Data providers supply information. Geographic layers make the information explorable. The AI agent gives users another way to query and control the environment.
The MCP integration extends that concept by allowing compatible AI clients to request views from a specialized application instead of trying to recreate the entire visualization themselves.
For developers, this suggests a useful design principle: an AI system does not need to do everything internally. It can use existing applications as tools, allowing each component to focus on what it does best.
The Bigger Idea: Spatial Intelligence
The most interesting part of God’s Eye View is not any single layer.
Aircraft tracking already exists. Satellite visualization already exists. Earthquake maps and weather dashboards already exist. Three-dimensional mapping platforms have existed for years.
The project's appeal comes from bringing these capabilities together and making them accessible through one interface.
Aircraft, ships, satellites, weather, fires, cameras, infrastructure and imagery become different views of the same physical world.
AI adds another dimension by making the interface conversational and allowing compatible agents to request geographic views.
That creates a compelling possibility: instead of receiving only a text explanation about a place, users can explore a visual representation of the place and its available data.
The map becomes more than something to navigate. It becomes an interface for asking questions about the world.
Final Thoughts
God’s Eye View looks like a futuristic intelligence console, but its underlying idea is more accessible than its appearance suggests.
Public aircraft feeds, maritime data, satellite orbital information, earthquake records, weather products and geographic datasets already exist across different systems. The challenge is connecting them, representing their limitations honestly and making the result useful to explore.
God’s Eye View brings those pieces together in a browser-based 3D globe, then adds voice interaction and an MCP integration that lets compatible AI clients work with its spatial capabilities.
The result is not an all-seeing surveillance system. It is a practical demonstration of what can happen when open-source software, public data, geospatial computing and AI are designed to work together.
And that may be the most interesting takeaway.
The future of AI interfaces may not be limited to chat windows and generated text. Sometimes, the most useful answer to a question could be a place you can explore — with the relevant information already displayed around it.
Sources & References
Official project documentation
Data providers and technical references
Editorial note: data availability, provider terms, supported integrations and project features can change. The repository documentation should be treated as the primary reference for the current implementation.