Data and features
GFS 12Z atmosphere and GEFS-Wave operational c00 from the same issue, horizons D+1…D+5; wind, pressure, precipitation and marine/wave variables; observed outcomes from NYC Ferry GTFS-Realtime, with optional 511NY corroboration
Plain-language summary
- What it solves
- A ferry may have a regular timetable while wind and sea conditions make a landing difficult or temporarily unusable. The workflow tries to identify these critical windows early for Rockaway and Bay Ridge.
- Who it can serve
- People studying operational forecasting, maritime-transport resilience, landing availability and prospective model verification.
- What it produces
- For the next five days it shows an attention state for each landing, then compares forecasts with what NYC Ferry actually reported and measures warning lead, caught events and false-alert burden.
1 · Project objective
From a marine forecast to an operational question: “could this landing become critical?”
A wind or wave-height forecast alone does not say whether a ferry terminal will remain usable. WF21 explores the missing link: it connects forecast conditions with the risk of landing unavailability, while keeping the weather signal, model estimate and real service outcome separate.
The system operates in research shadow: it observes, forecasts, preserves the forecast and verifies it afterwards. It sends no open/close command and does not replace official NYC Ferry communications.
2 · The two observed landings
Rockaway and Bay Ridge are not treated as interchangeable points.
RockawayThe main scientific test bed: a marine-core champion is compared in shadow with a challenger and a control, with no automatic promotion.
Bay RidgeRetains the frozen v0.9.8 policy. Any future change remains subject to burn-in, backup, prospective evidence and explicit human approval.
HorizonFive target dates, D+1…D+5, produced from the same complete GFS 12Z + GEFS-Wave operational c00 issue.
3 · Data and decision state
Atmospheric and marine sources must belong to the same forecast cycle.
The runtime combines atmospheric variables — including wind, pressure, precipitation and temperature — with marine and wave variables. If sources are incomplete or inconsistent, the system must stop or degrade its state: missing data cannot silently become an all-clear.
4 · The most important part: verify afterwards
The forecast is not judged against the next forecast, but against what actually happened.
WF21 archives NYC Ferry GTFS-Realtime evidence as its primary source and can use 511NY as corroboration. Verification distinguishes AVAILABLE, UNAVAILABLE and UNKNOWN: the absence of an alert is not enough to call a landing available, and UNKNOWN stays out of metric denominators.
Prospective metrics include caught episodes, warning lead, horizon coverage and alert burden on verified available days. D+1 and D+7 passes prevent the observed truth from being silently rewritten after the fact.
5 · Public governance
Communicate evidence without turning research into a false operational certification.
Public cards may show the state matrix, verified lead time, prospective scoreboard and source completeness. They do not publish raw/calibrated probabilities or internal thresholds. If any horizon state is missing, publication is suppressed instead of rendering it as LOW.
6 · What this means for NYC Ferry
An experimental landing-resilience observatory, not a duplicate of the ferry timetable.
The workflow tries to answer before an event is known: are forecast conditions entering a region that deserves attention for landing operability? It then checks whether the official service evidence actually showed an unavailability consistent with the observed target.
This makes WF21 a bridge across meteorology, operational oceanography, machine learning, source reliability and real-service verification. The architecture can be studied for other piers or terminals, but every transfer needs site-specific data, outcome definitions and validation.
Workflow technical dossier
Methods, checks, stack and limitations.
Inference
frozen scientific runtime; Rockaway uses a marine-core champion with challenger and control in shadow, while Bay Ridge retains the frozen v0.9.8 policy; public output exposes LOW/WATCH/HIGH states rather than probabilities or thresholds
Validation
immutable forecasts verified at D+1 and D+7; prospective metrics include episode recall, lead time, alert burden on verified available days, horizon coverage and restricted calibration; UNKNOWN stays outside denominators
Stack
Python, pandas/NumPy, scikit-learn, GFS, GEFS-Wave, NYC Ferry GTFS/GTFS-Realtime, optional 511NY, GitHub Actions, Pillow/Matplotlib, AT Protocol/Bluesky
Failure mode
incomplete or misaligned sources, non-weather service disruptions, service/infrastructure changes, distribution shift and sparse events; the system must degrade to UNKNOWN/HOLD rather than infer a false all-clear
Automation
Daily run with retry, 30-minute unavailability watcher, weekly review, monthly maintenance and a WF21 publication workflow separated from the technical run. Ledgers and reports are idempotent and committed forecasts are never overwritten.
Publications
From the technical run to a public card.
The Bluesky channel uses #LIwf21 and publishes Italian and English as independent root posts. The site page preserves method, boundaries and context when the social post has to stay concise.
Open publicationsPotential transferability
Have a problem similar to Port Operability · NYC Ferry?
A first discussion can start from the objective, available data and success criterion without sending confidential information. A result observed here is not assumed to transfer automatically to another context.