This project turns public signals into a 3D globe with AI, voice, and live data

[Devy]

This Project Converts Public Signals into a 3D Globe with AI, Voice, and Live Data

Most OSINT work starts as a stack of browser tabs.

One tab for planes. Another for ships. Another for earthquakes. Another for satellite passes. Another for traffic, public cameras, infrastructure, weather, launch data and map layers. The data is public, but the workflow is fragmented.

God’s Eye View takes a different approach: it converts those public signals into a photorealistic 3D globe, browser-based, that you can run locally, inspect, and extend.

The project describes itself as a “spy satellite simulator in your browser”, but the important part comes after: the sources are public and the data is real.

That makes it a useful project to study as developers, not just a flashy demo.

It combines planes, ships, satellites, earthquakes, traffic, public cameras, radio, bikeshare, active fires, space missions and mapped infrastructure into a single Cesium-based globe. It also adds voice interaction through an agent powered by OpenAI Realtime, so you can ask the interface to navigate, annotate, inspect entities, toggle layers or summarize the current scene.

The result feels cinematic. But the engineering questions are very practical.

How do you label what’s live and what’s simulated? How do you handle optional API keys? How do you prevent secrets from reaching the browser? How do you explain third-party data licenses? How do you build an AI interface over public signals without pretending the tool knows more than it actually does?

That’s where God’s Eye View gets interesting.

What You Can Run Locally

God’s Eye View is a Vite and vanilla JavaScript application built on CesiumJS, Google Photorealistic 3D Tiles, and various public data sources, both live and packaged.

The quick start is straightforward, with one important requirement: the repository currently requires Node.js 24.14.x or 26.x, enforced from package.json.

The basic local flow is:

git clone https://github.com/bilawalsidhu/gods-eye-view.git
cd gods-eye-view
cp .env.example .env
npm install
npm run dev -- --host localhost --port 4173

Then you open:

http://localhost:4173

The required key is GOOGLE_MAPS_API_KEY, because the photorealistic 3D planet comes from the Google Maps Tiles API. The README is clear that this is a metered provider, so it’s worth setting up quotas and budget alerts before serious use.

From there, many layers work without account or sign-up. The README lists planes, military traffic, satellites, earthquakes, CCTV, radio, bikeshare, space missions, mapped facilities and packaged datasets as available without keys.

Other capabilities improve when you add your own keys:

• OPENAI_API_KEY for voice interaction and AI-powered HUD summaries.
• AISSTREAM_API_KEY for live ships.
• NASA FIRMS key for active fires.
• TOMTOM_API_KEY for real traffic instead of approximate simulation.
• CESIUM_ION_TOKEN for Bing imagery layers.
• OpenSky credentials for more flight query credits.

This separation matters because the project doesn’t pretend all signals have the same cost, quality, or availability. It marks layers by whether they need nothing, require a free key, or depend on a metered provider.

That’s good developer UX.

First Lesson: Public Doesn’t Mean Simple

The README presents the tool as open source spatial intelligence. It sounds clean, but the implementation reality is messy in the way real software usually is.

Plane data comes from OpenSky and adsb.lol. Ships come from AISStream. Satellites use TLEs from CelesTrak. Earthquakes come from USGS. Traffic can use TomTom, with road geometry from OpenStreetMap. Public camera packages come from APIs from cities like Austin, California Caltrans, and Transport for London. Radio uses Radio Browser and broadcasts. Weather comes from Open-Meteo. Space launches use Launch Library 2.

Each source has its own terms, limits, update frequency, and failure behavior.

That’s why the repository’s DATA_SOURCES.md file is worth reading before treating this as a toy. The project says the source code is licensed under MIT, but third-party data and visual assets maintain their own licenses and terms. Some packaged datasets are explicitly separated because they’re not compatible with MIT.

For developers, that’s the first practical lesson: that code is open source doesn’t automatically make the data open for any use case.

If you fork it, make an internal demo, or a commercial variant, the data sources file isn’t decorative documentation. It’s part of the product boundary.

Second Lesson: Honest Degradation Builds Trust

The August 24 changelog on main adds several trust-relevant changes.

One fix indicates that the absence of an optional NASA FIRMS key no longer turns the entire Environmental mission into LOAD FAILED. The FIRMS row still shows KEY REQUIRED, while earthquakes continue loading.

It might sound minimal, but it’s exactly the kind of detail that separates a real tool from a demo.

In a multi-source interface, a missing key shouldn’t make the whole environment look broken. The UI should explain what’s missing, keep working where it can, and avoid turning partial success into total failure.

The README also says some experiences are modeled, not live. Traffic without a key is labeled as simulation. Camera poses are estimated until calibrated. Launch ascent playback is marked as reconstructed estimation. Layers expose source state and freshness, including partial, delayed, simulated, and unavailable states.

That’s the right instinct for an OSINT-style tool.

When you display public signals on a beautiful 3D globe, the interface can create false authority. A tactical style can make estimated data feel precise. A camera projection can feel like evidence even when calibration is approximate. A reconstructed launch can seem live if the label is weak.

God’s Eye View works against this by making provenance and state visible.

Not perfectly, and not as a hardened production system, but in a way that developers can inspect and improve.

Third Lesson: Keep Secrets on the Server Side

The voice features are one of the most striking parts of the project.

With an OpenAI key, you can talk to the globe. The README describes voice commands for navigation, annotation, questions about entities, layer controls, visual style changes, routes, and live scene summaries.

For example, the app can answer questions about the current view, selected planes, ships, datacenters, or nearby signals. It can draw routes and annotations over the world. It can change visual modes and operate layers hands-free.

But the important implementation detail is how the key is handled.

The README says OPENAI_API_KEY never reaches the browser. The client receives a short-lived session token instead. Other providers requiring secrets are also intermediated server-side, while proxy destinations are fixed or allowlisted, and higher-risk paths add request limits, timeouts, response limits, and sanitized errors where appropriate.

This matters because browser-based geospatial apps often live in an uncomfortable boundary. They feel like frontend demos, but touch paid APIs, user microphones, network proxies, and live data sources.If a local development server is exposed to a LAN, the README warns that it may proxy API keys configured for anyone who can reach it. The project recommends explicitly opting into LAN sharing, using IP-based throttles, and configuring budget limits on the provider side.

That’s exactly the kind of warning more AI demos should include.

The local-first story isn’t