Este projeto converte sinais públicos em um globo 3D com IA, voz e dados em tempo real
A maior parte do trabalho OSINT começa como uma pilha de abas.
Uma aba para aviões. Outra para navios. Outra para terremotos. Outra para passagens de satélites. Outra para tráfego, câmeras públicas, infraestrutura, clima, dados de lançamentos e camadas de mapa. Os dados são públicos, mas o fluxo de trabalho está fragmentado.
God’s Eye View toma outro caminho: converte esses sinais públicos em um globo 3D fotorrealista, baseado em navegador, que você pode executar localmente, inspecionar e estender.
O projeto se descreve como um “simulador de satélite espião no seu navegador”, mas a parte importante vem depois: as fontes são públicas e os dados são reais.
Isso o torna um projeto útil para estudar como desenvolvedores, não apenas uma demo vistosa.
Combina aviões, navios, satélites, terremotos, tráfego, câmeras públicas, rádio, bikeshare, incêndios ativos, missões espaciais e infraestrutura mapeada em um único globo baseado em Cesium. Também adiciona interação por voz por meio de um agente impulsionado por OpenAI Realtime, para pedir à interface que navegue, anote, inspecione entidades, mude camadas ou resuma a cena atual.
O resultado parece cinematográfico. Mas as questões de engenharia são muito práticas.
Como você etiqueta o que é tempo real e o que é simulado? Como você lida com chaves de API opcionais? Como você evita que os segredos cheguem ao navegador? Como você explica licenças de dados de terceiros? Como você constrói uma interface de IA sobre sinais públicos sem fingir que a ferramenta sabe mais do que realmente sabe?
Aí é onde God’s Eye View fica interessante.
O que você pode executar localmente
God’s Eye View é uma aplicação Vite e JavaScript vanilla construída sobre CesiumJS, Google Photorealistic 3D Tiles e várias fontes de dados públicas, tanto em tempo real quanto empacotadas.
O quick start é direto, com um requisito importante: o repositório atualmente requer Node.js 24.14.x ou 26.x, exigido desde package.json.
O fluxo local básico é:
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
Depois você abre:
http://localhost:4173
A chave necessária é GOOGLE_MAPS_API_KEY, porque o planeta 3D fotorrealista vem da Google Map Tiles API. O README deixa claro que este é um provedor medido, então convém configurar quotas e alertas de orçamento antes de um uso sério.
De lá, muitas camadas funcionam sem conta ou registro. O README lista aviões, tráfego militar, satélites, terremotos, CCTV, rádio, bikeshare, missões espaciais, instalações mapeadas e datasets empacotados como disponíveis sem chaves.
Outras capacidades melhoram quando você adiciona suas próprias chaves:
OPENAI_API_KEYpara interação por voz e resumos do HUD com IA.AISSTREAM_API_KEYpara navios em tempo real.- Chave da
NASA FIRMSpara incêndios ativos. TOMTOM_API_KEYpara tráfego real em vez de simulação aproximada.CESIUM_ION_TOKENpara camadas de imagens Bing.- Credenciais do OpenSky para mais créditos de consulta de voos.
Esta separação importa porque o projeto não finge que todos os sinais têm o mesmo custo, qualidade ou disponibilidade. Marca as camadas conforme se não precisam de nada, se requerem uma chave gratuita ou se dependem de um provedor medido.
Isso é boa UX para desenvolvedores.
Primeira lição: público não significa simples
O README apresenta a ferramenta como inteligência espacial open source. Parece limpo, mas a realidade de implementação é desorganizada da forma como o software real costuma ser.
Os dados de aviões vêm de OpenSky e adsb.lol. Os navios vêm de AISStream. Os satélites usam TLEs de CelesTrak. Os terremotos vêm de USGS. O tráfego pode usar TomTom, com geometria viária de OpenStreetMap. Os pacotes de câmeras públicas vêm de APIs de cidades como Austin, California Caltrans e Transport for London. O rádio usa Radio Browser e emissoras. O clima vem de Open-Meteo. Os lançamentos espaciais usam Launch Library 2.
Cada fonte tem seus próprios termos, limites, frequência de atualização e comportamento em caso de falhas.
Por isso o arquivo DATA_SOURCES.md do repositório vale a pena antes de tratar isso como um brinquedo. O projeto diz que o código-fonte tem licença MIT, mas os dados e assets visuais de terceiros mantêm suas próprias licenças e termos. Alguns datasets empacotados são explicitamente separados porque não são compatíveis com MIT.
Para desenvolvedores, essa é a primeira lição prática: que o código seja open source não converte automaticamente os dados em abertos para qualquer caso de uso.
Se você faz um fork, uma demo interna ou uma variante comercial, o arquivo de fontes de dados não é decoração documental. É parte do limite do produto.
Segunda lição: a degradação honesta gera confiança
O changelog do 24 de agosto em main adiciona várias mudanças relevantes para a confiança.
Uma correção indica que a ausência de uma chave opcional da NASA FIRMS não converte mais toda a missão Environmental em LOAD FAILED. A linha FIRMS continua mostrando KEY REQUIRED, enquanto os terremotos continuam carregando.
Pode parecer mínimo, mas é exatamente o tipo de detalhe que separa uma ferramenta real de uma demo.
Em uma interface de múltiplas fontes, uma chave faltante não deveria fazer com que todo o ambiente parecesse quebrado. A UI deveria explicar o que falta, continuar funcionando onde pode e evitar converter um sucesso parcial em uma falha total.
O README também diz que algumas experiências são modeladas, não tempo real. O tráfego sem chave é etiquetado como simulação. As poses das câmeras são estimadas até que sejam calibradas. A reprodução do ascenso de lançamentos é marcada como estimativa reconstruída. As camadas expõem estado de fonte e frescor, incluindo estados parciais, atrasados, simulados e indisponíveis.
Esse é o instinto correto para uma ferramenta de estilo OSINT.
Quando você mostra sinais públicos em um globo 3D lindo, a interface pode gerar uma falsa autoridade. Um estilo tático pode fazer com que dados estimados pareçam precisos. Uma projeção de câmera pode parecer evidência mesmo quando a calibração é aproximada. Um lançamento reconstruído pode parecer tempo real se a etiqueta for fraca.
God’s Eye View trabalha contra isso tornando visíveis a proveniência e o estado.
Não perfeitamente, e não como um sistema de produção endurecido, mas de uma forma que os desenvolvedores podem inspecionar e melhorar.
Terceira lição: mantenha os segredos no lado do servidor
As funções de voz são uma das partes mais impressionantes do projeto.
Com uma chave da OpenAI, você pode falar com o globo. O README descreve comandos de voz para navegação, anotação, perguntas sobre entidades, controles de camadas, mudanças de estilo visual, rotas e resumos de cena em tempo real.
Por exemplo, o app pode responder perguntas sobre a vista atual, aviões selecionados, navios, datacenters ou sinais próximos. Pode desenhar rotas e anotações sobre o mundo. Pode mudar modos visuais e operar camadas sem usar as mãos.
Mas o detalhe de implementação importante é como a chave é tratada.
O README diz que OPENAI_API_KEY nunca chega ao navegador. O cliente recebe em seu lugar um token de sessão de curta duração. Outros provedores que requerem segredos também são intermediados do lado do servidor, enquanto os destinos de proxy são fixos ou em allowlist, e os caminhos de maior risco adicionam requests limitados, timeouts, limites de resposta e erros sanitizados quando apropriado.
Isso importa porque apps geoespaciais baseados em navegador costumam viver em uma fronteira incômoda. Parecem demos frontend, mas tocam APIs pagas, microfones do usuário, proxies de rede e fontes de dados em tempo real.
Se um servidor local de desenvolvimento for exposto a uma LAN, o README avisa que ele pode intermediar chaves de API configuradas para qualquer pessoa que consiga acessá-lo. O projeto recomenda optar explicitamente por compartilhar em LAN, usar throttles por IP e configurar limites de orçamento do lado do provedor.
Esse é exatamente o tipo de aviso que mais demos de IA deveriam incluir.
A história local-first não é “nada pode dar errado”. É “estes são os limites, isto fica local e isto fica arriscado quando você compartilha”.
Quarta lição: ferramentas de voz precisam de grounding
A camada de voz não é simplesmente speech-to-text colado em cima de um mapa.
O projeto descreve um agente em tempo real que pode trazer contexto da cena antes de responder, incluindo coordenadas, nomes de ruas, camadas ativas e escala de visualização. Pode responder perguntas sobre entidades selecionadas usando sua telemetria em tempo real. No nível de rua, pode usar grounding visual do viewport para identificar placas e nomes de edifícios visíveis, com instruções para não inventar rótulos.
Esse é um padrão importante para interfaces de IA sobre dados operacionais.
Um agente de voz sem contexto de cena é um controle remoto. Um agente de voz com contexto se torna uma interface de análise. Mas quando começa a soar como um analista, precisa de restrições.
O changelog de 24 de agosto adiciona “narração honesta de identidade de aeronaves”: indicativo, operador, matrícula, tipo e rota vêm apenas do contexto do contato selecionado, e a ausência de operador, rota ou tipo enriquecido é nomeada explicitamente.
É uma decisão de produto pequena, mas significativa.
Uma implementação mais fraca preencheria lacunas com linguagem confiante. Uma implementação melhor nomeia o que sabe, de onde sabe e o que falta.
Para desenvolvedores que constroem ferramentas de IA sobre sistemas em tempo real, essa é a lição central: a personalidade do modelo importa menos que o limite de evidência.
O que é realmente em tempo real
Segundo o README, o globo inclui treze camadas em tempo real, com dez disponíveis sem chaves.
As camadas em tempo real ou de sinais públicos incluem:
- Voos em tempo real.
- Tráfego militar ADS-B.
- Navios em tempo real.
- Satélites.
- Terremotos.
- Tráfego.
- CCTV público.
- Rádio.
- Bikeshare.
- Incêndios ativos.
- Missões espaciais.
- Instalações mapeadas.
- Conjuntos de dados de infraestrutura empacotados.
Alguns desses sinais são realmente em tempo real. Outros são atrasados, interpolados, limitados, reconstruídos ou simulados conforme as chaves e o estado das fontes.
Por exemplo, o README diz que os aviões são renderizados um intervalo de polling atrás do tempo real para que o cliente possa interpolar suavemente. O tráfego é executado em modo de simulação, a menos que uma chave do TomTom seja configurada. A reprodução de lançamentos espaciais é marcada como estimativa reconstruída. As posições das câmeras são publicadas, mas as poses podem ser estimadas até serem calibradas.
Este é exatamente o matiz que vale a pena manter no artigo, porque mantém a história honesta.
O projeto não é “um mapa mundial onisciente em tempo real”. É uma interface de fusão de sinais públicos, legível para desenvolvedores, com rótulos de fonte e estado.
Isso ainda é muito interessante. Apenas é mais interessante quando descrito com precisão.
Por que deveria importar aos desenvolvedores
God’s Eye View é relevante para leitores de yoDEV porque se situa na intersecção de várias tendências de desenvolvimento:
- As interfaces 3D baseadas em navegador já são potentes o suficiente para ferramentas espaciais sérias.
- As APIs de dados públicos são abundantes, mas a integração e a procedência ainda são difíceis.
- Os agentes de voz com IA estão se movendo de companheiros de chat para interfaces operacionais.
- O desenvolvimento local-first continua sendo importante quando há chaves de API, microfones e serviços pagos envolvidos.
- As demos open source precisam de limites mais claros sobre licenças, termos de dados e segurança.
O projeto também é inusitadamente inspecionável.
O README diz que usa JavaScript vanilla, CesiumJS, Vite, Google Photorealistic 3D Tiles e OpenAI Realtime API. O repo inclui documentação sobre comportamento em tempo de execução, testes, segurança, fontes de dados, limites de contribuição e procedência de mídia.
Isso o torna um bom candidato para um artigo estilo Devy: não apenas “olhem essa coisa impressionante”, mas “executem isto, inspecionem como funciona e notem quais decisões de design importam”.
Uma forma prática de explorá-lo
Se você o testar localmente, eu o abordaria em três passadas.
Primeiro, execute a configuração mínima com Google Maps e sem chaves opcionais. Confirme o que funciona com fontes públicas ou sem chave. Observe voos, satélites, terremotos, CCTV, rádio, instalações mapeadas e camadas empacotadas.
Segundo, inspecione como a UI rotula dados faltantes ou simulados. Ative a camada de Missão Ambiental sem uma chave de FIRMS. Revise se o tráfego é em tempo real ou simulado. Veja como as visualizações de câmeras, reproduções de lançamentos e entidades rastreadas descrevem seu estado de fonte.
Terceiro, adicione a camada de voz com IA apenas depois que o mapa básico funcione. Use-a como função de desenvolvimento, não como truque de magia. Peça para navegar, anotar, selecionar entidades próximas, mudar modos e responder perguntas sobre objetos selecionados. Depois inspecione que contexto usou e onde se recusa ou nomeia dados faltantes.
É aí que o projeto se torna útil como padrão.
Não porque todos os times precisem de um globo OSINT, mas porque muitos times estão construindo interfaces sobre sinais fragmentados em tempo real: observabilidade, logística, segurança, frotas, IoT, operações internas, sistemas urbanos, infraestrutura ou dados de pesquisa.
God’s Eye View é um exemplo visível e hackeável de como pode parecer esse tipo de interface.
O aviso
Isso não é uma plataforma de inteligência de produção endurecida.
O README diz que o projeto é um cliente open source em evolução para exploração e aprendizado, não um serviço de produção endurecido. Os custos e termos dos provedores podem mudar. Algumas fontes de dados têm restrições não comerciais ou proprietárias. Algumas visualizações são modeladas, estimadas, atrasadas ou reconstruídas. Compartilhar em LAN pode expor acesso intermediado a chaves se habilitado sem cuidado.
Esses avisos não enfraquecem o projeto. O tornam mais credível.
Uma ferramenta de sinais públicos deveria ser explícita sobre o que sabe, o que estima, o que simula, quanto custa e para o que não deveria ser usada.
God’s Eye View faz isso com mais clareza que a maioria das demos geospaciais virais.
O padrão maior
O gancho é visual: um globo fotorealista repleto de aviões, navios, satélites, terremotos, câmeras e sinais em tempo real.
Mas a lição para desenvolvedores é arquitetônica.
God’s Eye View mostra o que acontece quando você combina feeds de dados públicos, um mecanismo 3D nativo do navegador, tratamento local-first de chaves, atribuição de fontes, ferramentas de voz em tempo real e rótulos explícitos de incerteza em uma única interface.
Essa combinação vai aparecer em mais lugares.
Não apenas em OSINT. Em devtools. Em dashboards de segurança. Em logística. Em sistemas de cidades inteligentes. Em monitoramento de infraestrutura. Em resposta a incidentes. Em qualquer contexto onde o difícil não seja ter dados, mas converter muitos sinais imperfeitos em algo que uma pessoa possa operar.
O mundo já está emitindo os sinais.
A pergunta para desenvolvedores é como convertemos isso em software de forma honesta, segura e útil.