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 v3 — eonet.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
- Caixa delimitadora — retângulo em graus, que o banco resolve por índice.
- 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ê.