Case study · Built and running

Passage Plan — the decision-support tool a deck officer built for his own bridge.

A personal tool that turns a GPX route through the Black Sea, Marmara, Aegean and Mediterranean into a full passage-plan draft: VTS areas and reporting points marked, live NAVTEX, weather, depth and UKC, MARPOL fuel changeovers and a checklist with the master’s approval. Built by a chief-mate candidate for his own watches. Advisory by design; it does not replace the ENC or the company SMS.

The problem

The plan lives in ten sources that never talk

Preparing a passage plan is hours of assembly after the route is drawn on the ECDIS: pilot books for VTS limits and reporting points, NAVTEX on another screen, weather on another site, UKC by hand on paper, ECA entry points from memory, and finally the company’s Excel checklist. The same work is redone every voyage and something is always missed.

The bar

It never guesses; it says so

The design rule for the tool: when a value is unknown the screen says “no data”, it never assumes. Depth and distance-to-land are suggestions; UKC is computed only from the depth the officer typed. Every source carries its precision (official / derived / approximate) and an unverified record looks unverified on screen.

What runs today

One chain from GPX to a signed PDF

Import GPX → legs, courses, ETAs → VTS and reporting plan → NAVTEX, weather, currents, daylight → depth suggestion and TSS check → zone-based UKC and an ECDIS settings card → MARPOL ECA changeovers → checklist and master approval → PDF with map, RTZ and GPX export. Under way: GPS or manual fix, XTE and the next reporting point.

Inside the system

What was built.

Passage Plan leg list and map: ECDIS settings card with safety depth and XTL per zone, legs with courses, ETAs, UKC, VTS and reporting badges, and a Varna to Almeria route with abort points and reporting points
Varna–Almería route: leg list, ECDIS settings card, VTS and reporting badges, abort points and reporting points on the map. Personal instance, sample route.

GPX routes named from a dictionary

A GPX exported from the ECDIS or planning software is uploaded; placeholder names such as “WP 012” are auto-named from a dictionary of known points with a radius (Varna breakwater, pilot-off point, Çanakkale SP-1). The dictionary is edited on screen and each point is verified against a source; unverified names are listed in the summary. Manual fields are keyed by a coordinate-based leg id, so renaming a waypoint never wipes the depth you typed.

VTS areas and reporting points, real polygons

VTS areas for the Turkish Straits and Marmara, the Black Sea (Bulgaria and Georgia included), the Aegean and the Mediterranean are stored as real polygons with channel and call sign; reporting points are defined as a line to cross, an area to enter or a “24 hours before entry” rule. The route is intersected with all of them and every report lands on its leg with ETA, position and content. You can draw your own areas and points too; they stay marked with “user” precision.

Live NAVTEX, weather and currents

NAVTEX warnings are pulled from NGA MSI and from SHODB (Samsun, Istanbul, Izmir, Antalya), their coordinates parsed, and those within 50 NM of the route attached to the leg. Wind and waves come from Open-Meteo and reduce leg speed in heavy weather; strait currents are a typical-current model from literature values, not a forecast, and show up as minutes on the ETA. If the weather service is down the plan is still produced; it just says “weather unavailable”.

Depth suggestion and TSS check

For every leg a minimum-depth profile is extracted from EMODnet bathymetry (GEBCO as fallback) and crossings are checked against a bundled OpenStreetMap TSS snapshot for the Mediterranean and Black Sea: schemes crossed, separation zones cut, schemes nearby. The result is always presented as a suggestion; when a tile could not be fetched the section never reads as clean, it says it is incomplete.

Zone-based UKC and an ECDIS settings card

Legs are classified into open-sea / coastal / port-limits / berth zones, each with its own UKC policy (defaults are placeholders; the company SMS prevails). The UKC figure includes Barrass squat, a CATZOC reliability allowance, heel sinkage in turns and tide. From this a card proposes safety depth, safety contour, look-ahead time and XTL per zone for the ECDIS, with its basis written under the card.

Checklist, MARPOL and export

A 54-item checklist compiled from IMO A.893(21), SOLAS V/34, OCIMF SIRE 2.0 and the ICS Bridge Procedures Guide: part is evaluated automatically (NAVTEX read? TSS present?), the rest is ticked by hand; it closes with prepared-by / checked-by / master approval and a briefing record. The MARPOL layer gives Mediterranean SOx ECA entry and exit, the fuel changeover point and per-leg discharge and ballast rules, and checks the corridor against drawn no-go areas. The plan exports as a PDF with map, IEC 61174 RTZ and GPX.

Discipline

How it stays trustworthy.

Passage Plan checklist tab: 10 of 54 items complete, 8 missing, items citing A.893(21) and SOLAS V/34 with the NAVTEX warnings near the route listed under the relevant item
The checklist tab: every item shows its source; the NAVTEX item lists the 19 warnings near the route. Decision support, not a substitute for company procedure.

1,026 Python tests, 313 web tests

Every calculation module — squat, UKC zones, CATZOC, turns and wheel-over, daylight, currents, ECA crossings, RTZ export — ships with its own tests; the UI components are tested with Vitest. The data files are tested too: every VTS polygon must be valid and inside the world, ids unique, source URLs well-formed.

The same caveat on every screen

The same sentence sits in the app’s bottom bar, in the PDF and in the checklist: the map and warnings are for awareness; they do not replace the official ENC, paper charts or the NAVTEX receiver. Squat is an estimate and the master’s UKC policy governs. The software never declares anything “safe”; it shows the officer something he has not looked at yet.

No record without a source

Every VTS area, reporting point, ECA boundary and checklist item carries a source URL and a short note; the MEPC.361(79) Mediterranean ECA lines are regenerated deterministically from the Natural Earth coastline. A polygon not derived from an official publication is stamped “approximate” and drawn that way on the map.

Stack

A fast path and a slow path

FastAPI back end; Vite + React + TypeScript with MapLibre GL in front. The plan computation returns in under two seconds when weather and NAVTEX are cached; depth and TSS analysis is a separate slow endpoint that never blocks the plan. The app is a PWA: the last plan, layers and viewed map tiles are readable offline, and the bar says “offline: last data”.

Delivery

Contract first, then code

Each wave (v1.0 → v1.6) is first fixed as a written API contract between the front end and the back end, then the two sides are built independently; every addition is backward compatible. The Docker image, the server deploy script and CI (pytest, tsc, Vitest, data validation) live in the repository.

Status

Personal, private, in use

Runs on the author’s own server, behind access control, for a single user; it has no public address and none is planned. This is not a product but a tool an officer wrote to speed up his own passage-plan preparation. The same approach — sourced data, calculations that never guess, master approval — can be adapted for a fleet or a training institution.

Related work: MarOps — back office for small shipowners · Free maritime tools that run in the browser.

Next step

Doing the same assembly job on your bridge?

Ask for a walkthrough — or bring one GPX and we will plan it together.

Get in touch