God's Eye View: The Open-Source OSINT Globe That Lets AI Explore the Real World

Key Takeaways

• God's Eye View is an open-source geospatial intelligence interface, not a literal spy satellite feed. It combines public and third-party signals on a browser-based 3D globe, including aircraft, vessels, satellites, earthquakes, public cameras, weather, infrastructure, radio, launches, and other layers.
• The project is unusually accessible for a GEOINT-style tool. A keyless mode works locally with baseline imagery and several public-data layers; optional provider keys unlock photorealistic 3D, Google place search, live vessel feeds, NASA fire data, traffic, and AI voice control.
• Its strongest idea is data fusion. Instead of opening separate flight trackers, marine trackers, earthquake maps, weather viewers, CCTV pages, and satellite tools, users can move between these signals in one spatial context.
• The AI layer is functional rather than decorative. With an OpenAI key, the realtime voice agent can navigate the globe, change layers, answer questions about visible entities, draw annotations, and operate the interface. The project also exposes a Model Context Protocol server for Claude, Codex, and compatible desktop clients.
• Not every layer is equally real-time or equally precise. Some feeds are live or frequently refreshed; others are delayed, modeled, simulated, cached, or based on estimated camera or trajectory geometry. The application itself warns against safety-critical use.
• The source code is MIT-licensed, but the data is not universally MIT-licensed. Third-party datasets, imagery, 3D models, and provider APIs keep their own terms. This distinction matters for commercial deployments.

As of October 7, 2026, the public repository showed roughly 48.5K GitHub stars and 9.9K forks, with hundreds of commits and active development on the main branch. GitHub also lists it as a JavaScript project focused on 3D globes, OSINT, GIS, flight tracking, satellite tracking, and spatial intelligence.

What Is God's Eye View? is an open-source browser application created by Bilawal Sidhu and contributors. Its own description is intentionally cinematic: a spy-satellite simulator in the browser, except the data is real.

A more precise technical description is a local-first 3D geospatial data-fusion client.

The application uses a globe interface to combine multiple classes of public or user-authorized information:

• aircraft transponder data;
• military-aircraft feeds where available;
• AIS vessel data;
• satellite orbital elements;
• earthquakes;
• launch data;
• active fires and fire perimeters;
• public CCTV feeds and camera locations;
• road traffic;
• weather radar, wind, satellite imagery, lightning, and cyclone advisories;
• radio stations;
• datacenters, dams, submarine cables, transit, bike-share systems, and other infrastructure layers;
• annotations, routes, scene presets, and shareable map states.

The project is designed around the idea that spatial context becomes more useful when multiple signals can be inspected together. A flight, nearby camera, weather system, fire, ship, satellite, or piece of infrastructure is more meaningful when it can be explored without leaving the same coordinate system.

That is the central reason God's Eye View feels different from a normal tracker. It is less about providing the deepest possible interface for one dataset and more about giving users a common spatial operating picture.

Why Did God's Eye View Go Viral?

The visual presentation helped. Aircraft can be tracked over photorealistic terrain, CCTV can be projected into 3D scenes, satellites can be followed in orbit, and the entire globe can be rendered with tactical-style HUD overlays and sensor-inspired looks such as NVG, FLIR, CRT, Noir, and Snow.

But the bigger reason is the gap between appearance and provenance.

The interface looks like a fictional intelligence console, while much of the underlying information comes from openly accessible or commercially available feeds. That contrast makes the project immediately understandable: modern public data already exposes a surprising amount of activity when it is fused into one interface.

The repository says the project reached #1 on GitHub Trending in August 2026, and Trendshift's historical tracking independently records it reaching GitHub Trending #1 on August 27, 2026. The creator also publicly described the surge and the demand for a simpler installer and full walkthrough.

The project's growth also reflects a broader developer trend: GIS, OSINT, realtime data feeds, 3D web rendering, and AI agents are converging. God's Eye View packages all five into a product that can be understood in seconds.

What Can God's Eye View Actually Do?

The feature set is much broader than the viral flight-tracking demos suggest.

Track aircraft in 2D, 3D, or cockpit view

Users can enable live flight layers, select an aircraft, follow its motion, inspect available metadata, and switch into a cockpit-style camera.

The application also supports proximity-based 3D aircraft models for classes such as airliners, helicopters, business jets, and military aircraft. A nearby contact can transition from a simple map glyph to a 3D model as the camera approaches.

This matters because the interface is not only plotting points. It is trying to preserve a relationship between telemetry, terrain, camera motion, and scale.

Inspect ships and maritime traffic

Vessel layers use AIS-derived data when configured. Users can inspect ships, search by vessel identifiers or names through the tool layer, view recent tracks, and combine maritime activity with ports, infrastructure, weather, or nearby cameras.

The important limitation is coverage. Terrestrial AIS reception becomes sparse offshore, and broader satellite AIS access is typically commercial. The project's architecture can support richer feeds, but open-source software cannot remove upstream data economics.

Follow satellites and predict passes

The satellite layer uses orbital-element data to position spacecraft and can calculate upcoming passes over a location.

The associated query tools can answer questions such as when the ISS or another loaded satellite will rise, peak, and set, including whether conditions suggest naked-eye visibility.

This turns the globe from a visualization into a queryable spatial model.

Explore public cameras and viewsheds

God's Eye View can display public cameras in supported regions and, for some sources, show snapshots or live video.

One of the more distinctive visualization features is the estimated viewshed: a 3D representation of the approximate direction and field of view of a camera.

That should not be interpreted as survey-grade geometry. Camera poses can be estimated or incomplete. The viewshed is best treated as contextual visualization, not proof that a camera can or cannot see a specific object.

Add weather and environmental context

The weather stack is deeper than a decorative overlay. The project includes support for forecast wind fields, observed radar, infrared satellite imagery, lightning density, cyclone advisories, fires, and other environmental layers.

That combination is useful because weather often explains what other datasets are doing. Aircraft routes, ship behavior, fire growth, camera visibility, and infrastructure risk become easier to interpret when the environmental context is present in the same view.

Draw, annotate, route, and create scenes

The map is also an authoring surface.

Users can add pins, lines, polygons, labels, arrows, and routes. Directions can be displayed for driving, walking, or cycling, and the scene director can create cinematic camera movements.

Share links can serialize important view state, including camera position, visual style, layers, annotations, and in some cases a tracked target.

That design makes a scene reproducible. A useful geospatial view can be handed to another person instead of being described manually.

Real Data Does Not Mean Perfect Real-Time Data

This is the most important distinction in the entire project.

God's Eye View combines data from many providers, and every provider has different latency, update intervals, geographic coverage, licensing rules, and failure modes.

The repository itself states that most feeds are live or regularly refreshed, while some traffic is simulated along real roads and some CCTV camera poses or launch trajectories are coarse estimates.

A practical way to interpret the layers is:

This distinction is crucial for E-E-A-T because a sophisticated interface can make uncertain data appear more authoritative than it is.

The correct mental model is situational exploration, not operational truth.

The AI Voice Agent Is More Than Voice Search

Voice control is one of the most technically interesting parts of God's Eye View.

With an OpenAI API key configured, the realtime agent receives structured scene context and can call application actions or data-query tools.

Examples include:

• flying the camera to a place;
• changing visual styles;
• enabling or disabling layers;
• selecting or following an aircraft;
• entering cockpit mode;
• drawing a real boundary or route;
• asking how many aircraft are in an area;
• finding ships or satellites;
• asking what entity is currently selected;
• getting a short situational summary of the visible scene.

The implementation is more robust than a simple speech-to-command parser because the agent can operate against structured tools rather than relying entirely on natural-language interpretation.

For developers, that architecture is notable. The same conceptual tool catalog can serve both voice function calling and external agents.

MCP Integration: God's Eye View Inside Claude, Codex, and ChatGPT

The repository includes a Model Context Protocol server under server/mcp/.

That means compatible AI clients can query God's Eye View data or open a globe view from the conversation.

The documented setup supports Claude Code, Claude Desktop, Codex CLI, Codex desktop, and ChatGPT desktop through either STDIO or local HTTP transport.

A minimal local workflow is:

git clone https://github.com/bilawalsidhu/gods-eye-view.git
cd gods-eye-view
npm ci
npm run build:panel
npm run dev

Then an MCP client can register the server against the running local app.

The tool layer exposes structured queries for areas such as earthquakes, fires, aircraft, vessels, satellite passes, CCTV cameras, infrastructure, and situational briefs. It can also return a suggested globe view so an answer can be opened directly in the spatial interface.

The important design insight is that the globe becomes an agent surface, not merely an app that happens to have AI bolted on.

A language model can ask for structured data, receive machine-readable results, and then hand the user a visual state that corresponds to the answer.

How the Architecture Works

The application is primarily JavaScript and uses Vite for development and builds, with Cesium as the core 3D geospatial engine.

Key dependencies include:

• cesium for globe rendering;
• satellite.js for orbital calculations;
• hls.js for compatible live video streams;
• mapillary-js for street-level imagery support;
• Mapbox vector-tile and PBF tooling;
• eccodes-wasm for weather-data decoding;
• WebRTL-SDR tooling for supported local radio workflows;
• Node-based server providers for APIs and credential-bearing data sources.

The repository separates many layers into modules such as flights, vessels, earthquakes, satellites, fires, traffic, CCTV, transit, radio, ALPR locations, submarine cables, and street-level imagery.

This modular structure matters because a geospatial fusion system becomes difficult to maintain if every provider is wired directly into one monolithic map component.

A strong architectural pattern in God's Eye View is:

1. source/provider layer retrieves or normalizes data;
2. layer module turns domain data into map behavior;
3. application services coordinate state and requests;
4. Cesium/view layer renders the world;
5. tool catalog exposes structured queries to voice and MCP;
6. local server proxies protect secrets and normalize providers that should not be called directly from the browser.

That separation is one of the most reusable ideas in the repository.

How to Install God's Eye View

There are two main installation paths.

Option 1: Pinokio

For users who do not want to manage Node.js manually, the project supports a Pinokio installer.

The README currently recommends Pinokio 8.2 or later and supports Windows, macOS, and Linux.

Option 2: Terminal

The documented Node.js requirement is Node 24.14.0 or later within the 24.x line, or Node 26.x.

git clone https://github.com/bilawalsidhu/gods-eye-view.git
cd gods-eye-view
npm ci
npm run doctor
npm run dev

Then open:

http://localhost:4173

The app is designed to start without mandatory API keys. The README says its baseline can use Esri satellite imagery and keyless terrain, with OpenStreetMap as a fallback, while several data layers work without credentials.

A useful maintenance note: the main branch is moving quickly. On October 7, 2026, new street-level imagery work was still being merged after the latest tagged release. Anyone writing documentation, deploying a fork, or comparing behavior should distinguish the latest release tag from current main.

Which API Keys Are Optional?

The product treats most keys as capability upgrades.

Common examples include:

• Cesium ion token for supported photorealistic 3D and terrain workflows;
• Google Maps API key for direct Google photorealistic 3D and place-search capabilities;
• OpenAI API key for realtime voice and AI summaries;
• AISStream key for configured vessel data;
• OpenSky credentials for certain authenticated flight-data paths;
• Mapillary token for street-level imagery;
• provider-specific keys for other premium or metered feeds.

This approach gives the project a low floor and a high ceiling.

A developer can run the project cheaply and explore the architecture, then add commercial providers only when a use case requires better imagery, coverage, or AI interaction.

Security Model: Local-First, but Not Magic

God's Eye View is explicitly described as a local-first exploratory client, not a hardened production service.

That positioning is important.

Sensitive API credentials such as the main OpenAI key, AISStream key, and OpenSky OAuth secrets are intended to remain server-side. The browser receives proxied data or short-lived session credentials instead of the raw secret.

Some browser-oriented tokens, however, are deliberately exposed to the client because the upstream services are designed that way. Those tokens must be restricted at the provider level.

The project also includes protections against turning its local proxy into a generic relay, including fixed upstream destinations, request validation, origin and host checks, and rate limits on cost-bearing routes.

The latest tagged v0.2.1 release, published October 3, 2026, focused heavily on this area, including stricter cross-site request handling, host checks, CSP, MCP-panel restrictions, and default throttling for OpenAI- and Google-backed routes.

The practical rule is simple: localhost is the intended default trust boundary.

Exposing the application to a LAN or the public internet changes the threat model because remote users may indirectly consume configured provider credentials or paid quotas.

Performance: Fast Globe, Expensive Dense Overlays

The repository includes a useful performance baseline rather than vague performance claims.

On one documented Apple M5 / Chrome 150 test configuration, the median initial-settle time was about 1.86 seconds, with simple scenes reaching 60 FPS.

The same benchmark shows why performance discussions need nuance:

• normal globe and several simple aircraft scenes reached 60 FPS;
• dense detection overlays dropped into roughly the mid-30s to low-40s FPS;
• cockpit mode was around 49 FPS in the recorded scene;
• text-heavy combined scenes consumed substantially more memory;
• large live populations such as vessel and fire datasets increased rendering cost;
• cold activation time varied widely by layer.

The key insight is that rendering the globe is not the hard part.

The expensive cases appear when many moving entities, labels, overlays, video sources, post-processing effects, and 3D assets are active at once.

For forks and commercial derivatives, performance work should therefore focus on:

• level-of-detail policies;
• label density;
• entity culling;
• spatial indexing;
• request batching;
• tile caching;
• worker offloading;
• incremental rendering;
• data retention limits;
• scene-specific defaults.

Licensing: MIT Code Does Not Mean MIT Data

The source code is released under the MIT License.

However, the repository's LICENSE file explicitly separates the software license from third-party data and assets.

Examples include datasets with attribution, non-commercial, or share-alike requirements. Runtime providers such as Google Maps, OpenSky, AISStream, and other services retain their own terms. Some bundled event imagery and 3D models also have separate licenses.

This creates an important commercial-use checklist:

• audit every bundled dataset;
• audit every 3D model;
• audit each provider API;
• verify whether redistribution is allowed;
• verify attribution requirements;
• remove non-commercial assets if the product will be monetized;
• restrict keys and set provider-side quotas;
• do not assume that forking an MIT repository makes the entire data stack commercially reusable.

For businesses, this is arguably the most important section of the project documentation.

What Makes God's Eye View Technically Interesting?

Several design choices stand out.

1. Data fusion instead of another single-purpose tracker

Most tracking products optimize deeply for one domain.

God's Eye View optimizes for transitions between domains.

A user can move from an aircraft to weather, a camera, nearby infrastructure, a satellite pass, or an annotated route without changing tools.

That creates a different kind of value: cross-layer reasoning.

2. AI actions are bound to real application state

The voice agent is not just generating descriptions.

It can manipulate map state and query structured services. That makes voice a true control surface.

3. Views are serializable

Share links preserve meaningful scene state. This turns a map view into a reproducible artifact.

4. The project treats the agent and the globe as two views of the same data

MCP queries can return both structured answers and a suggested visual state.

That is a strong pattern for future AI-native analytics products: answer in text, verify in a spatial interface.

5. The project is transparent about imperfect data

The documentation repeatedly distinguishes observations, forecasts, derived positions, modeled data, estimated geometry, stale fallbacks, and provider limitations.

That is especially important in OSINT software, where presentation quality can easily exceed data certainty.

God's Eye View vs Google Earth and Single-Purpose Trackers

God's Eye View should not be evaluated as a direct replacement for every specialized product.

The correct comparison is therefore not simply which product has more data.

God's Eye View is strongest when the problem requires fusion, experimentation, visualization, and extensibility.

Specialized products remain stronger when the requirement is certified uptime, deep domain-specific analytics, long historical archives, commercial support, or safety-critical reliability.

Best Use Cases

God's Eye View is particularly well suited to:

• OSINT education: demonstrate how public signals can be combined without claiming access to classified systems;
• GIS prototyping: test new layer ideas quickly in a mature 3D interface;
• journalism and research: explore spatial relationships before verifying claims with authoritative sources;
• developer demos: build AI-agent workflows that control a real application;
• emergency-management prototypes: visualize multiple public feeds, while keeping the project out of actual safety-critical decision loops;
• transportation exploration: inspect flights, vessels, transit, and traffic together;
• weather storytelling: combine environmental observations with other live systems;
• spatial product R&D: study how text, voice, tools, maps, and 3D scenes can share application state.

Common Pitfalls

Treating the interface as authoritative intelligence

A polished HUD does not improve the accuracy of an upstream feed.

Always inspect timestamps, provenance, coverage, fallback states, and the difference between observed and modeled data.

Publishing API keys carelessly

Client-visible mapping tokens must be restricted. Server-side secrets should remain behind the local proxy.

Exposing the development server directly to the internet

The project is not positioned as a production multi-tenant service. A public deployment needs additional authentication, authorization, quota controls, logging, abuse protection, and security review.

Ignoring data licenses

The repository's MIT license applies to the code, not automatically to every dataset and asset.

Running every layer simultaneously

The benchmark data shows that dense overlays, high object counts, post-processing, and heavy text rendering can become expensive.

Assuming main and the latest release are identical

This repository is developing quickly. Reproducible deployments should pin a commit or release tag.

A Practical Evaluation Workflow

A developer evaluating God's Eye View can use this sequence:

1. Run it keyless first. Confirm that the baseline app and local server work before adding external services.
2. Enable one domain at a time. Start with flights, satellites, earthquakes, or cameras rather than turning on everything.
3. Inspect provenance. Read DATA_SOURCES.md for every layer relevant to the intended use.
4. Add photorealistic 3D only if needed. A basic globe is enough for many data-engineering and MCP experiments.
5. Add OpenAI last. First verify that the underlying data and controls work without the agent.
6. Try the MCP server. This reveals the deeper product idea: structured spatial tools that an agent can call.
7. Measure performance with the intended layers. The upstream data population can change dramatically from one test to another.
8. Pin the version before building on top. Main can move quickly.
9. Audit licensing before commercial use.
10. Add authentication before remote access.

This workflow separates the core architecture from optional provider complexity and makes problems easier to diagnose.

Is God's Eye View Really Open Source?

The application source code is open and MIT-licensed, and the repository is designed to be inspected and extended.

However, an accurate answer needs one qualification: the complete experience depends on a mixture of open data, third-party APIs, browser tokens, user-provided credentials, and datasets with different licenses.

So the software is open source, while the total data environment is heterogeneous.

That is normal for geospatial applications, but it is easy to miss if only the GitHub badge is considered.

Is It Safe to Use for Real Operations?

No safety-critical workflow should treat it as a primary operational system.

The project explicitly describes itself as an evolving client for exploration and learning and warns that data can be delayed, incomplete, modeled, inferred, or wrong.

It should not be used as the sole basis for:

• aviation or maritime navigation;
• emergency response;
• medical or health decisions;
• investment decisions;
• law-enforcement action;
• any other high-stakes operational decision.

The strongest use is exploratory analysis followed by verification against authoritative sources.

Why This Project Matters Beyond the Demo

God's Eye View demonstrates a broader product direction for AI and GIS.

For years, geospatial interfaces were mostly passive: the user clicked layers, searched places, and manually interpreted the map.

This project points toward a different model:

data sources → spatial services → structured tools → AI agent → interactive 3D verification.

That loop is more important than any individual shader or tracking layer.

An agent can ask a structured question, receive a structured answer, move the camera, enable the relevant layers, and present the result visually. The human can then inspect the same context rather than trusting a text-only summary.

That pattern can extend far beyond OSINT into logistics, climate analytics, infrastructure monitoring, real-estate intelligence, supply chains, utilities, defense-adjacent simulation, transportation, insurance, and location-aware digital twins.

The project therefore matters less as a finished intelligence product and more as an unusually visible example of AI-native spatial software.

Conclusion

God's Eye View earns attention because it turns fragmented public signals into a coherent, explorable world model.

Its most impressive features are not the military-style HUD or the spy-thriller visuals. They are the modular data architecture, local-first credential model, structured tool layer, AI actions, MCP integration, and reproducible spatial views.

At the same time, the project should be used with the right expectations. Data freshness varies. Some geometry is estimated. Some services require paid or restricted providers. Dense scenes can be expensive to render. Commercial deployments need a real license audit, and public hosting needs a stronger security layer.

For developers interested in GEOINT, OSINT, GIS, realtime visualization, Cesium, AI agents, or MCP, the repository is worth studying even if the final product is never deployed unchanged.

The best next step is to run the project keyless, inspect the data-source documentation, then connect one AI or provider capability at a time. That approach makes it easier to understand what God's Eye View actually is: not a magic surveillance system, but a powerful open-source framework for turning public spatial signals into an interactive, agent-controllable map of the world.