A forecast for a route is not a forecast for a line
An offshore race has no connectivity after the start, so everything the boat will need for three days has to be on the tablet before the dock lines come off. What the platform fetches is neither a global model nor a point forecast. It is a corridor: the box around the plan’s route, widened by a margin, with the model run cut down to it.
The margin is the only number on the boat’s weather page — 5 to 200 nautical miles, and 30 to begin with. It exists because a boat does not sail the rhumb line: a beat takes you twenty miles off it, a headland gets a wide berth, and a forecast that stops at the drawn route runs out exactly where a navigator starts making decisions. It also drives the download roughly quadratically, so doubling it is nearer four times the bytes.
A plan with no route never gets weather at all: the area is derived from the route, so there is nothing to cut a forecast to. That is arithmetic rather than a rule. The job runs every ten minutes and keeps the five most recently updated routed plans of each boat current, so a plan saved now has its files about ten minutes later plus the build. There is no fetch now button, on purpose: at nine in the morning there is no 12z ECMWF, and a button cannot conjure a run nobody has published.
Up to four models are fetched per boat, and the page states each one’s own limits beside it rather than grading them — AIFS publishes no gusts and the platform will not manufacture one from the mean wind, because a gust is what a crew reefs on; AROME’s domain is 37.5 to 55.4° N; ICON’s high-resolution European nest stops at 29.5° N, with global ICON south of it.
What comes down the button at the dock
On the tablet, with a connection, SETTINGS → WEATHER AND DATA → WEATHER is one card about one plan — the loaded one, or the newest routed one, with any others counted and named rather than left out. Each row is the newest run of one model, with its size and whether it is already aboard, and the progress bar counts bytes across the whole run rather than files.
Three kinds of file come down it, not one:
- A weather bundle per model run — wind, gusts, pressure, and where the platform holds them, the surface current and the height of tide.
- The sea model — the depth grid, the coastline, the seamarks and the hazards along the corridor, which is what the depth check in the routing reads.
- An official chart extract, where a hydrographic office publishes one on terms that allow it.
A run is immutable — a new run is a new file, never a changed one — so a second press costs nothing for what is already held, and cancelling puts the rows in flight back to missing rather than leaving half a file behind. Then you leave, and the wind screens read off the tablet’s own storage with the antenna down.
Reading it with no connection
Wherever the tablet shows weather it shows three facts beside it, answering three different questions: which run it is and the hour that run was initialised at, when the file was fetched, and how far ahead it reaches. A 48-hour run is the wrong file to spend marina wifi on for a 60-hour race, and you should learn that from the list rather than from the forecast running out on the second night.
On NAVIGATION, WIND draws the corridor forecast as barbs under the marks and the laylines, with a transport for stepping the file’s own forecast hours and MODEL for picking which file is drawn. That picker is built from the bundles on the disk: a run that failed to fetch is an absent row rather than a row that breaks when you tap it. And a missing barb is missing data, never a calm — a real calm gets a circle, an absence bare water.
You can stop on the steps the file carries and not between them: a smooth continuum would let you land on an instant whose gust statistic covers no window at all. Gust windows differ between models and within one run, so the bundle carries the window per step.
The routed path, from where the boat is
PATH AHEAD routes the rest of the course from the boat’s own position, through the forecast the tablet holds, against the depth in the sea model and around the plan’s exclusion zones. It recomputes on four triggers — the plan changed, the forecast files changed, the boat moved a nautical mile, or the clock stepped ten minutes — and RECOMPUTE asks for it now.
The grey dots behind the path are the isochrones — how far the boat could have reached by each step of the calculation. Each leg card gives the board it is entered on, the heading to steer and the arrival clock in UTC, then how long on this board, how many boards, and the sail pair the boat’s crossover chart calls for. The wind reported per board is water-referenced: a forecast wind is referenced to the ground and a polar to the water, and feeding one into the other makes an error the size of the current. Every leg carries a depth line too, saying whether the depth was checked all the way and on what size of cell.
There is no model picker on this tab, and that is the design: the panel names the model that produced the answer and prints the same answer against the other models aboard, because the spread between them is the confidence display. An OTHER MODELS switch on the legend row hides the alternate paths on the chart, and the spread stays as text either way.
A file you brought yourself
A boat that already has a forecast from somewhere else can import it. IMPORT GRIB reads GRIB edition 2 in simple, complex and complex-with-spatial-differencing packing on a regular latitude and longitude grid, and it names what it found in those words rather than saying unsupported format: CCSDS packing, which is what ECMWF’s free open-data files use, and JPEG 2000 and PNG packing are declined by name. The 10 m wind is required and a file without it is refused rather than imported empty. The import runs on the tablet and nothing about it reaches the platform.
At sea, REFRESH WEATHER NOW is the same download built for a thin link: the smallest useful file first rather than the freshest, a stopped transfer resumed where the connection allows it, and the cost in megabytes printed above the button before you press it.
None of this is navigation. It is a forecast drawn over a course, and the ship’s plotter remains the navigator’s authority. The tablet’s chart is a repacked corridor extract rather than an official ENC, it does not meet chart carriage regulations, and it names which of the two tiers you are looking at.
Read the method
The documentation this post draws on.
- Weather — What the platform fetches for a boat’s routed plans and what it cannot tell you: the models and the limit each one carries, the corridor margin, taking the bundles at the dock, and reading the staleness line and the barbs at sea.
- Your own GRIB, and weather at sea — Importing a forecast file you already have and refreshing the weather once you have left: which GRIB formats the tablet reads and which it declines by name, getting a file across from mail, what the import summary says it left out, and a download built for a satellite link.
- Planning a coastal or offshore race — A race whose course is known days ahead: drawing the plan ashore with marks, rounding sides, exclusion zones and a safety margin, the corridor forecast built for it, routing the course in the browser and adopting the result — then LOAD RACE, NAVIGATION and PATH AHEAD on the tablet, the alarms, sailing through midnight, and the debrief.
- Navigation — The navigator’s own section: every race plan the fleet holds in one list, the weather already fetched for each routed plan and what makes a corridor stale, the viewer that draws a forecast on the chart and how to read a wind barb, routing a course in the browser with the tablet’s own engine and comparing the variants that change the answer, the marks the whole organisation reuses and why a plan copies one rather than pointing at it, the chart tools that measure a range and bearing and place a mark from one, the navigator’s log and routes pinned from the boat, the deck channels a boat transmits to its own instruments, and taking a plan away as GPX.