God's Eye View: así está construido el satélite espía

Abres una pestaña del navegador y tienes delante un globo terráqueo fotorrealista con once mil aviones volando en directo. Pinchas uno. La cámara se engancha, dibuja una estela y te mete en la cabina. Cambias a visión nocturna. Bajas a una intersección de Austin y miras por una cámara de tráfico pública proyectada dentro de la ciudad en 3D.

Parece material clasificado.

No lo es. Todo lo que ves ahí estaba publicado antes de que alguien lo juntara.

Eso es God’s Eye View, el proyecto de Bilawal Sidhu que llegó al número 1 de GitHub Trending (diario y semanal) en agosto de 2026 y que hoy es un repositorio MIT que puedes clonar. Y lo interesante para nosotros no es el juguete. Es cómo está hecho.

En este post repasamos:

• De dónde salen los datos y por qué casi todos son gratis
• El stack real: vanilla JavaScript, CesiumJS y un backend escondido donde no lo esperas
• Los cuatro problemas de ingeniería que hacen que la imagen resulte creíble
• Cómo se gestiona el presupuesto de APIs como una decisión de arquitectura
• Quién es Bilawal Sidhu y por qué acabó liberando esto

La astucia está en la fuente, no en el render ¶

La jugada maestra de God’s Eye View es darse cuenta de que el mundo ya emite.

Cada avión comercial lleva un transpondedor ADS-B que grita su posición, altitud y rumbo en abierto. Cada barco mercante emite AIS por la misma razón. Los satélites publican sus elementos orbitales en CelesTrak. El USGS publica cada terremoto. Las ciudades publican los catálogos de sus cámaras de tráfico. La NASA publica las detecciones de incendios activos.

Todo eso ya estaba ahí. Disperso, feo, en formatos distintos, en trece sitios distintos.

Lo que hace el proyecto es fusionarlo en una sola escena y darle la estética de una sala de operaciones. La tecnología difícil no es la que captura el dato. Es la que lo pone en el mismo sitio sin que cante.

Y el reparto de costes es casi cómico:

Once de las trece capas tienen camino sin clave. La única que cuesta dinero real es la voz, y ya veremos lo que hacen con eso.

🔑 Si te quedas con una idea del proyecto, que sea esta: antes de construir la fuente de datos, comprueba si alguien ya la está emitiendo en abierto.

El stack, o más bien la ausencia de stack ¶

Aquí viene la parte que le duele a mucha gente.

No hay framework. Ni React, ni Vue, ni Svelte. El package.json declara seis dependencias de producción y la lista completa cabe en un tuit: cesium, satellite.js, egm96-universal, mgrs, pbf y @mapbox/vector-tile.

Eso es todo.

CesiumJS es la pieza gorda: el motor de globo 3D sobre WebGL que se come los teselados, la proyección geodésica y el pipeline de render. Vite hace de bundler y de servidor de desarrollo. El resto es JavaScript a pelo organizado en módulos:

src/
├── main.js                 # Arranque: teselas 3D de Google, registro de capas
├── ui.js                   # Paneles, HUD, estilos, fachada de control
├── hud.js                  # HUD de inteligencia + resumen de escena con IA
├── mapStackController.js   # Cambio de basemap: Google 3D / Esri / OSM / ion
├── voice/                  # Sesión Realtime de OpenAI + 28 herramientas
├── data/                   # Un módulo por capa + orquestación + contexto
│   ├── iconOrientation.js  # Rumbos proyectados en pantalla + culling
│   └── local_data/         # Datasets empaquetados con su procedencia
└── scenes/                 # Director de escenas cinematográficas

La carpeta src/data/ tiene 88 módulos de producción. Al lado, 103 ficheros de test. En todo el repositorio hay 178 suites ejecutables con npm test, sin Jest ni Vitest: el runner nativo de Node y ficheros .test.mjs.

Un proyecto sin framework, con más ficheros de test que de producción en su carpeta más crítica y con un style.css de 261 KB escrito a mano. Esto no es un fin de semana de vibecoding. Es alguien que sabe exactamente dónde está cada cosa.

Un backend entero escondido dentro de vite.config.js ¶

Esta es mi parte favorita, y es donde se ve el oficio.

El vite.config.js del proyecto ocupa 342 KB. No es un error de tipeo. Dentro viven veintiséis rutas de API montadas como middlewares de Vite mediante configureServer:

// El patrón que se repite 26 veces en vite.config.js
{
  name: 'opensky-proxy',
  configureServer(server) {
    server.middlewares.use('/api/opensky', async (req, res) => {
      // valida, cachea, aplica presupuesto, sanea errores
    });
  }
}

/api/opensky, /api/ais-live, /api/cctv, /api/celestrak, /api/firms, /api/tomtom, /api/overpass, /api/route, /api/radio, /api/terrain/heights, /api/realtime/token… y así hasta veintiséis.

¿Por qué meter un backend dentro de la configuración del bundler? Porque el proyecto no quiere que despliegues nada. Corre en tu máquina, npm run dev y ya. Y aun así necesita un servidor, por un motivo que no es negociable: las claves de API no pueden tocar el navegador.

Cada API que usa una clave privada (OpenAI, AISStream, OAuth de OpenSky, los frames de las cámaras) pasa por ese proxy con protección contra SSRF, topes de tamaño de respuesta y errores saneados. Las únicas dos claves que ve el navegador son Google Maps y Cesium ion, y las dos se restringen en el proveedor.

Lo que en una app “seria” serían doce funciones serverless, aquí son doce middlewares que solo existen mientras tengas la terminal abierta. Cero infraestructura, cero factura, mismo modelo de seguridad.

Los cuatro problemas que hacen creíble la imagen ¶

Enseñar un punto en un mapa es fácil. Que ese punto parezca real es donde se va el noventa por ciento del esfuerzo. El repositorio documenta cuatro peleas concretas, y las cuatro se pueden robar para tus propios proyectos.

Iconos que apuntan al rumbo de verdad ¶

Un icono de avión en Cesium es un billboard: un cuadrado que siempre mira a la cámara. Si quieres que la punta apunte al rumbo real del aparato, tienes un problema de geometría, porque el rumbo vive en el mundo y el icono vive en la pantalla.

El primer intento del proyecto mezclaba dos técnicas según la inclinación de la cámara y se rompía en modo órbita: el avión se quedaba pegado al viewport en lugar de girar. El comentario en iconOrientation.js lo cuenta con fecha y todo, “playtest del 10 de junio de 2026”.

La solución es transformar el vector de rumbo a espacio mundo y proyectarlo sobre la base right/up de la cámara. Con dos detalles finos: una banda muerta de medio grado para ignorar el ruido de proyección, y un umbral mínimo por debajo del cual el rumbo apunta casi de frente a la pantalla y el ángulo deja de ser fiable.

El comentario del código reconoce que es una aproximación ortográfica, exacta solo en el centro del viewport. Y añade una frase que me parece la mejor del repositorio: la evidencia de campo, no un cambio de fórmula sin verificar, decidirá si conviene pasar a proyección exacta.

💡 Documentar por qué elegiste la aproximación vale más que el código que la implementa.

Movimiento suave con datos a trompicones ¶

OpenSky te da una foto fija cada 15 o 30 segundos. Si pintas cada foto según llega, tus aviones dan saltos.

El truco es renderizar una ronda de sondeo por detrás del tiempo real. Al ir con ese retraso deliberado siempre tienes dos posiciones conocidas que envuelven el instante que quieres pintar, así que puedes interpolar entre ellas en lugar de extrapolar hacia adelante. Interpolar no se equivoca; extrapolar sí, y se nota cuando el avión corrige de golpe y pega un tirón hacia atrás.

Cuando falta el par que envuelve (feed caído, glitch, arranque en frío), entra dead reckoning: se estima la posición con el último rumbo y velocidad conocidos. El código se cuida de que el paso de un régimen al otro no produzca ni un salto visible ni un congelamiento.

Es la misma idea que usan los juegos online para disimular la latencia. Retrasar la realidad un poco para poder mentir mejor.

Aviones que se posan en el suelo y no flotando ¶

Un avión parado en la pista tiene que estar en la pista. Suena obvio hasta que descubres que la altitud de un feed ADS-B, la malla de terreno renderizada y el elipsoide de referencia son tres cosas distintas.

Aquí entra egm96-universal, una de esas seis dependencias. El proyecto convierte alturas usando un datum vertical real, tiene en cuenta el geoide y muestrea contra la malla de terreno efectivamente renderizada, no contra un modelo teórico. Si Re:Earth Terrain no responde, cae a la matemática de geoide EGM96 empaquetada en el bundle.

Resultado: los aviones aparcan en las plataformas y las cámaras de tráfico se plantan en las esquinas en lugar de levitar un metro y medio.

Satélites que no derivan ¶

Los satélites se propagan con SGP4 vía satellite.js, el estándar que come TLEs de CelesTrak. Lo complicado no es la propagación: es que el anillo de órbita que dibujas al lado del satélite se mantenga enganchado.

El proyecto realinea con GMST (tiempo sidéreo medio de Greenwich) para que anillo y objeto compartan marco de referencia. Sin eso, el anillo deriva unos grados por minuto y empieza el parpadeo por segundo. Con eso, se queda quieto.

Guía interactiva gratis

Leer proyectos así está bien. Montar el tuyo está mejor

Un recorrido de 17 paradas para elegir proyecto, agente y presupuesto, con una parada dedicada a empezar pequeño, en local y para ti. Sales con una checklist a tu medida.

Entra en el curso gratis →

Veintiocho herramientas para un agente de voz que sabe dónde está ¶

La capa de voz es la única que cuesta dinero, y también la mejor diseñada del proyecto.

Funciona con la Realtime API de OpenAI y expone veintiocho herramientas al modelo, agrupadas en cuatro trabajos: dirigir la cámara, anotar el mundo, interrogar las capas y operar la consola. Le dices “dibuja la ruta a pie desde el Capitolio hasta Zilker Park” y aparece el trazado siguiendo calles reales. Luego “vuélala” y la cámara la recorre con giros peraltados.

Tres decisiones de arquitectura que merecen apuntarse:

El agente lee la escena antes de contestar. No adivina: recoge coordenadas, nombres de calles, capas activas y escala de vista, y responde con eso. Preguntar “¿qué ciudad es esta?” en mitad de un vuelo tiene respuesta porque el contexto viaja con la pregunta.

Tu clave nunca llega al navegador. El endpoint /api/realtime/token del proxy devuelve un token de sesión efímero. El OPENAI_API_KEY se queda en tu máquina.

El agente solo confirma lo que de verdad ocurrió. Nada de “hecho” cuando la herramienta falló. Y en visión a nivel de calle, la instrucción explícita es no alucinar carteles: lee lo que aparece legible en la captura o calla.

Construye agentes con criterio

Un agente con 28 herramientas no se improvisa: se diseña por capas

Verás los seis niveles de arquitectura de un agente (tools, guardarraíles, memoria, skills, MCP y orquestación) con código real, para que el tuyo no se descontrole cuando le das acceso a cosas que importan.

Ver el método entero →

Masterclass en directo · 6 niveles de arquitectura

El presupuesto como decisión de arquitectura ¶

Aquí es donde el proyecto se separa de la demo bonita.

Cuando tu app depende de trece proveedores externos, el control de gasto no es una preocupación de negocio que resuelves al final. Es código.

• Gobernador de créditos de OpenSky. Hay un módulo que lleva la cuenta del presupuesto de peticiones y decide cuándo refrescar.
• Presupuesto diario de teselas de TomTom. Con un tope por defecto de 40.000 teselas configurable por variable de entorno, y caché de 120 segundos por delante.
• TLEs cacheados en disco. Los elementos orbitales cambian despacio: no tiene sentido volver a pedirlos cada arranque.
• Tope duro en la voz. La sesión muestra el gasto acumulado en tiempo real junto al micrófono, avisa a los 2 dólares y corta la sesión a los 5. Además hay un selector de modelo estándar o mini, y la ventana de contexto de voz se mantiene corta a propósito.
• Caché con servicio en degradado. Varios endpoints sirven la última respuesta buena durante una caída del proveedor. El catálogo de radio puede tirar de caché hasta siete días antes de darse por muerto.

El propio repositorio deja clara una distinción que mucha gente confunde: estos topes de aplicación no son topes de facturación. Te dicen que configures las cuotas y las alertas en el proveedor, porque una alerta de presupuesto no detiene el gasto.

Y hay un detalle en el módulo de costes de voz que es puro oficio: un aviso en mayúsculas recordando que los identificadores de modelo y los precios son hechos externos que cambian, con la fecha exacta en la que se leyeron de la documentación de OpenAI.

⚠️ Si tu código guarda un precio de un tercero, guarda también la fecha en que lo comprobaste. Tu yo de dentro de seis meses te lo agradecerá.

Los datos que viajan dentro del repositorio ¶

No todo llega por red. El repositorio empaqueta datasets estáticos para que la app tenga algo que enseñar nada más arrancar: 4.351 centros de datos, 704 presas y 712 cables submarinos, más límites de barrios y geometrías de Natural Earth.

Y aquí el proyecto hace algo que casi nadie hace: ninguno de esos datasets es MIT, y lo dice.

La licencia del repositorio incluye una exclusión explícita. Los cables submarinos vienen de TeleGeography bajo CC BY-NC-SA, que es NonCommercial. En vez de esconderlo o de quitar la capa, el DATA_SOURCES.md lo pone por delante: si tu uso es comercial, borra esa carpeta, que está aislada precisamente para eso.

Cada carpeta de local_data/ lleva su propio README de procedencia. Cada modelo 3D empaquetado registra creador, fuente, licencia y si fue modificado. Y las atribuciones no viven solo en un fichero markdown: se registran en el display de créditos de Cesium y siguen visibles incluso en modo limpio y en modo grabación.

Es la diferencia entre cumplir una licencia y diseñar para cumplirla.

La línea que el proyecto se niega a cruzar ¶

Con un juguete que tiene la estética de una sala de operaciones militar, la pregunta ética llega sola. El repositorio la contesta antes de que la hagas, y la contesta en dos planos.

En el plano del producto, la línea está escrita: el proyecto modela eventos, activos, infraestructura y sistemas. No construye funciones de búsqueda de personas concretas, ni reconocimiento facial, ni seguimiento de individuos. Y los pull requests que crucen esa línea no se van a mergear. La frase del README es directa: aquí las personas no son un tipo de consulta.

En el plano de la honestidad del dato, el proyecto etiqueta lo que es modelado. El tráfico está simulado sobre carreteras reales: con clave de TomTom las velocidades del flujo son reales, pero las posiciones de los vehículos individuales no son observaciones. Las poses de las cámaras son estimaciones que tú mismo recalibras arrastrando un gizmo. Y el replay de un lanzamiento lleva la etiqueta RECONSTRUCTED ESTIMATE encima, porque eso es exactamente lo que es.

Hay incluso un aviso de no usar nada de esto para navegación aérea o marítima, respuesta a emergencias o decisiones médicas. Suena a legalese. Yo lo leo de otra forma: alguien pensó en quién va a malinterpretar la pantalla y escribió el desmentido antes de que pasara.

Bilawal Sidhu, o por qué este proyecto existe ¶

Esto no lo montó un desconocido en un fin de semana.

Bilawal Sidhu pasó seis años en Google como Senior Product Manager de computación espacial y mapas 3D. Su firma está en Immersive View de Google Maps, en la ARCore Geospatial API y en la captura VR de YouTube. Es decir: el tipo que hoy fusiona trece capas sobre un globo fotorrealista se pasó media década construyendo ese globo desde dentro.

Hoy es curator de tecnología y presentador en TED, venture scout para a16z y asesor de empresas de IA generativa e inteligencia espacial. Su audiencia acumulada supera los 2,1 millones de personas, y la serie de vídeos de God’s Eye View —que antes se llamaba WorldView— pasó de 5 millones de visualizaciones en YouTube y 25 millones sumando redes.

Durante meses la gente le pidió el código. Él tenía otro plan: dejar el repositorio como cliente open source y construir aparte un producto profesional.

Así que preguntó.

La respuesta no fue sutil, y en agosto de 2026 el repositorio salió con licencia MIT. Mantiene el proyecto junto a Sameh Khamis desde Halfpixel, donde ahora están montando una versión hospedada porque la petición más repetida tras el lanzamiento no fue una función nueva: fue “dame un enlace y ya”.

Hay una frase suya en el README que se queda contigo si trabajas con datos. Construye en este espacio una semana, dice, y aprendes que el presente es la parte barata. En el momento en que intentas ir hacia atrás en el tiempo —teselar, servir y hacer scrub de qué pasó y qué cambió, a una resolución que sirva de algo— el dato se vuelve caro y el cómputo se vuelve brutal.

Eso es alguien que ya se ha pegado con el problema.

Arrancarlo en tu máquina ¶

No hace falta cuenta ni claves. El camino de terminal es el de siempre, con Node 24.14 o superior:

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

Abre http://localhost:4173 y eliges misión de arranque. Sin ninguna clave tienes imágenes de satélite de Esri, terreno, vuelos, tráfico militar, satélites, terremotos, cámaras públicas, radio y lanzamientos.

El npm run doctor es otro detalle que merece copiarse: verifica la versión de Node, las rutas de proveedor y dónde ha encontrado cada credencial configurada, sin imprimir ni un valor. Un doctor de entorno que no filtra secretos por consola.

Las claves se añaden dentro de la app, en el panel POWER UP, no editando ficheros. Se escriben en .env (o en el fichero del lanzador si usas Pinokio), y el fichero se marca como solo-propietario antes de que se escriba nada dentro. Si ya tienes las claves en tu shell o en el Keychain de macOS, el panel las muestra como configuradas externamente y en solo lectura.

Lo que puedes llevarte a tus propios proyectos ¶

Aunque nunca vayas a tocar un globo 3D, aquí hay cinco patrones que valen para cualquier app que consuma datos de terceros.

Empieza por buscar quién ya publica el dato. Antes de pensar en scrapear o en montar la captura, revisa qué se emite en abierto. La astucia de este proyecto no está en la tecnología: está en la búsqueda previa.

Mete el proxy de credenciales desde el día uno. Aunque tu app sea solo local. Cuesta poco al principio y es carísimo de retrofitear.

Retrasa el render para poder interpolar. Si tu fuente llega a ráfagas, ir un intervalo por detrás te da siempre dos puntos conocidos y elimina los saltos.

Convierte el presupuesto en código. Contadores, topes duros, cachés con servicio en degradado. Y deja escrito en el propio código que un tope de app no es un tope de facturación.

Etiqueta lo que es estimado. RECONSTRUCTED ESTIMATE encima de una trayectoria modelada no le quita magia a la escena. Le da credibilidad a todo lo demás que enseñas.

Preguntas frecuentes ¶

¿Qué es exactamente God’s Eye View? ¶

Es un simulador de globo terráqueo 3D que funciona en el navegador y visualiza datos públicos en tiempo real: aviones, barcos, satélites, terremotos, tráfico, incendios, radio y cámaras públicas. Lo creó Bilawal Sidhu y se publicó con licencia MIT en agosto de 2026.

¿Con qué tecnologías está construido? ¶

Vanilla JavaScript sin framework, CesiumJS como motor de globo 3D sobre WebGL, y Vite como bundler y servidor de desarrollo. Solo seis dependencias de producción, entre ellas satellite.js para propagación SGP4 y egm96-universal para cálculos de geoide.

¿Necesito claves de API para usarlo? ¶

No para arrancar. Once de las trece capas tienen camino sin clave, incluidas vuelos, satélites, terremotos, cámaras públicas y radio. Las claves son mejoras: Cesium ion para las ciudades 3D fotorrealistas, OpenAI para la voz, AISStream para barcos, NASA FIRMS para incendios y TomTom para tráfico real.

¿Cuánto cuesta tenerlo en marcha? ¶

La mayoría de capas cuesta cero, sin registro. Otras son gratis con alta. La única que consume dinero real es la voz con la Realtime API de OpenAI, unos pocos céntimos por minuto activo, y la app mete un aviso a los 2 dólares y un tope duro que corta la sesión a los 5.

¿De dónde salen los datos de aviones? ¶

De OpenSky Network como fuente principal, con adsb.lol como respaldo acotado cuando OpenSky no devuelve una foto usable. Los vuelos militares vienen de adsb.lol. Ojo con la licencia de OpenSky: es de uso no comercial.

¿Puedo usar God’s Eye View en un proyecto comercial? ¶

El código es MIT, pero eso cubre solo el código. Los datasets empaquetados y las fuentes en vivo mantienen sus propias licencias, y algunas son incompatibles: los cables submarinos de TeleGeography son NonCommercial y hay que borrarlos, y OpenSky puede exigir un acuerdo previo. El fichero DATA_SOURCES.md documenta el caso de cada fuente.

¿Cómo consigue que los aviones se muevan con suavidad? ¶

Renderizando un intervalo de sondeo por detrás del tiempo real. Como los datos llegan cada 15 o 30 segundos, ese retraso deliberado garantiza dos posiciones conocidas que envuelven el instante a pintar, así que se interpola en lugar de extrapolar. Cuando falta el par, entra dead reckoning.

¿Dónde está el backend del proyecto? ¶

Dentro de vite.config.js, que ocupa 342 KB. Son veintiséis rutas de API montadas como middlewares de Vite con configureServer. Solo existen mientras tienes el servidor de desarrollo en marcha, y su función principal es que ninguna clave privada llegue al navegador.

¿Se puede compartir mi instancia con otras personas? ¶

Por defecto no: el servidor escucha solo en localhost. Puedes exponerlo a la red local de forma explícita, pero entonces cualquiera que llegue al servidor usa tus claves configuradas. El proyecto deshabilita el panel de claves cuando detecta modo compartido y recomienda un proxy de autenticación revisado si necesitas acceso remoto.

¿Sirve para buscar o seguir a personas concretas? ¶

No, y es una decisión deliberada. El proyecto modela eventos, activos, infraestructura y sistemas, no individuos. No incluye búsqueda de personas ni reconocimiento facial, y los mantenedores han declarado que no van a aceptar pull requests que crucen esa línea.

Fuentes ¶

• God’s Eye View, repositorio oficial en GitHub — Bilawal Sidhu y Sameh Khamis, licencia MIT, 2026
• DATA_SOURCES.md — documentación de licencias y atribución de las trece capas
• Perfil profesional de Bilawal Sidhu — seis años en Google (Immersive View, ARCore Geospatial API), TED, a16z
• bilawal.ai — web personal del creador
• CesiumJS — el motor de globo 3D sobre el que está construido
• OpenSky Network — la fuente principal de vuelos en directo, licencia no comercial
• CelesTrak — elementos orbitales TLE, Dr. T.S. Kelso

Las capturas animadas de este post son propiedad de Bilawal Sidhu, se enlazan desde el repositorio original y no están cubiertas por la licencia MIT del código.

🧨 Cada domingo, una dosis de dinamita sobre programación con IA para +7.200 developers. Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter