Ashore and on board

Navigation

Draw the course ashore with the forecast and the depth on the chart, route it with the engine the tablet runs at sea, and load it on the boat with no signal.

Who it is for

The navigator, and the tactician on a windward-leeward day. For a coastal or offshore race the job is to plan it in a browser — the course, the forecast, the depth and the routed path — and then sail it on the boat with no signal, on a tablet holding the same plan and running the same routing engine. For a windward-leeward race the marks live in the same library, and the tablet sets the course on the water, pings both ends of the line and runs the start, with laylines and targets from the boat’s own instruments.

Race plans

A plan is a document: waypoints in order, which side to leave each one, a passing radius, the water the routing must not enter, and the depth you want under the keel. The committee’s GPX imports into a plan, and a plan exports as GPX for a plotter. Every boat’s plans are listed together on the Navigation page.

Two rows of the Navigation plan list, under a boat heading and the column headings NAME and WHAT IT HOLDS. "Race to Mackinac" holds the chips Offshore, 4 wpt, 2 zones and 3 m margin; "Sørlandet coastal" holds Coastal, 5 wpt, 1 zone and 3 m margin
Two plans on one boat, in the list that gathers every boat’s plans on the Navigation page. The chips beside each name are what the plan holds: its type, its waypoint count, its exclusion zones and the depth margin under the keel.

Zones are drawn on the chart, typed as corners, or pasted as a published list of positions — sailing instructions publish an exclusion zone as coordinates, and tracing those off a basemap by eye is a transcription with an error in it. In the browser the course can be drawn over an official raster chart as well as over the platform’s own; that layer is off until you switch it on, and what it covers is set out under Charts below.

The plan editor’s map, drawn over the official raster chart of a stretch of the Norwegian south coast around Kristiansand, Mandal and Lindesnes. Three tool pills stand across the top of the map — Measure, Dividers and Range and bearing — with the zoom controls at the top right and a 5 nm scale bar at the foot. The plan’s route runs in blue between three numbered waypoints, each a blue disc inside an orange passing-radius circle: 1. Kristiansand start at the east end, 2. Ryvingen S (out) in the middle and 3. Lindesnes S at the west end. A red rectangle south-east of Ryvingen S is the plan’s exclusion zone. The chart’s own soundings, depth contours, light characteristics and traffic symbols are drawn under all of it, and the chart’s attribution line runs along the bottom edge of the map
The plan editor on the coastal plan from the list above, with the official raster chart under the course: the route through 1. Kristiansand start, 2. Ryvingen S (out) and 3. Lindesnes S, each waypoint’s passing radius drawn as a circle around it, and the plan’s one exclusion zone as the red rectangle south-east of Ryvingen S. The three chart tools sit along the top of the map and stay inert until one is switched on. Chart © Kartverket, CC BY 4.0.

The weather fetched for the plan

For every plan with a route, the platform fetches your forecast models on each model’s own run schedule, clipped to a corridor around the route, carrying the tidal stream and the height of tide. The models are ECMWF IFS, ECMWF AIFS, GFS, ICON and AROME, up to four at a time, with each model’s own limits stated beside it on the page that chooses them — AIFS publishes no gusts, AROME’s domain is 37.5–55.4° N, and ICON’s high-resolution European nest stops at 29.5° N with global ICON serving south of it. The boat’s weather page chooses what is fetched; the Weather tab under Navigation lists what has been built.

Two ages are always printed, never one: how old the forecast RUN is, and how old the FILE is. A three-hour-old ECMWF run is the freshest run that exists, so age alone is never called stale — what is flagged is a corridor that no longer covers your route, or a forecast whose horizon has passed.

At sea you can also bring your own file. The tablet imports a GRIB2 forecast you downloaded yourself, names the packings it reads and the ones it declines by name rather than saying “unsupported”, and its refresh is built for a satellite link rather than a pontoon.

The weather viewer

A corridor opens on the plan’s own map: wind speed drawn over the course as a coloured wash with barbs on it for the direction, gust and pressure contours where the file carries them, a scrubber over the file’s own steps, and a meteogram at any point you click. The wash is one block per sample and is not smoothed between them, so it is never drawn finer than the file it came from.

The weather viewer’s map on a coastal plan. Wind speed is drawn over the water as a coloured wash in flat blocks, one block per sample and not smoothed between them, running green through yellow to orange across the corridor, with white wind barbs standing on a spaced grid over it. The plan is drawn on top: the route in blue through 1. Kristiansand start, 2. Ryvingen S (out) and 3. Lindesnes S, and a red rectangle labelled Zone A south-east of Ryvingen S. Measure, Dividers and Range and bearing stand along the top of the map, the zoom controls at the top right and a 3 nm scale bar at the foot. Under the map the line "Press a tool to use it on the map." and then the step row: a back arrow, Play, a forward arrow, a slider set near its left end, and the reading 2026-09-16 18:00Z · +30 h Step 31 of 137. A colour scale under that runs 14.2, 15.0, 20.0, 25.0 and 26.6 knots
One forecast step over the course: wind speed as the coloured wash, wind direction as the barbs standing on it, and the plan’s route and exclusion zone drawn on top. The scale under the map states the lowest and highest speed on screen — 14.2 and 26.6 knots — with fixed steps between. The row under the map steps the file: 2026-09-16 18:00Z, thirty hours out, step 31 of 137. Chart data © OpenStreetMap contributors · EMODnet · GEBCO.

Click any point and the meteogram for that position opens under the map: wind and gusts, sea-level pressure on its own axis, the direction at each step, and the depth at that point with the survey resolution and the vertical uncertainty beside it. A barb that is missing is missing data and never a calm — the viewer draws nothing where the file answered nothing, and a calm draws its own circle. The meteogram breaks its line across a step the file did not answer rather than dropping to zero.

The meteogram the weather viewer opens at a clicked point, headed AT 57.956, 7.209 with a Close button at the right. Wind speed and gusts are drawn as two lines against a knots axis on the left marked 0, 20 and 40, gusts above wind throughout, and sea-level pressure as a dashed line against a hectopascal axis on the right. A vertical line marks the step the map is showing, and a readout on the chart gives 2026-09-17 08:00Z · 11.7 kt. Under the traces a row of arrows carries the wind direction at each step, and the time axis runs from 2026-09-15 12:00Z to 2026-09-21 06:00Z. Below the chart, the sounding at the same point in five labelled rows: Depth 24.0 m, Source emodnet, Resolution 115 m, Vertical uncertainty 1.0 m and Datum LAT
The meteogram at one clicked position, 57.956 N 7.209 E, across the whole of the same file — 2026-09-15 12:00Z to 2026-09-21 06:00Z: gusts above wind against the knots axis, sea-level pressure dashed against the hectopascal axis on the right, and the wind direction as a row of arrows under them. The vertical line is the step the map is showing. Under the chart is the sea model’s reading at that point — 24.0 m on a 115 m grid, 1.0 m of vertical uncertainty, to the lowest astronomical tide.

Routing in the browser

The browser and the tablet run the same program, so a route computed here and the same route computed on the boat return the same numbers. That is not a claim about care taken: the routing engine is one Kotlin library, compiled to WebAssembly for the browser and shipped as itself on the tablet, and the same request returns the same double to the last bit.

Route the course, and you get the baseline path and the isochrone fans it expanded, drawn on the plan’s own map with a turning point at every tack and a marked point wherever the sail pair changes. The chart tools work on this map like any other, so a range and a bearing off the routed path are two clicks.

The Routing tab’s map after a run on a coastal plan. The routed path is drawn in violet from 1. Kristiansand start west past 2. Ryvingen S (out) to 3. Lindesnes S and back again, tacking in a zigzag of boards with a white dot at each turning point and one violet dot ringed in white, labelled M1 + A2, where the sail pair changes. The plan’s own legs run under it as straight cyan lines between the same three waypoints, a red rectangle labelled Zone A stands south-east of Ryvingen S, and thin grey isochrone lines fan across the water behind the path. Measure is lit in the pill row at the top left, beside Dividers and Range and bearing, with the line "Select a mark or a waypoint to measure the cursor against it." under it; a white dashed measure line runs between Kristiansand start and Lindesnes S. The zoom controls sit at the top right and a 3 nm scale bar at the foot. Under the map: "Click two points. The line reports range in nautical miles, bearing in degrees true and the reciprocal. Escape or the Measure button clears it.", and then the reading 33.7 nm · 261°T · back 081°T
One routing run on the plan’s own map: the routed path in violet with a white dot at each turning point and a marked point where the sail pair changes, the plan’s own legs in cyan under it, the isochrone fans the run expanded behind them, and the exclusion zone it had to stay out of. The Measure tool is switched on, and the dashed line it drew between two waypoints reads 33.7 nautical miles, 261 degrees true, and 081 back. Chart data © OpenStreetMap contributors · EMODnet · GEBCO.

Under the map the run is broken down: how long the boat spends on each board and what share of the passage that is, every sail change with its time and the pair on each side of it, a row per leg with the arrival time, the boards and the distance, and the wind along the route board by board with the sail to fly on each.

Two blocks of a browser routing run’s result. ON EACH BOARD reads "Port · 6h 12m · 60%", "Starboard · 4h 7m · 40%" and "Sail changes · 2", then the two changes themselves: "01:33Z · M1 + J3 → M1 + A4" and "02:33Z · M1 + A4 → M1 + A2". Under it a table headed LEG, OUTCOME, ETA, ELAPSED, BOARDS, DISTANCE and SAIL CHANGES, with five rows all reading arrived: Kristiansand start at 2026-09-15 19:15Z, 0s, 0 boards, 0.0 nm and 0 sail changes; Ryvingen S (out) at 2026-09-15 22:55Z, 3h 40m, 15 boards, 26.1 nm and 0; Lindesnes S at 2026-09-16 01:33Z, 2h 37m, 6 boards, 19.2 nm and 0; Ryvingen S (home) at 2026-09-16 03:15Z, 1h 42m, 2 boards, 15.6 nm and 2; and Kristiansand finish at 2026-09-16 05:35Z, 2h 20m, 5 boards, 21.0 nm and 0
The same run broken down: six hours twelve on port against four hours seven on starboard, the two sail changes with the pair before and after each, and one row per leg — every leg arrived, with the longest at three hours forty over fifteen boards and 26.1 nautical miles.

Compare a slower polar, a later start or a second forecast model side by side — those are the three axes the engine takes, and the page names the three it does not: a wind-speed scale, a wind-direction offset and reverse isochrones. Scaling or rotating a forecast would mean writing a new file, and inventing a wind is not something this platform will do behind a slider. Adopt as waypoints writes the computed turning points back into the plan, keeping the plan’s own waypoints, their names and their rounding sides.

The RESULTS table of a browser routing run, under the column headings VARIANT, ETA, ELAPSED and VS BASELINE. Six rows, one per forecast run: GFS — NOAA 2026-09-09 00:00Z is the baseline at ETA 2026-09-09 15:51Z, 8h 37m, with an em dash against itself; then ECMWF IFS 2026-09-08 18:00Z at 9h 44m and +1h 6m, GFS — NOAA 2026-09-08 18:00Z at 9h 6m and +28m 37s, ECMWF IFS 2026-09-08 12:00Z at 9h 48m and +1h 11m, GFS — NOAA 2026-09-08 12:00Z at 9h 14m and +36m 51s, and ECMWF IFS 2026-09-08 06:00Z at 9h 52m and +1h 15m. The note under the table reads that isochrones are computed for the baseline route only, not for a variant
One routing run on one boat, comparing six forecast runs of two models. The first row is the baseline and every other row is read against it. Two more columns, distance and manoeuvre count, sit to the right of this crop.

Marks, chart tools, the log and the calculator

Marks are organisation-wide: a headland is a fact about a coast, not about a hull, so the whole programme shares one list and a plan that uses a mark copies its position rather than pointing at it. That is deliberate and it is stated on screen — correcting a buoy here does not silently change the shape of twelve plans somebody already saved. Marks import from GPX, and disposal is archiving rather than deletion.

Chart tools — measure, dividers, and a mark placed from a bearing and a range — are on all four navigation maps, and they are inert until you switch one on. A range reads the same number in the same words wherever it is measured, and a position computed from a bearing and a range can be saved as a mark.

The navigator’s log rides the plan, and the Notes tab under Navigation lists the plans that have one, newest writing first across the whole fleet. Beside it, a corrected-time calculator covers IRC, ORC time-on-time and time-on-distance, PHRF both ways and SRS both ways, entirely in the browser with nothing sent to the server. It reads no certificate and applies no sailing instruction, so it is not a scorer, and it says so at the top of its own page.

On the boat

LOAD RACE on the tablet’s NAVIGATION tab takes the plan off the tablet’s own cache, so it loads with no signal at all. With a route loaded, NAVIGATION swaps the mark-laying controls for SKIP, BACK and WAYPOINTS, and the corner of the plot carries six labelled numbers: DTW, BTW, XTE, VMC, TTG, DTF.

Race Control on its NAVIGATION tab with the forecast overlay running, in the night palette, with a race plan loaded. The status strip reads LIVE, "FaRo UDP :50001", the boat name and SYNCED, then BSP 7.00 kn, TWS 14.0 kn, TWA 48° and TWD 300°T. The WAYPOINT card is headed "2/5 Ryvingen S (out)" and reads DTW 19.85 nm, BTW 252°T, XTE 4 m STBD, VMC 7.0 kn, TTG 2:50:11 and DTF 68.37 nm, over "ETA 16:57 UTC", "Next leg 272°T · 14.27 nm" and "Wind at Ryvingen S (out) 297°T 13.3 kn projected at the current VMC — ECMWF 06z". Forecast barbs are drawn across the water over the derived chart and the plan’s orange legs. A stepper card along the bottom reads "now" over "ECMWF 06z · 1/47" between a back and a forward arrow, with the line "Gusts are the maximum over each step’s own window." under it. Five controls stack down the right edge: WAYPOINTS, "Move, add, reorder, draw zones — and save the plan back. · 1 zone"; WIND ON, "ECMWF 06z · fetched 12:32 · to Sat 06:00"; MODEL, "ECMWF 06z"; SOURCE, "Tint the water by how well its depth is known."; and TIDE ON. Along the bottom: "44.9 nm across  your view · double-tap re-fits"
NAVIGATION on the tablet with a plan loaded, on a Sørlandet coastal plan, fed by a desk simulator: the WAYPOINT card giving the six numbers for 2/5 Ryvingen S (out), the forecast drawn over the water as barbs, the step card reading now · ECMWF 06z · 1/47, and the WIND ON control naming the run it draws — ECMWF 06z, fetched 12:32, running to Sat 06:00. Chart data © OpenStreetMap contributors · EMODnet · GEBCO.

PATH AHEAD then routes the rest of the course from where the boat is, through the forecast the tablet holds, against the depth in the sea model and around the plan’s own exclusion zones. Each leg card gives the board it is entered on, the heading to steer, the arrival time, how long on this board, how many boards, and the sail pair the boat’s crossover chart calls for — with an amber line at each change.

Race Control on its PATH AHEAD tab, in the night palette, routing the same beat from the boat’s own position with the other model’s path drawn as well. The status strip reads LIVE, "FaRo UDP :50001", the boat name and SYNCED, then BSP 7.00 kn, TWS 14.0 kn, TWA 27° and TWD 300°T; PATH AHEAD is lit in the tab row. Two routed paths cross the chart: the primary in cyan, leaving the plan’s own straight orange leg between 2/4 Ryvingen S (out) and 3 Lindesnes S and sailing it in three boards before running back east to the finish, and a thinner grey one beside it, the other model’s path drawn without boards. Each carries its own arrival label — ECMWF 20:21 UTC on a leader to the finish ring, and GFS 20:10 UTC against the grey path further down the coast. Grey isochrone dots fan out behind both and a red exclusion-zone rectangle stands beside the boat. Down the right, the PATH AHEAD card reads 20:21 UTC in large type over "8h 42m to the last mark", then "ECMWF primary · 20:21 UTC", "vs GFS 20:10 UTC (−11 m)", "Depth checked all the way on 115 m cells" and "Margin 3.0 m · 1 zone · 4 hazards". Under it stand RECOMPUTE and PIN, and under those the first leg card: "1. Lindesnes S" badged STBD, reading PORT, 310°T and 14:24 UTC against the labels BOARD, HEAD and ETA
PATH AHEAD on the same plan and the same simulated feed, routing the rest of the course from where the boat is: the routed path in cyan, leaving the plan’s own orange leg between Ryvingen S and Lindesnes S and sailing it in three boards before running back east to the finish, the grey path the other model routes beside it, the isochrones behind both, and an arrival label on each — ECMWF 20:21 UTC and GFS 20:10 UTC. The panel reads 20:21 UTC, 8h 42m to the last mark, ECMWF primary at 20:21 UTC against GFS at 20:10, eleven minutes earlier, the depth checked all the way on 115 m cells, and under it margin 3.0 m · 1 zone · 4 hazards. Chart data © OpenStreetMap contributors · EMODnet · GEBCO.

The plan can be changed aboard with no signal. SAVE TO PLAN writes to the tablet and sends when there is a link; if the plan also changed ashore, the tablet offers three answers rather than merging — KEEP MINE, TAKE THEIRS, KEEP BOTH. There is no merge, because nothing on the platform can tell which of two routes is right.

One leg card from Race Control’s PATH AHEAD tab, in the night palette, scrolled past the card’s board and heading row to the lines under it. Five lines stand inside the card’s cyan border: "TWA 141° · TWS 15.0 kn"; "Depth checked all the way on 115 m cells"; "Set 149°T · 0.2 kn"; "Sail M1 + A2"; and, in amber, "Changes to M1 + A4 at 16:32 UTC"
One leg card from the same tab, on the same plan and the same desk-simulator feed rather than a day anybody sailed, scrolled to the lines under the board and the heading: the wind on the leg, the depth check, the tidal set, then the sail pair the boat’s own crossover chart calls for and the amber line at the change. A leg card carries those last two lines only when the boat has a crossover chart entered; the two figures above are of a boat that has none.

Charts, and the three tiers kept apart

The platform’s own chart is global and is what both surfaces draw by default: depth shading against your own draft, contours, soundings, seamarks, lights and hazards, built from OpenStreetMap seamarks and public bathymetry, with the survey quality it can offer declared per cell rather than borrowed from an office’s own zone of confidence.

Official charts are two different things on two surfaces. In the browser, the plan editor can lay an official raster chart under the course — Kartverket’s Sjøkart for Norway and NOAA’s for the United States, off by default and never at the same time as each other’s water. On the tablet, the official tier is vector ENC cells, and its coverage is the United States today, because NOAA publishes its ENCs for redistribution and European hydrographic offices license theirs. Swedish, Finnish and Danish official charts are not available.

Kartverket’s raster is a browser layer and does not reach the tablet. And what the tablet carries is a repacked corridor extract: it is not an official ENC, it does not meet chart carriage regulations, and its symbols are a racing subset rather than a conformant S-52 presentation. The tablet says which of the two charts you are looking at, in the SOURCE legend and on the probe card, and it says no official chart for this area when it has looked and there is none — which is a different sentence from silence.

What the platform’s own chart resolves

Depth is fused from public bathymetry, finest covering source first, first source with a value winning the cell and nothing averaged: NOAA BlueTopo at 2 to 16 m over US waters, NOAA’s coastal relief model at about 92 m over US coasts, LINZ charted soundings over New Zealand, GMRT at about 100 m where the sea floor has been surveyed, EMODnet at about 115 m over Europe, AusSeabed at about 250 m over Australia, and GEBCO at about 463 m as the global fallback. Lakes above sea level are corrected to their own surface level from HydroLAKES, with chart datums for the Great Lakes and the large Nordic lakes. The resolution that answered is declared per cell, which matters: a corridor served only by the global fallback is coarse, and the probe says so rather than drawing a confident contour over it.

Current comes from seventeen ranked ocean models — thirteen NOAA coastal forecast systems over US waters and the Great Lakes, four Copernicus Marine regional products, and the Copernicus global product behind them. The finest model whose own published area contains the whole corridor, and which answers, wins the whole of it. One source per corridor, never spliced, and its name, its resolution and whether it already includes the tide travel in the file’s own header. Tide height is fused separately, per corridor.

Two bathymetry sources do not share a zero — EMODnet is referenced to the lowest astronomical tide and GEBCO to mean sea level — and that is stated rather than smoothed over, because a depth is only as good as the datum under it.

Deck channels and instrument output

The boat keeps a document saying what Race Control transmits back onto its own bus: the gateway kind and address, the slots, the transport, the key, the value each slot carries, its label, decimals, damping and rate. It transmits the app’s own computed values — time to gun, time to burn, distance to the line, line bias, laylines, targets — and never wind or boat speed, which are the instruments’ own.

None of this has been checked against a physical display, and Garmin slots transmit nothing at all — the NMEA 2000 message that carries Garmin custom data has not been identified, and the transport is in the list so the document can describe a Garmin boat. Both limits are printed where the document is edited, and neither is softened here.

If you already navigate with Expedition

This table says two things and no others: what Nordic Stars does, and which Expedition file formats and tables Nordic Stars reads. It makes no claim about Expedition. The mapping is interoperation, not a comparison.

What you already haveWhat Nordic Stars does with it
Race logs (.csv) and the matching event filesImported as a day. Guns and line pings arrive as race events; the event times are venue-local with no zone marker, so the import asks which venue you sailed and anchors them to UTC.
Polar tables and VPP outputUploaded as the boat’s polar, in one of three roles — start, nav and perf. The tablet routes on nav; perf is the yardstick a percentage is measured against.
CAL tables — acceleration, rate of turn, brakingRead off the boat by the tablet and charged to every routed path: the turn time plus the speed it costs to get back up. The units are Expedition’s, verbatim, because converting them would make every future disagreement two-sided.
The column names your files are written withMapped onto the platform’s channel registry at import, with the mapping remembered per format and shared across your organisation; anything the registry has no name for becomes one of your own custom: channels.
The GRIB you download yourselfImported on the tablet. The packings it reads and the ones it declines are named by name in the guide.
The committee’s GPXImported into a race plan: a route first, loose marks second. A recorded track is counted and not read — a track is where a boat went, not a course to sail.
The numbers you want on a mast displayInstrument output over a gateway, carrying the app’s own computed values only. One of the three gateway transports speaks Expedition’s simple protocol. See the limits below before relying on any of it.

How it works

  1. Draw the plan: waypoints, rounding sides, zones, depth margin.
  2. The corridor forecast arrives on each model’s own schedule.
  3. Open it in the viewer and read the wind along the course.
  4. Route it, compare the variants, and adopt the path you want.
  5. LOAD RACE on the tablet at the dock, while there is still wifi.
  6. Sail it with NAVIGATION and PATH AHEAD, with no signal.
  7. The day is in the debrief player when you tie up.

What it does not do

A computed route is a planning result, not a passage plan. It follows the forecast in one file and the depth in one sea model, both of which can be wrong or incomplete, and the ship’s plotter stays the navigator’s authority. This is race navigation support.

  • No autopilot and no steering output. Instrument output puts numbers on a display; nothing on this platform steers a boat.
  • No write-back of calibration to the boat’s processor. A correction is a read-time lens on the platform’s own copy of the data — see Data Analytics — and the instruments go on reading what they read.
  • No encrypted S-63 vector charts on any tablet. The licensed tier exists in the platform and is off; every boat on the platform today falls through to the open NOAA cells. No official charts outside the coverage named above.
  • No native NMEA 2000 live ingest — the tablet reads a gateway that puts the bus out as NMEA 0183 — and no B&G H5000 websocket source.
  • Instrument output has never run against a physical display, and Garmin slots transmit nothing.
  • The sail crossover chart and the routing limits are per tablet and do not sync; a second tablet aboard keeps its own copy, and the browser reads neither. The browser’s own sail column is read from a chart built from the boat’s registered wardrobe, one wind range per sail from its category — ordinary shapes of use rather than measurements, and not the crew’s own numbers. The routing limits it reads not at all.
  • Routing limits are not a weather warning and not a rule check: the tablet does not know which race you are sailing or what its sailing instructions say about propulsion. Motoring is off until somebody turns it on, motoring never opens the no-go zone, and every routed leg that uses it says so.
  • An exclusion zone written into an exported GPX rides our own extensions, so no other program reads it, and GPX import brings in routes and marks rather than zones.
  • The routing comparison offers a polar scale, a start offset and a second forecast model. It names on screen the three axes it does not offer — a wind-speed scale, a wind-direction offset and reverse isochrones — rather than leaving a navigator to hunt for them.
  • A mark used by a plan is copied into it, so correcting a buoy in the marks list does not change the shape of the plans that already used it. The screen says so.
  • The corrected-time calculator is not a scorer.

Two things this section deliberately says nothing about, in either direction: waves and storm surge. The sea model does not carry them, and an absence claim would be as unsourced as a presence claim.

Common questions

Does the route computed in the browser match the one on the boat?

Yes. The browser and the tablet run the same routing program — one Kotlin library, compiled to WebAssembly for the browser and shipped as itself on the tablet — so the same request returns the same numbers.

Which forecast models are fetched for a race plan?

ECMWF IFS, ECMWF AIFS, GFS, ICON and AROME, up to four at a time, on each model’s own run schedule and clipped to a corridor around the route. Each model’s own limits are stated beside it: AIFS publishes no gusts, AROME covers 37.5–55.4° N, and ICON’s high-resolution European nest stops at 29.5° N.

Can I sail the plan with no signal?

Yes. LOAD RACE takes the plan off the tablet’s own cache, and the forecast, the sea model and the chart are fetched at the dock rather than at sea. PATH AHEAD routes the rest of the course from where the boat is, offline.

Are official charts included?

In the browser, official raster charts cover Norway and the United States and are off by default. On the tablet, the official vector tier covers the United States today. Everywhere else both surfaces draw the platform’s own chart, and the tablet says which of the two you are looking at.

Is a computed route a passage plan?

No. A computed route is a planning result. It follows the forecast in one file and the depth in one sea model, both of which can be wrong or incomplete, and the ship’s plotter stays the navigator’s authority.

Where to read more

  • NavigationThe 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.
  • Race plansPlanning a coastal or offshore race ashore: the map, waypoints and rounding sides, exact positions in degrees and decimal minutes, the water to avoid and the depth to keep under the keel, importing the committee’s GPX — and what happens when two people edit one plan.
  • WeatherWhat 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 seaImporting 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.
  • Currents and tidesThe tidal stream and the height of tide: where each comes from, what the current changes in the routing, in the laylines and on the chart, the units and datums they are stated in — and the limits, including no surge and a grid that does not resolve a harbour.
  • Planning a coastal or offshore raceA 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.
  • Laylines and board timesWhere the tacking angle comes from and how long to hold this board: the source chain behind a layline, the two-board solve, and which mark the plan is aimed at.
  • The boat’s clockWhy the tablet stamps nothing: the instruments’ clock carried forward as an offset, freshness judged source against source, and the one question the tablet does answer.

The rest of the platform

Draw the course, take the forecast at the dock, and route it with the engine the tablet runs at sea. Every account starts with a 30-day free trial for one boat, no card required.