salish-nav-planner

Multi-day trip-planning aid for cruising Puget Sound and the Salish Sea. Pick a start, a first-night destination, and a trip length (1–7 days); the planner chains the remaining days for you, picking each night's stop to fit your preferred day length. Not for navigation — carry current charts.

Controls:

• Days (1–7) — how many days to plan.
• Min / max hours per day — the day-length window auto-picked stops must fit. Days are chosen closest to the middle of the window. Hours rather than miles because a cruising day is bounded by daylight, not distance.
• Speed (kt) — your boat's cruising speed, default 6. Reachable distance is hours × speed, so changing speed replans the stops, not just the times: a 3–8h day reaches 18–48 nm at 6 kt but 30–80 nm at 10 kt.
• Round trip — finish back where you started. Leave it off and you can optionally name an End at port to finish somewhere else (deliver the boat to Anacortes), or leave that blank to wander one-way with no return obligation.
• Mast (ft) — height above the water. Three feet is added for masthead gear, and hops under fixed spans that don't clear are removed from the graph, so the planner routes around them: at 45 ft Port Ludlow to Port Townsend runs 12.9 nm through the Port Townsend Canal, and at 60 ft it becomes 35.1 nm around Marrowstone Island. Opening bridges never block a route — they're a radio call and a wait — so they're reported rather than avoided. See Bridges and air draft.
• Start date and Depart — when the trip begins and what time you get underway each day. Together they turn the plan from a sequence of hops into dated, clock-timed days, which is what makes a weather forecast and a slack-water table mean anything.
• Let the forecast shape the plan — when on, wind is a ranking term alongside day length and return shape, so a day that means a long beat into a blow loses out to a shorter or more sheltered one. Turn it off to see the forecast without letting it move your stops. It disables itself past the ~16-day forecast horizon, where planning falls back to distance alone.
• Each day after the first can be re-rolled (Next cycles through the other candidates) or pinned to a specific stop; pinning a day resets the auto-picked days after it, since they were chosen relative to a different upstream stop. A pinned stop outside your day-length window is honored but flagged.
• Share opens the device's share sheet where available. Copy link puts the same compact, self-contained trip URL on the clipboard. The URL includes the planner settings, the resolved stop sequence, and which days you explicitly pinned, so the recipient sees the same itinerary even if live weather or destination rankings have changed. Existing version 1 links still open. Unsupported or malformed links show a warning.

Each planned day shows the day's wind (direction, sustained and gust speed, Beaufort force, and your point of sail on that heading), plus every tidal pass on the route with your estimated arrival time, the predicted current at that moment, and the next slack — so a pass reads as an appointment rather than a distance.

Routing data is scraped from nwcruising.net's ~220 harbor/marina/point pages, each listing distances, times, and "via" passage notes to other locations. See Data below for how that's licensed and why the scraped output isn't committed to this repo.

See the planner roadmap for upcoming work and the architecture decision log for design decisions.

Stack

• Next.js App Router + React + TypeScript strict
• PandaCSS + Park UI preset + Ark UI primitives
• MapLibre GL + pmtiles protocol for the map — matches the chart-tile pipeline in the sibling bc-charts-pm repo
• Vitest for unit tests
• Hexagonal-ish layering: src/domain (pure types/logic) → src/application (routing graph, trip planner, ports) → src/adapters (fs-backed repository, Next server glue) → src/components (UI)

MapLibre worker

scripts/copy-maplibre-worker.mjs stages maplibre-gl's web worker into public/maplibre/ (run automatically on install, dev, and build). maplibre otherwise computes its worker URL at runtime from import.meta.url, which under Turbopack resolves to a chunk path that's never emitted — the worker 404s and every GeoJSON layer silently fails to draw while raster tiles and markers still render. map.tsx calls setWorkerUrl() to point at the staged copy. If vector layers ever stop rendering, check that copy is present and matches the installed maplibre-gl version (public/maplibre/VERSION).

Getting started

npm install
npm run scrape   # crawl nwcruising.net -> public/data/*.json (one-shot, ~2 min)
npm run dev      # http://localhost:3000

Run npm run scrape before npm run dev or npm run build to populate the planner. The app requires route data by default. CI can opt into an empty dataset for its build and supplies fixture data at test time.

Deployment

netlify.toml configures Netlify to use Node.js 24, run the standard npm build, and deploy Next.js through Netlify's automatically managed OpenNext adapter.

Getting route data into a deploy

edges.json and locations.geojson are gitignored, so a Git-based build checks out a repo with no routes in it. The home page reads route data and the shared trip URL at request time. The build fetches the data before compiling the app so the deployment can serve routes.

npm run build therefore runs npm run dataset first (scripts/fetch-dataset.mjs), which pulls both files from wherever you host them:

The files live in a private Cloudflare R2 bucket, read over R2's S3-compatible API with a SigV4-signed request:

This is the beginning of the README. Read the rest at the original. Read the full README ↗