Fleet Operations Panel

the problem

A small ship operator's data is scattered by default: positions live on a generic tracking site, certificates live in spreadsheets, noon reports arrive as email attachments that get retyped by hand, and charter terms live in someone's head. Generic AIS trackers show positions and nothing else; enterprise fleet software is built for much larger fleets and correspondingly harder to deploy for an operator running 5 to 30 ships. The goal was one screen that consolidates all of it without asking the crew to change how they already report.

how it is built

• Python/Flask backend (application-factory and blueprint structure) with PostgreSQL and PostGIS for geospatial vessel and route data.
• Live AIS vessel tracking on Leaflet with OpenSeaMap tiles, plus a CesiumJS 3D globe view with a dedicated always-on "TV mode" — auto-tour between ships, large clock, fleet summary — meant to run unattended on an office display.
• A custom maritime route engine instead of straight-line or generic routing: the traveled portion of a route comes from real AIS track history, and the remaining planned portion is computed over real coastline data so it follows straits, canals and islands instead of cutting across land.
• Certificate and survey tracking (ISM, ISPS, MLC and class) with cascading 90/60/30-day alerts and traffic-light status, plus a survey-window field per certificate.
• Performance analytics from manually-entered noon reports: fuel-consumption trend, a speed-vs-consumption curve, a speed-vs-weather (Beaufort) correlation chart, a CII carbon-intensity score, and port/anchor/underway time-split analytics.
• Eight standard voyage report types (DSR, DPR, DAR, DDR, PDR, AAR, ADR, plus daily position) modeled as structured records tied to a voyage, not free-text logs.
• A commercial/chartering ledger alongside the operational modules — hire rate, charter-period progress, off-hire day tracking, re-delivery countdown, daily fleet revenue.
• Role-based access (Admin/Operator/Observer) over HTTPS/TLS.
• Reports render to PDF through WeasyPrint (HTML to PDF) rather than a separate reporting engine.

the hard parts

• Realistic sea routing needed two different grid resolutions, not one: a coarse global grid (about 1.1km cells) finds the overall corridor quickly, then a fine local grid (about 275m cells) is built only around that corridor and re-solved at that resolution — solving the whole world at fine resolution is too slow, and solving it only at coarse resolution misses features like the Bosphorus, which is roughly 700m wide at its narrowest point.
• Coastline data quality turned out to be the actual bottleneck, not the pathfinding algorithm: an earlier version built on lower-resolution reference coastline data produced routes that visibly cut across capes, deltas and narrow straits. The route engine was rebuilt on full-resolution OpenStreetMap coastline polygons instead, with a zero-tolerance validation pass — every route segment is checked against real land polygons, with narrow, deliberate exemptions only for man-made shipping canals and port-approach zones.
• Ingesting noon reports without changing how captains already work: rather than a new form or app, the system re-parses the same Excel and plain-text report formats captains already send by email, triggered by CC-ing one address — so fuel and speed data, which isn't in AIS at all, flows in without a change to the ship-side workflow.