Satellite — Etna event-based

1 · In una frase

Evento GVP, fonti INGV, sismicità, FIRMS e venti vengono combinati in uno scenario educativo di trasporto potenziale della cenere.

2 · Perché esiste

Passare da un evento pubblico a un quadro geospaziale tracciabile senza trasformarlo in un avviso ufficiale.

3 · Cosa produce

Card verticale con traiettorie a circa 700 e 500 hPa, corridoi, regime, dati termici e sismici, safety gate.

Come leggere l’ultimo output: Le linee seguono il vento previsto a due livelli; le bande sono corridoi indicativi. Non rappresentano concentrazione, deposizione o pericolosità.

Le linee seguono il vento previsto a due livelli; le bande sono corridoi indicativi. Non rappresentano concentrazione, deposizione o pericolosità.

4 · Come funziona

Dalle fonti all’output.

Diagramma della pipeline del workflow — Diagramma della pipeline: dalle fonti pubbliche attraverso controlli e calcolo fino alle card pubblicate, con supervisione umana.

1Nuovo evento

2Gate INGV

3Multi-dati

4Venti 2 livelli

5Traiettorie

6Pubblicazione

5 · Dati utilizzati

Dati utilizzati
Fonte	Variabile	Frequenza	Limite
Smithsonian GVP	Evento Etna pubblico e datato	Ogni controllo	Ritardo e granularità del feed
INGV/OE	Comunicati e controllo ufficiale	Ogni evento	Parsing prudenziale; incertezza blocca
NASA FIRMS VIIRS	Anomalie termiche 24 h	Ogni evento	Proxy termico, non prova di cenere
Catalogo sismico	Eventi e magnitudo 24 h	Ogni evento	Copertura e soglie
Open-Meteo	Venti orari a 700 e 500 hPa	Ogni evento	Campo interpolato; non modello di cenere

6 · Modelli e regole

Modelli e regole

Advezione lagrangiana oraria: velocità e direzione del vento vengono convertite in spostamenti geografici. Due livelli descrivono differenze verticali; velocità media, variabilità e shear alimentano un classificatore MLP del regime. DBSCAN raggruppa anomalie FIRMS; Isolation Forest può evidenziare configurazioni insolite.

7 · Controlli

Controlli

Safety gate ufficiale fail-closed, freschezza, provenienza, controllo immagini vecchie, hash esatto e percettivo, stato anti-duplicazione e due post bilingui indipendenti.

8 · Risultati e metriche

Risultati e metriche

Esiti dei run (pubblicato, saltato, bloccato), disponibilità delle fonti e duplicati evitati. Non viene dichiarata skill di dispersione operativa.

9 · Limiti

Limiti

Nessun termine sorgente, altezza reale della colonna, granulometria, turbolenza, sedimentazione, deposizione, concentrazione, visibilità o hazard aeronautico.

Possibili applicazioni del pattern

Evento e fusione geospaziale

Possibili applicazioni: workflow event-driven per fenomeni ambientali, infrastrutture distribuite o monitoraggio territoriale. Osservazioni, simulazioni e comunicazioni ufficiali devono restare separate.

Componenti trasferibili

trigger GVP e safety gate INGV
sismi, FIRMS e venti
advezione a 700/500 hPa
stato anti-duplicazione bilingue

Domande di ricerca

propagazione dell’incertezza
confronto con modelli di dispersione
qualità del trigger evento
validazione dei regimi

Mappa delle applicazioni Dettagli tecnici comuni

Dossier tecnico del workflow

IMPLEMENTATODescrive il comportamento presente nel workflow.ESTENSIONEIndica una ipotesi di analisi o componente non inclusa, non una funzione già operativa.

Dettagli implementativi e criteri di valutazione.

Questa sezione collega l’output visibile alle scelte di data engineering, modellazione, validazione e delivery presenti nel repository.

Architettura e dati

Trigger su nuovo evento Etna datato nel feed GVP, seguito da gate ufficiale INGV/OE fail-closed.
Fusione di sismicità, hotspot FIRMS e venti Open-Meteo; oggetti tipizzati con Pydantic.
State JSON con evento, fingerprint, hash immagine e URI delle due pubblicazioni standalone.

Feature e metodi

Integrazione oraria della traiettoria con advezione lagrangiana su livelli circa 700 e 500 hPa.
Corridoi indicativi derivati dal percorso centrale; shear e geometria alimentano la classificazione del regime.
DBSCAN per cluster FIRMS, Isolation Forest per configurazioni anomale e MLPClassifier/PyTorch opzionale.

Validazione e failure mode

Controlli su età evento, fonte ufficiale, dati correnti, timestamp e assenza di riuso di immagini precedenti.
Test di safety, caption, eventi, sismicità, guard, release contract e publisher bilingue.
Il metodo non modella concentrazione, sedimentazione, granulometria o hazard aeronautico.

Runtime e delivery

Package Python installabile con CLI Hatch, pytest e Ruff; dipendenze bloccate in uv.lock.
Beautiful Soup/pypdf, requests, pandas, scikit-learn, matplotlib/Pillow e GitHub Actions.

Confronta tutti i workflow Ricerca e sviluppi

10 · Cronologia operativa

Cronologia operativa

Stato: Attivo · event-driven
Frequenza: Controllo ogni 6 ore; pubblicazione solo su nuovo evento valido
Aggiornamento pagina: luglio 2026

11 · Approfondimento tecnico

Metodo e assunzioni

Failure mode principali