Skip to content

Weather routing

Weather routing answers one question: given the boat, the forecast and where you want to go, which way and when should you steer to arrive soonest? For a ship the answer is a fuel or a safety trade-off; for a sailing yacht it is mostly a matter of time, because the boat’s speed depends so strongly on the angle to the wind. This page explains how routers find that answer, which method WeatherRouting uses, and where it can go wrong.

Three things decide a sailing boat’s speed over the ground at any moment:

  • The boat, described by its polar diagram: the speed through the water for every true wind speed and true wind angle.
  • The wind at that place and time, from a forecast that changes every hour and every few miles.
  • The current, which adds its own velocity to the boat’s.

Written as vectors, the boat’s velocity over the ground for a heading ψ\psi is

v⃗ground=Vpolar(TWA(ψ),TWS) e^ψ+c⃗\vec v_{\text{ground}} = V_{\text{polar}}\big(\text{TWA}(\psi), \text{TWS}\big)\,\hat e_\psi + \vec c

where e^ψ\hat e_\psi points along the heading, TWA is the angle between heading and true wind, and c⃗\vec c is the current. The router has to choose the heading at every moment so that the whole track arrives first — while the wind, the current and therefore the best heading keep changing on the way.

This is a version of a classic problem of mathematics, Zermelo’s navigation problem (1931): find the fastest path for a craft of given speed through a moving medium. Sailing adds a speed that depends on direction, tacks and gybes that cost time, land, and rules about where you may go.

Reviews of ship weather routing name the same main families again and again: the isochrone method, dynamic programming and graph search, and calculus of variations / optimal control, with combinations and heuristics (such as evolutionary algorithms) built on them (Zis, Psaraftis & Ding 2020; Walther et al. 2016). The second review sums it up well: which approach suits depends heavily on the objective, the controls, the constraints and the implementation.

An isochrone is a line of equal time: all the places the boat could have reached after, say, six hours. The method builds them one after another:

  1. From the start, sail for one time step in every heading of a fan (for example every 5°). The end points form the first isochrone.
  2. From every point of that isochrone, do the same again. Of the many new points, keep only the outermost ones — the points that got furthest — and drop the rest. That is the next isochrone.
  3. Repeat until an isochrone reaches the destination. Following each point back to the point it came from gives the route.

The method goes back to manual plotting by the US Navy Hydrographic Office in the 1950s (R. W. James, 1957) (to verify: whether James’s report itself introduces isochrones, or later authors attribute them to it). Hideki Hagiwara’s modified isochrone method (TU Delft thesis, 1989; with Spaans, Journal of Navigation 1987) made it suitable for computers by dividing the space around the start into sectors and keeping one point — the furthest — per sector. Later work adapted it to keep routes off land (Szłapczyńska & Śmierzchalski 2007).

For a sailing yacht: the isochrone method is the classic choice of yacht routing software. It handles any polar, any wind field and current naturally, because it simply sails the boat forward in time. Its weak spot is the pruning: “furthest from the start” is a good measure in open water, but near land it throws away points that are worth keeping — a point in a bay or behind a headland is never the furthest, yet it may be the only way in.

Here the sea is first divided into a grid of points (or a network of possible tracks), and the route is the cheapest path through it. Classic algorithms — Dijkstra’s shortest path, A*, or dynamic programming stage by stage — find that path exactly, for the grid they are given. Adding time as a third dimension (“3D dynamic programming”) lets the cost of each step depend on the forecast at the moment the boat gets there.

For a sailing yacht: land and forbidden areas are easy — they are simply missing from the grid. But the grid decides which headings exist: with eight or sixteen neighbours per point, the boat can only sail in those directions, and a close-hauled course between them has to be built from zig-zags. A fine grid fixes that at a high cost in memory and time. Tacking costs depend on the previous heading, so the “state” of a point has to include the tack, which multiplies the grid again.

Calculus of variations and optimal control

Section titled “Calculus of variations and optimal control”

The third family treats the route as a smooth curve and the heading as a control that varies continuously. The conditions for the fastest curve follow from the calculus of variations (Zermelo’s own approach) or from optimal control theory; a starting route is then improved step by step until it can no longer be made faster. S. J. Bijlsma’s Delft thesis On minimal-time ship routing (1975) is a well-known early application to ships (to verify: the thesis’s method, from its text).

For a sailing yacht: these methods are elegant and precise when the boat’s speed changes smoothly with heading. A polar diagram does not: the boat cannot point higher than its best close-hauled angle, and tacking is a jump, not a smooth turn. The method also improves a route locally — it does not by itself find out whether going north or south of an island is faster. It is therefore rarely used alone for yachts.

IsochroneGrid / graph searchCalculus of variations
Headingsany, in a fanonly those of the gridcontinuous
Changing wind and currentnaturalwith time as a dimensionnatural
Tacks and gybeseasy to countneeds extra stateawkward
Land and zoneschecked per step; pruning can lose bayssimply left out of the gridconstraints, hard
Finds the global bestclose, depends on pruningexactly, for the gridlocally only

WeatherRouting uses the isochrone method: it sails the boat forward in time in a fan of headings, step by step. What it keeps from each step — the pruning — borrows the grid idea from graph search, so that bays, harbours and channels are not lost.

From every point of the current front, for every heading in a fan of 5° (72 headings), the router works out:

  1. The wind at that point and moment. The forecast is interpolated bilinearly in space and linearly in time, on the wind’s east and north components.
  2. The boat’s speed from the polar diagram (bilinear interpolation between the table’s angles and wind speeds), times the boat’s efficiency factor.
  3. Sail or motor. If the sailing speed is below the boat’s minimum sailing speed, the boat motors at its motoring speed instead — unless the calculation is set to sail only.
  4. Penalties. A change of tack while sailing upwind (both angles under 90°) costs the boat’s tack penalty, a change while running downwind (both over 90°) its gybe penalty, and a switch between sailing and motoring its mode-switch penalty. The penalty is time lost from the step. The router remembers the last sailing wind angle across motoring steps, so it cannot dodge a tack penalty by motoring one step through the wind.
  5. The current at the point, added to the boat’s velocity through the water.
  6. The new position after one time step, along the course over ground.

The time step is 30 minutes by default and can be changed per calculation. Within two normal steps’ sailing of a leg’s start or end, the router takes 5-minute steps, because a harbour entrance needs turns shorter than half an hour of sailing.

Each new point is then checked: the step may not cross land, may not come closer to the coast than the coast distance, may not stray too far from the line between the waypoints (the corridor: half the leg’s length either side, at least 2 nm), and must obey the zone rules (see below). Points that fail are dropped.

Of all the new points, the router keeps only some — otherwise their number would grow without limit. WeatherRouting offers two ways:

  • Sectors, as in the modified isochrone method: per 1° sector seen from the leg’s start, keep the point furthest from the start. Near land (within 1 nm of the coastline), it also keeps the first point to reach each square of 0.1 nm, so that a bay or a channel that bends back is not lost.
  • Squares (the default): no sectors at all. The sea is divided into squares, and per square only the first point to reach it is kept — if several reach it in the same step, the one closest to the waypoint. A point is only compared with points in the same state: wind on port, on starboard or not yet sailed, and sailing or motoring, because those change what the next step costs. The squares are 0.25 nm within 2 nm of land or a waypoint, and grow with distance, doubling every further 2 nm up to 1 nm in open water.

The squares are the grid idea from graph search, used inside the isochrone method: the headings stay free, and the first boat to reach a place is, by definition, the fastest one to get there. The squares became the default because the sector method often gave routes that changed direction very often, which did not inspire confidence. They are slower to calculate.

Before each step, the router checks whether any point of the front can sail straight to the waypoint within the step, without crossing land, the coast distance or a zone rule. The earliest such arrival ends the leg. A route with several waypoints is routed leg by leg: the earliest arrival at one waypoint is the start of the next leg.

The route you see is the chain from the arrival back to the start, each point remembering the point it came from. The isochrones drawn on the map are the fronts at every whole hour.

The router gives up, and tells you why, when:

  • the wind data ends, or the route leaves the area the forecast covers — then it shows the route up to the furthest point reached;
  • every direction is blocked — by land, the coast distance, the corridor, a no-go zone or a traffic separation rule;
  • it makes no progress towards the waypoint for 24 hours;
  • the route takes longer than the maximum duration (240 hours by default).

No step may cross the coastline. A waypoint on land is refused, and a route without land data for its area gets a warning that it may cross land.

On top of that, the router keeps a coast distance: by default 0.5 nm from the coastline, adjustable from 0 to 5 nm. Close to a waypoint this would make harbours unreachable, so the required distance shrinks linearly to zero within 3 nm of any waypoint (adjustable from 0 to 20 nm). The required distance dd at a point that lies rr from the nearest waypoint is

d=dcoast⋅min⁡ ⁣(1,  rrrelax)d = d_{\text{coast}} \cdot \min\!\left(1,\; \frac{r}{r_{\text{relax}}}\right)

A channel narrower than twice the coast distance is closed by it — except within the relaxation distance of a waypoint.

The router follows Rule 10 of the COLREGs as it applies to a small yacht:

  • Crossing a scheme: a traffic lane or separation zone may be crossed only on a heading close to a right angle to the direction of traffic — within a tolerance of 15° by default (adjustable from 5° to 30°). The rule speaks of the heading, not the track, so a boat set sideways by the current still crosses correctly.
  • Following a lane: by default lanes may only be crossed. Per area you can allow following a lane in its direction of traffic, within the same tolerance. A step that started crossing a lane must go on crossing it, and one following it must go on following it.
  • Separation zones and lines may only be crossed, never followed.
  • Roundabouts (a circular scheme around a light vessel or a buoy) may be transited by default, always keeping the centre to port — going round anticlockwise. The central zone keeps its own rule.
  • Junctions, where lanes of a scheme meet, refuse headings within 45° of directly against a lane ending there.

The direction of traffic comes from the chart data of the scheme, taken locally: near a bend in a lane, the nearest part of the lane counts. Each crossing is reported in the result with its worst angle.

Other areas from the chart get a rule — no-go, warn or allowed — with defaults per kind that you can change in Settings:

KindDefault
Wind farmno-go
Restricted area, entry prohibitedno-go
Restricted area, otherwarn
Nature reserve / protected areawarn
Precautionary areawarn
Inshore traffic zonewarn
TSS crossing areawarn

A no-go zone is never entered; a waypoint inside one is refused. A warn zone may be sailed through, and the result lists every warn zone the route touches. Your own zones, drawn in the app, follow the same rules.

A tidal gate — a sill, a bar, a lock — is a waypoint the router does not treat differently while routing. After the route is calculated, the app checks when the boat reaches each gate against the gate’s passable windows: the times the predicted water is above the minimum you need. To find a departure that fits, a departure sweep calculates the same route for up to 48 departure times and shows which ones arrive inside a window.

Auto-routing up a narrow, winding passage may fail with “every direction is blocked” or “no progress for 24 hours”, even though the passage is plainly navigable. The usual causes:

  • The steps are too long for the passage. In 30 minutes a boat sails 3 nm at 6 knots. If the passage bends within that distance, every step from the front ends on land and is dropped. The router only takes short steps near the start and end of a leg.
  • The coast distance closes it. A channel narrower than twice the coast distance is closed, except near a waypoint.
  • The passage bends back. A river that turns away from the destination leads the boat away from the waypoint for a while; with the sector method such points are never “furthest” and can be lost.

What helps:

  • Put a waypoint at the entrance of the inlet or channel, and one at each sharp bend or narrow part. Near a waypoint the router steps every 5 minutes and the coast distance relaxes, so each short leg is easy.
  • Put the last waypoint in open water of the harbour or the river, not against a quay or a lock, so the final approach is not on top of the coastline.
  • Lower the coast distance for that calculation, or the time step.
  • Keep the squares method (the default); it does not lose the points that go back on themselves.
  • Don’t put a waypoint inside a scheme. The router warns about it, and it forces the route through a lane where it may have to cross at a poor angle. Put waypoints on either side of the scheme instead, and let the router find the crossing.
  • If a scheme blocks every direction — for example a crossing that would have to run along the lane — check the scheme’s settings for that area, or add a waypoint that sets up a right-angle crossing.

Because the router takes the earliest arrival at each waypoint as the start of the next leg, a route with many waypoints is the fastest route leg by leg, not necessarily the fastest overall: arriving a few minutes later on the other tack might have given a better next leg. Use waypoints where you need them — to pass a gate, to steer clear of something, to help in narrow waters — and let the router choose freely in between.

A route is only as good as the forecast and the polar diagram. The polar is the boat’s speed in flat water with clean sails; the efficiency factor lets you scale it down for a cruising load, a short-handed crew or a sea state the polar does not know about. Comparing routes on different forecast models — WeatherRouting can compare up to eight calculations — shows how much the answer depends on the forecast.

Free software under AGPL-3.0-or-later · Source code · Credits

Generated using E.U. Copernicus Marine Service Information; https://doi.org/10.48670/moi-00054