Dati e feature
GFS atmosferico 12Z e GEFS-Wave operational c00 sullo stesso issue, orizzonti D+1…D+5; vento, pressione, precipitazione e variabili marine/onda; evidenze outcome da NYC Ferry GTFS-Realtime, con 511NY opzionale come corroborazione
Sintesi non tecnica
- Che cosa risolve
- Un traghetto può avere un orario regolare, ma vento e mare possono rendere un approdo difficile o temporaneamente non utilizzabile. Il workflow prova a riconoscere con anticipo queste finestre critiche per Rockaway e Bay Ridge.
- A chi può servire
- Chi studia forecasting operativo, resilienza dei trasporti marittimi, disponibilità di pontili e verifica prospettica dei modelli.
- Che cosa produce
- Per i prossimi cinque giorni mostra uno stato di attenzione per ciascun approdo, poi confronta le previsioni con ciò che NYC Ferry ha effettivamente riportato e misura anticipo, eventi intercettati e falsi allarmi.
1 · Obiettivo del progetto
Dalla previsione meteo alla domanda operativa: “questo approdo potrebbe diventare critico?”
Una previsione di vento o altezza d’onda, da sola, non dice se un terminale ferry sarà utilizzabile. WF21 prova a costruire il passaggio mancante: collega le condizioni previste al rischio di inagibilità/indisponibilità dell’approdo, mantenendo distinti il segnale meteorologico, la stima del modello e l’esito reale del servizio.
Il sistema lavora in research shadow: osserva, prevede, conserva la previsione e la verifica dopo. Non invia comandi di chiusura o apertura e non sostituisce le comunicazioni ufficiali di NYC Ferry.
2 · I due approdi osservati
Rockaway e Bay Ridge non sono trattati come due punti identici.
RockawayÈ il banco di prova principale del percorso scientifico: un modello champion “marine core” viene confrontato in shadow con challenger e controllo, senza promozione automatica.
Bay RidgeMantiene una policy congelata v0.9.8. Qualunque evoluzione resta subordinata a burn-in, backup, evidenza prospettica e approvazione umana.
OrizzonteCinque date target, D+1…D+5, calcolate dallo stesso issue completo di GFS 12Z e GEFS-Wave operational c00.
3 · Dati e decision state
Fonti atmosferiche e marine devono riferirsi allo stesso ciclo.
Il runtime combina variabili atmosferiche — tra cui vento, pressione, precipitazione e temperatura — con variabili marine e d’onda. Se le fonti non sono complete o coerenti, il sistema deve fermarsi o degradare lo stato: un dato mancante non può diventare implicitamente un “via libera”.
4 · La parte più importante: verificare dopo
La previsione non viene giudicata con la previsione successiva, ma con ciò che è successo davvero.
WF21 archivia evidenze da NYC Ferry GTFS-Realtime come fonte primaria e può usare 511NY come corroborazione. La verifica distingue AVAILABLE, UNAVAILABLE e UNKNOWN: l’assenza di un alert non basta per dichiarare l’approdo disponibile, e UNKNOWN resta fuori dai denominatori delle metriche.
Le metriche prospettiche includono eventi intercettati, lead time, copertura degli orizzonti e burden degli alert sui giorni verificati disponibili. Le verifiche D+1 e D+7 impediscono di “aggiustare” retroattivamente la verità osservata.
5 · Governance pubblica
Informare senza trasformare una ricerca in una falsa certificazione operativa.
Le card pubbliche possono mostrare matrice degli stati, lead time verificato, scoreboard prospettico e completezza delle fonti. Non pubblicano probabilità grezze o calibrate né soglie interne. Se manca lo stato di un orizzonte, la pubblicazione viene soppressa invece di rappresentarlo come LOW.
6 · Cosa significa per NYC Ferry
Un osservatorio sperimentale sulla resilienza degli approdi, non un duplicato dell’orario del ferry.
Il valore del workflow è provare a rispondere prima che l’evento sia noto: le condizioni previste stanno entrando in una zona che storicamente e fisicamente merita attenzione per l’operabilità dell’approdo? Poi il sistema controlla se il servizio ufficiale ha effettivamente mostrato un’indisponibilità coerente con il target osservato.
Questo rende WF21 un ponte tra meteorologia, oceanografia operativa, machine learning, affidabilità delle fonti e verifica del servizio reale. La stessa architettura può essere studiata per altri pontili o terminali, ma ogni trasferimento richiede dati, soglie, outcome e validazione specifici del sito.
Dossier tecnico del workflow
Metodi, verifiche, stack e limiti.
Inferenza
runtime scientifico congelato; Rockaway usa champion marine-core con challenger e controllo in shadow, Bay Ridge mantiene la policy v0.9.8; l’output pubblico espone stati LOW/WATCH/HIGH, non probabilità o soglie
Validazione
previsioni immutabili verificate a D+1 e D+7; metriche prospettiche su episode recall, lead time, alert burden su giorni verificati disponibili, horizon coverage e calibrazione riservata; UNKNOWN escluso dai denominatori
Stack
Python, pandas/NumPy, scikit-learn, GFS, GEFS-Wave, NYC Ferry GTFS/GTFS-Realtime, 511NY opzionale, GitHub Actions, Pillow/Matplotlib, AT Protocol/Bluesky
Failure mode
fonti incomplete o non allineate, eventi non meteorologici, cambi di servizio o di infrastruttura, distribution shift e scarsità di episodi; il sistema deve degradare a UNKNOWN/HOLD invece di dedurre un falso all-clear
Automazione
Run giornaliero con retry, watcher di indisponibilità ogni 30 minuti, review settimanale, manutenzione mensile e pubblicazione WF21 separata dal run tecnico. Registri e report sono idempotenti e le previsioni committate non vengono sovrascritte.
Pubblicazioni
Dal run tecnico alla card pubblica.
Il canale Bluesky usa il tag #LIwf21 e pubblica italiano e inglese come post root indipendenti. La scheda del sito conserva metodo, confini e contesto anche quando il post social è sintetico.
Apri pubblicazioniPossibile trasferibilità
Hai un problema che assomiglia a Port Operability · NYC Ferry?
Il primo confronto può partire da obiettivo, dati disponibili e criterio di successo, senza inviare informazioni riservate. Un risultato osservato qui non viene assunto automaticamente valido in un altro contesto.