How the Data Works#

If you dive Puget Sound or the Strait, you already know the problem: the tide table on your phone says slack at 2:47, you show up at 2:40, and the water is still ripping. Generic tide apps work fine for surf check-ins in open coastline. They fall apart in complex environments like ours — narrow passages, deep basins, shifting haloclines. Add the confusion of picking the right NOAA station out of dozens of nearby options, each with its own offsets and quirks, and predictions can be extremely hard to get right. The result ranges from inconvenient to certifiably dangerous.

I built TideTracker because I wanted an efficient way to plan safer dives in a hard-to-predict environment. Most of the data was already there — but local knowledge has never been consolidated concisely to fill in the missing pieces. TideTracker closes that gap with verifiable, site-specific data for the places we actually dive. It aims to present that data in a format you can actually parse at 5 a.m., before your first cup of coffee and the drive to the beach — and hopefully save you a long walk in full gear to a site that isn't diving today.

This page explains where the numbers come from, what I do to them, and — just as importantly — what I don't.

Why corrections are necessary#

NOAA publishes two kinds of predictions relevant to divers:

Harmonic predictions come from reference stations with long tidal records. Seattle, Tacoma, Port Townsend, Neah Bay. These are the gold standard — decades of data, regularly maintained, genuinely accurate at the station itself.

Subordinate station predictions are derived. NOAA takes a reference station and applies a published offset — a time adjustment and sometimes a height ratio — to estimate conditions at a nearby site that doesn't have its own long-term gauge. Most dive sites fall into this category. Some of those offsets are excellent. Some are decades old, based on short survey periods, and visibly wrong to anyone who dives the site regularly. At a site with strong currents, a thirty-minute error in slack prediction isn't inconvenient — it's the difference between a planned dive and an unplanned drift.

Current predictions have the same split, and the situation is worse. Current reference stations are sparser, subordinate current stations are often tied to tide stations rather than to their own current measurements, and slack times in constricted passages don't always correspond to the high and low water that drives the math. Dive sites are also frequently far enough from their assigned subordinate station — geographically, and more importantly hydrologically — that both maximum current and slack timing can drift meaningfully from what the offset predicts.

The result: the raw NOAA number for your dive site is usually close, sometimes excellent, occasionally off by enough to matter. At sites where "off by enough to matter" means being pulled away from your exit, that gap stops being a data-quality issue and starts being a safety one. The correction engine exists to narrow that gap, flag the uncertainty, and show you what it's doing.

Where the data comes from#

Every prediction in TideTracker starts as a pull from a NOAA API:

Tide predictions — CO-OPS tide prediction endpoints, 6-minute intervals, harmonic where available, subordinate-station-derived otherwise.
Current predictions — CO-OPS current prediction endpoints, same interval, same hierarchy.
Station metadata — station IDs, coordinates, reference station relationships, published offsets.

No scraping, no third-party aggregators. If NOAA's upstream data changes, TideTracker reflects that change on the next refresh.

One detail worth disclosing here, because the briefing surfaces it but it's easy to miss: the 6-minute tide curve plotted across the day in the briefing chart is always pulled from Seattle (9447130), regardless of the site's assigned tide station. Seattle's high-resolution feed is the cleanest continuous source, and using it for the curve gives every site a smooth, reliable plot. The high and low tide times shown in each dive window — the values that drive slack-vs-tide lag and the tidal-range metric — still come from the site's own assigned tide station, so peak times and tagged metrics remain accurate for that specific location. The chart itself notes this in a footnote on sites where the two stations differ.

Corrections are layered on top of this raw NOAA data — never in place of it. The original prediction, the applied offset, and any correction are all visible to the user, along with the source of each. When user-reported observations begin feeding the correction engine, the same rule will apply: every adjustment will be traceable to its source, whether that's NOAA, the correction engine, or a community report.

What the correction engine does#

For each dive site, TideTracker maintains a mapping: which NOAA station (or pair of stations — one tide, one current) is the best available proxy, what offsets apply, and how confident we should be in the result.

The correction step does three things:

Applies the published NOAA offset for subordinate stations. This is baseline, not novel — it's what any honest tide app should do.
Filters outliers from the correction history using interquartile range (IQR) bounds. Corrections are derived from user-submitted observations compared against the predicted value at the time of the dive. A single weird report (a mistimed slack call, a misread gauge, a ferry parked on the sensor) can poison the average, so the IQR filter throws out values that sit too far from the middle of the distribution before computing the applied delta.
Surfaces the source of every prediction. Each metric in the briefing is tagged with the NOAA station it's drawn from, and Step 2 of the Plan a dive wizard surfaces the full station pairing for the site — current station, tide station, IDs and all. If you want to know where a number came from, you don't have to dig.

Because corrections are driven by user observations, the engine gets better as more divers report in. A larger sample size tightens the distribution, pushes genuine errors to the edges where the IQR filter can catch them, and leaves the reliable middle to drive the applied delta. This also means you don't need to be hyper-accurate in your reports — a rough slack time from a real dive, logged honestly, is more useful than nothing and won't single-handedly skew a site's correction. We'll cover exactly how reporting works in the Community section.

What the correction engine doesn't do#

This is the honest part, and it matters more to experienced divers than anything above:

It doesn't model hydrodynamics. No CFD, no basin-scale simulation. The app isn't predicting currents from first principles; it's refining NOAA's predictions using NOAA's own framework.
It doesn't account for weather. Surface conditions — especially surface currents — can differ significantly from mid-water and bottom currents, in both direction and velocity. Wind, barometric pressure, and river outflow all drive that divergence. Weather integration is on the roadmap, but even when it lands it will inform surface conditions, not replace the NOAA-based prediction for depth.
It doesn't replace your own judgment. If you know from ten years of diving Alki Junkyard that the surface ebb starts pushing earlier than the prediction says, trust that. The app is a planning tool, not a substitute for local knowledge — and honestly, your local knowledge is part of what I'm trying to capture and feed back in.
It doesn't decide whether the dive is safe. Conditions you assess on site — visibility, surface state, your team's readiness, your own physical state that morning — ultimately determine whether a dive is within your training and abilities. TideTracker is a planning tool for sharpening your expectations before you get to the water. It is not a substitute for good judgment, current training, and the experience to know when to call a dive.

Badges and how to read them#

Every prediction in TideTracker carries badges that answer two questions: how good the dive opportunity looks, and how much you should trust the prediction behind it. Four badge dimensions, organized into two pairs.

How good is the dive opportunity?#

Day rating — appears on the briefing hero once a date is fetched, and on each day's card in date-range mode. Three states: Good day, Marginal day, Poor day. This is a coarse signal for browsing — at a glance, which days at this site are worth a closer look. A "Good day" doesn't mean dive it; a "Poor day" doesn't mean don't. It means "start your planning here."

Window quality — appears on each slack window in the daily briefing. Four states: Best, Good, Marginal, Skip. This is the finer-grained signal you actually plan around. A day rated "Good" overall might have one "Best" window in the morning and a "Marginal" one in the afternoon. Window quality factors in slack duration, predicted current strength on either side, and time of day.

How much can I trust the prediction?#

Confidence — three tiers based on how many verified diver observations stand behind the correction at this site, with an activation gate before the badge appears at all:

No badge yet — fewer than 10 observations. The briefing shows "No correction data yet" (zero observations) or "Correction pending: n/10 required" (one to nine). The correction engine has nothing to apply, so predictions fall back to raw NOAA.
Low — 10 to 19 observations. The applied delta is active but still settling.
Moderate — 20 to 49 observations. The correction is meaningful but still tightening.
High — 50 or more observations. The applied delta is well-established and stable.

Confidence tells you how much evidence sits behind the correction. A high-confidence prediction at a frequently-dived site like Keystone Jetty carries a lot of accumulated reality; a low-confidence prediction at a newer or less-reported site is still leaning more heavily on raw NOAA data.

Staleness — every site shows when its correction was last updated ("updated 3 months ago"). Sites that haven't received new observations in 12 months are flagged stale.

A stale flag is a soft warning, not a verdict. A site with a stale but well-established applied delta will still usually beat raw NOAA predictions alone — the corrections don't expire, they just stop reflecting recent conditions. The flag is there for two reasons: so you know to weight the prediction with appropriate skepticism, and so that if you do dive the site and notice something off, you can include that context in your report. "Predicted slack and current strength were both off; data was over a year old, site may need fresh corrections" is exactly the kind of feedback that helps me prioritize which sites need attention.

Where the prediction came from#

Beyond the four badge dimensions, every briefing surfaces the NOAA stations it's built from. Step 2 of the Plan a dive wizard shows the site's station pairing — current station, tide station, with NOAA IDs visible — before you even fetch predictions. Inside the briefing itself, individual metrics are tagged with their source station: a max flood reading at Alki Junkyard might be tagged with Rich Passage; a tidal range at the same site might be tagged with Seattle. Different metrics can come from different stations, and the tags tell you which is which.

This is the closest thing to a lineage indicator the app currently has, and it's deliberately granular — telling you which station each metric is drawn from is more useful than telling you whether a single page-level prediction is "reference" or "subordinate."

What's not yet in the badges#

One thing planned but not shipped: trajectory — whether a site's correction is improving, stable, or declining over time. Useful signal, but it requires more pattern analysis than the engine does today. On the roadmap.

What's coming#

Three things are in active or near-term development that will sharpen this further:

Weather integration — wind, barometric pressure, and river outflow, surfaced as a layer for anticipating surface-condition divergence from NOAA predictions. Not a correction to the underlying depth-current model.
User-reported discrepancies — structured in-app reporting so you can tell TideTracker "slack was actually at 3:05, not 2:47" at a specific site. Aggregated reports feed the correction engine through the IQR-filtered applied delta described above.
Remote sensor network — standalone pressure and current loggers at sites that are geographically or hydrologically far from NOAA stations, or that show low correction confidence. Long-term; deployment prioritized by distance from reference stations, correction-model confidence, and user reports.

Questions, corrections, disagreements#

If you dive a site regularly and the app is wrong about it, I want to know. The feedback form in the app goes straight to me. Specific is better than general — a date, a site, what the app said, what you saw — but any signal helps. Even a note that says "the Keystone Jetty prediction has been consistently off for weeks" tells me where to look.

This is beta. The data pipeline will keep improving. Everything above is how it works today.