Este proyecto convierte señales públicas en un globo 3D con IA, voz y datos en vivo
La mayor parte del trabajo OSINT empieza como una pila de pestañas.
Una pestaña para aviones. Otra para barcos. Otra para terremotos. Otra para pasos de satélites. Otra para tráfico, cámaras públicas, infraestructura, clima, datos de lanzamientos y capas de mapa. Los datos son públicos, pero el flujo de trabajo está fragmentado.
God’s Eye View toma otro camino: convierte esas señales públicas en un globo 3D fotorealista, basado en navegador, que puedes correr localmente, inspeccionar y extender.
El proyecto se describe como un “simulador de satélite espía en tu navegador”, pero la parte importante viene después: las fuentes son públicas y los datos son reales.
Eso lo vuelve un proyecto útil para estudiar como desarrolladores, no solo una demo vistosa.
Combina aviones, barcos, satélites, terremotos, tráfico, cámaras públicas, radio, bikeshare, incendios activos, misiones espaciales e infraestructura mapeada en un único globo basado en Cesium. También agrega interacción por voz mediante un agente impulsado por OpenAI Realtime, para pedirle a la interfaz que navegue, anote, inspeccione entidades, cambie capas o resuma la escena actual.
El resultado se siente cinematográfico. Pero las preguntas de ingeniería son muy prácticas.
¿Cómo etiquetas qué es live y qué es simulado? ¿Cómo manejas claves de API opcionales? ¿Cómo evitas que los secretos lleguen al navegador? ¿Cómo explicas licencias de datos de terceros? ¿Cómo construyes una interfaz de IA sobre señales públicas sin fingir que la herramienta sabe más de lo que realmente sabe?
Ahí es donde God’s Eye View se vuelve interesante.
Qué puedes correr localmente
God’s Eye View es una aplicación de Vite y JavaScript vanilla construida sobre CesiumJS, Google Photorealistic 3D Tiles y varias fuentes de datos públicas, tanto live como empaquetadas.
El quick start es directo, con un requisito importante: el repositorio actualmente requiere Node.js 24.14.x o 26.x, exigido desde package.json.
El flujo local básico es:
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
Después abrís:
http://localhost:4173
La clave requerida es GOOGLE_MAPS_API_KEY, porque el planeta 3D fotorealista viene de Google Map Tiles API. El README es claro en que este es un proveedor medido, así que conviene configurar cuotas y alertas de presupuesto antes de un uso serio.
Desde ahí, muchas capas funcionan sin cuenta ni registro. El README lista aviones, tráfico militar, satélites, terremotos, CCTV, radio, bikeshare, misiones espaciales, instalaciones mapeadas y datasets empaquetados como disponibles sin claves.
Otras capacidades mejoran cuando agregas tus propias claves:
OPENAI_API_KEYpara interacción por voz y resúmenes del HUD con IA.AISSTREAM_API_KEYpara barcos en vivo.- Clave de
NASA FIRMSpara incendios activos. TOMTOM_API_KEYpara tráfico real en lugar de simulación aproximada.CESIUM_ION_TOKENpara capas de imágenes Bing.- Credenciales de OpenSky para más créditos de consulta de vuelos.
Esta separación importa porque el proyecto no finge que todas las señales tienen el mismo costo, calidad o disponibilidad. Marca las capas según si no necesitan nada, si requieren una clave gratuita o si dependen de un proveedor medido.
Eso es buena UX para desarrolladores.
Primera lección: público no significa simple
El README presenta la herramienta como inteligencia espacial open source. Suena limpio, pero la realidad de implementación es desordenada de la forma en que el software real suele serlo.
Los datos de aviones vienen de OpenSky y adsb.lol. Los barcos vienen de AISStream. Los satélites usan TLEs de CelesTrak. Los terremotos vienen de USGS. El tráfico puede usar TomTom, con geometría vial de OpenStreetMap. Los paquetes de cámaras públicas vienen de APIs de ciudades como Austin, California Caltrans y Transport for London. La radio usa Radio Browser y emisoras. El clima viene de Open-Meteo. Los lanzamientos espaciales usan Launch Library 2.
Cada fuente tiene sus propios términos, límites, frecuencia de actualización y comportamiento ante fallos.
Por eso el archivo DATA_SOURCES.md del repositorio vale la pena antes de tratar esto como un juguete. El proyecto dice que el código fuente tiene licencia MIT, pero los datos y assets visuales de terceros mantienen sus propias licencias y términos. Algunos datasets empaquetados están explícitamente separados porque no son compatibles con MIT.
Para desarrolladores, esa es la primera lección práctica: que el código sea open source no convierte automáticamente los datos en abiertos para cualquier caso de uso.
Si haces un fork, una demo interna o una variante comercial, el archivo de fuentes de datos no es decoración documental. Es parte del límite del producto.
Segunda lección: la degradación honesta genera confianza
El changelog del 24 de agosto en main agrega varios cambios relevantes para la confianza.
Una corrección indica que la ausencia de una clave opcional de NASA FIRMS ya no convierte toda la misión Environmental en LOAD FAILED. La fila de FIRMS sigue mostrando KEY REQUIRED, mientras los terremotos continúan cargando.
Puede sonar mínimo, pero es exactamente el tipo de detalle que separa una herramienta real de una demo.
En una interfaz de múltiples fuentes, una clave faltante no debería hacer que todo el entorno parezca roto. La UI debería explicar qué falta, seguir funcionando donde puede y evitar convertir un éxito parcial en un fallo total.
El README también dice que algunas experiencias son modeladas, no live. El tráfico sin clave se etiqueta como simulación. Las poses de cámaras son estimadas hasta que se calibran. La reproducción del ascenso de lanzamientos se marca como estimación reconstruida. Las capas exponen estado de fuente y frescura, incluyendo estados parciales, demorados, simulados y no disponibles.
Ese es el instinto correcto para una herramienta de estilo OSINT.
Cuando mostrás señales públicas en un globo 3D hermoso, la interfaz puede generar una falsa autoridad. Un estilo táctico puede hacer que datos estimados se sientan precisos. Una proyección de cámara puede sentirse como evidencia incluso cuando la calibración es aproximada. Un lanzamiento reconstruido puede parecer live si la etiqueta es débil.
God’s Eye View trabaja contra eso haciendo visibles la procedencia y el estado.
No perfectamente, y no como un sistema de producción endurecido, pero sí de una forma que los desarrolladores pueden inspeccionar y mejorar.
Tercera lección: mantené los secretos del lado del servidor
Las funciones de voz son una de las partes más llamativas del proyecto.
Con una clave de OpenAI, puedes hablarle al globo. El README describe comandos de voz para navegación, anotación, preguntas sobre entidades, controles de capas, cambios de estilo visual, rutas y resúmenes de escena en vivo.
Por ejemplo, la app puede responder preguntas sobre la vista actual, aviones seleccionados, barcos, datacenters o señales cercanas. Puede dibujar rutas y anotaciones sobre el mundo. Puede cambiar modos visuales y operar capas sin usar las manos.
Pero el detalle de implementación importante es cómo se maneja la clave.
El README dice que OPENAI_API_KEY nunca llega al navegador. El cliente recibe en su lugar un token de sesión de corta duración. Otros proveedores que requieren secretos también se intermedian del lado del servidor, mientras que los destinos de proxy están fijos o en allowlist, y los caminos de mayor riesgo agregan requests acotados, timeouts, límites de respuesta y errores saneados cuando corresponde.
Esto importa porque las apps geoespaciales basadas en navegador suelen vivir en una frontera incómoda. Se sienten como demos frontend, pero tocan APIs pagas, micrófonos de usuario, proxies de red y fuentes de datos en vivo.
Si un servidor local de desarrollo se expone a una LAN, el README advierte que puede intermediar claves API configuradas para cualquiera que pueda alcanzarlo. El proyecto recomienda optar explícitamente por compartir en LAN, usar throttles por IP y configurar límites de presupuesto del lado del proveedor.
Ese es exactamente el tipo de advertencia que más demos de IA deberían incluir.
La historia local-first no es “nada puede salir mal”. Es “estos son los límites, esto queda local y esto se vuelve riesgoso cuando lo compartes”.
Cuarta lección: las herramientas de voz necesitan grounding
La capa de voz no es simplemente speech-to-text pegado arriba de un mapa.
El proyecto describe un agente realtime que puede traer contexto de la escena antes de responder, incluyendo coordenadas, nombres de calles, capas activas y escala de vista. Puede responder preguntas sobre entidades seleccionadas usando su telemetría en vivo. A nivel calle, puede usar grounding visual del viewport para identificar carteles y nombres de edificios visibles, con instrucciones de no inventar etiquetas.
Ese es un patrón importante para interfaces de IA sobre datos operativos.
Un agente de voz sin contexto de escena es un control remoto. Un agente de voz con contexto se convierte en una interfaz de análisis. Pero cuando empieza a sonar como un analista, necesita restricciones.
El changelog del 24 de agosto agrega “narración honesta de identidad de aeronaves”: callsign, operador, matrícula, tipo y ruta vienen solamente del contexto del contacto seleccionado, y la ausencia de operador, ruta o tipo enriquecido se nombra explícitamente.
Es una decisión de producto pequeña, pero significativa.
Una implementación más débil llenaría huecos con lenguaje confiado. Una mejor implementación nombra qué sabe, de dónde lo sabe y qué falta.
Para desarrolladores que construyen herramientas de IA sobre sistemas live, esta es la lección central: la personalidad del modelo importa menos que el límite de evidencia.
Qué es realmente live
Según el README, el globo incluye trece capas live, con diez disponibles sin claves.
Las capas live o de señales públicas incluyen:
- Vuelos en vivo.
- Tráfico militar ADS-B.
- Barcos en vivo.
- Satélites.
- Terremotos.
- Tráfico.
- CCTV público.
- Radio.
- Bikeshare.
- Incendios activos.
- Misiones espaciales.
- Instalaciones mapeadas.
- Datasets de infraestructura empaquetados.
Algunas de estas señales son realmente live. Otras son demoradas, interpoladas, acotadas, reconstruidas o simuladas según las claves y el estado de las fuentes.
Por ejemplo, el README dice que los aviones se renderizan un intervalo de polling detrás del tiempo real para que el cliente pueda interpolar con suavidad. El tráfico corre en modo simulación salvo que se configure una clave de TomTom. La reproducción de lanzamientos espaciales se marca como estimación reconstruida. Las posiciones de cámaras son publicadas, pero las poses pueden estar estimadas hasta que se calibren.
Este es exactamente el matiz que conviene conservar en el artículo, porque mantiene la historia honesta.
El proyecto no es “un mapa mundial omnisciente en vivo”. Es una interfaz de fusión de señales públicas, legible para desarrolladores, con etiquetas de fuente y estado.
Eso sigue siendo muy interesante. Solo que es más interesante cuando se describe con precisión.
Por qué debería importarle a los desarrolladores
God’s Eye View es relevante para lectores de yoDEV porque se ubica en la intersección de varias tendencias de desarrollo:
- Las interfaces 3D basadas en navegador ya son lo bastante potentes para herramientas espaciales serias.
- Las APIs de datos públicos abundan, pero la integración y la procedencia siguen siendo difíciles.
- Los agentes de voz con IA se están moviendo de compañeros de chat a interfaces operativas.
- El desarrollo local-first sigue siendo importante cuando hay claves API, micrófonos y servicios pagos involucrados.
- Las demos open source necesitan límites más claros sobre licencias, términos de datos y seguridad.
El proyecto también es inusualmente inspeccionable.
El README dice que usa JavaScript vanilla, CesiumJS, Vite, Google Photorealistic 3D Tiles y OpenAI Realtime API. El repo incluye documentación sobre comportamiento actual en runtime, testing, seguridad, fuentes de datos, límites de contribución y procedencia de medios.
Eso lo vuelve un buen candidato para un artículo estilo Devy: no solo “miren esta cosa impresionante”, sino “corran esto, inspeccionen cómo funciona y noten qué decisiones de diseño importan”.
Una forma práctica de explorarlo
Si lo pruebas localmente, lo encararía en tres pasadas.
Primero, ejecuta la configuración mínima con Google Maps y sin claves opcionales. Confirma qué funciona con fuentes públicas o sin clave. Mira vuelos, satélites, terremotos, CCTV, radio, instalaciones mapeadas y capas empaquetadas.
Segundo, inspecciona cómo la UI etiqueta datos faltantes o simulados. Activa la misión Environmental sin una clave de FIRMS. Revisa si el tráfico es live o simulado. Mira cómo las vistas de cámaras, las reproducciones de lanzamientos y las entidades rastreadas describen su estado de fuente.
Tercero, agrega la capa de voz con IA solo después de que el mapa básico funcione. Úsala como función de desarrollo, no como truco de magia. Pídele que navegue, anote, seleccione entidades cercanas, cambie modos y responda preguntas sobre objetos seleccionados. Después inspecciona qué contexto usó y dónde se niega o nombra datos faltantes.
Ahí es donde el proyecto se vuelve útil como patrón.
No porque todos los equipos necesiten un globo OSINT, sino porque muchos equipos están construyendo interfaces sobre señales live fragmentadas: observabilidad, logística, seguridad, flotas, IoT, operaciones internas, sistemas urbanos, infraestructura o datos de investigación.
God’s Eye View es un ejemplo visible y hackeable de cómo puede sentirse ese tipo de interfaz.
La advertencia
Esto no es una plataforma de inteligencia de producción endurecida.
El README dice que el proyecto es un cliente open source en evolución para exploración y aprendizaje, no un servicio de producción endurecido. Los costos y términos de proveedores pueden cambiar. Algunas fuentes de datos tienen restricciones no comerciales o propietarias. Algunas vistas son modeladas, estimadas, demoradas o reconstruidas. Compartir en LAN puede exponer acceso intermediado a claves si se habilita sin cuidado.
Esas advertencias no debilitan el proyecto. Lo vuelven más creíble.
Una herramienta de señales públicas debería ser explícita sobre qué sabe, qué estima, qué simula, cuánto cuesta y para qué no debería usarse.
God’s Eye View hace eso con más claridad que la mayoría de las demos geoespaciales virales.
El patrón más grande
El gancho es visual: un globo fotorealista lleno de aviones, barcos, satélites, terremotos, cámaras y señales en vivo.
Pero la lección para desarrolladores es arquitectónica.
God’s Eye View muestra qué pasa cuando combinas feeds de datos públicos, un motor 3D nativo del navegador, manejo local-first de claves, atribución de fuentes, herramientas de voz realtime y etiquetas explícitas de incertidumbre en una sola interfaz.
Esa combinación va a aparecer en más lugares.
No solo en OSINT. En devtools. En dashboards de seguridad. En logística. En sistemas de ciudades inteligentes. En monitoreo de infraestructura. En respuesta a incidentes. En cualquier contexto donde lo difícil no sea tener datos, sino convertir muchas señales imperfectas en algo que una persona pueda operar.
El mundo ya está emitiendo las señales.
La pregunta para desarrolladores es cómo las convertimos en software de forma honesta, segura y útil.