Alerta de Desastres Naturais NASA EONET
Entrar com GitHub
UTC 2026-09-03 22:41:10
Local

Documentação As fatias

Evento

O que a NASA publica, e o defeito de 456 km

3 min de leitura

Fatia evento

O que a NASA publica, e o que dispara o alerta. É a razão de o sistema existir.

A fonte

EONET v3eonet.gsfc.nasa.gov/api/v3/events. É aberta: não usa chave de API. Medido: a chamada responde 200 até sem cabeçalho nenhum. O User-Agent que enviamos é etiqueta, não autenticação.

O defeito de 456 km

A EONET devolve vários pontos de geometria por evento — a trajetória, com uma data por ponto. O projeto original usava getGeometry().get(0): o primeiro, que é onde o evento começou.

Medido na resposta real, em 02/09/2026, evento EONET_23800 (Tropical Storm Marie, seis pontos):

primeiro ponto   2026-09-01T06:00Z   lat  14.10  lon -108.10   ← o que o legado usava
último ponto     2026-09-02T12:00Z   lat  16.80  lon -111.30   ← onde ela está agora
distância ................................................  456 km

Num alerta de raio 100 km, isso avisa quem está longe e cala para quem está perto — e não aparece erro nenhum. Aqui a posição é sempre a do ponto de data mais recente.

A segunda armadilha: a ordem das coordenadas

GeoJSON é [longitude, latitude], ao contrário do que quase todo mundo escreve ao falar.

Ler na ordem intuitiva põe o evento do outro lado do planeta. E quando os dois números estão na faixa válida — como [-40, -20]não dá exceção nenhuma: só um pino no lugar errado do mapa.

Sincronizar é um upsert, e isso não é detalhe

Três desenhos possíveis, e dois quebram:

desenho consequência
inserir sempre uma cópia por sincronização; mapa e estatística incham sem erro
ON CONFLICT DO NOTHING congela a posição no primeiro dia; o alerta decide sobre onde a tempestade estava
ON CONFLICT DO UPDATE o certo

O primeiro era o defeito do original: a unicidade morava só no Java (findByEonetIdApi().orElse(new)), e duas sincronizações simultâneas liam "não existe" e inseriam as duas.

xmax = 0 distingue INSERIU de ATUALIZOU na mesma ida ao banco — sem isso, "trouxe 50" e "os mesmos 50 de sempre" produziriam a mesma linha de log.

Proximidade: duas etapas, e a segunda é a que decide

  1. Caixa delimitadora — retângulo em graus, que o banco resolve por índice.
  2. Geodésia — a distância real sobre a esfera.

Parar na primeira é o erro tentador, porque "já filtrou". Mas caixa é retângulo e raio é círculo: o canto fica a raio × √2 do centro — 41% mais longe.

Medido no teste, com raio de 100 km: o canto da caixa está a 140 km. Sem a geodésia, o alerta avisaria essa gente — e quem é avisado à toa é quem desliga a notificação antes do evento que importava.

Zero eventos é alerta, não sucesso

A EONET praticamente nunca devolve vazio para uma janela de dias. Zero quase sempre significa filtro errado ou contrato mudado, e por isso sai em WARN. Sucesso silencioso aqui é o que faz ninguém perceber que o sistema parou de receber dados.

Polígono não vira ponto

Alguns eventos têm geometria de área, não de ponto. Reduzir área a ponto exigiria escolher um centro que a NASA não declarou — e esse centro entraria no alerta como se tivesse sido medido. O evento entra sem coordenada, e a tela diz por quê.