Transparent by design
How estimates work
Rainier Gate Waits is an experimental, independent service. It estimates entrance delay by comparing current traffic travel time with normal travel time on a fixed approach segment, then optionally adjusting that baseline with recent community wait timers.
Plain-language summary
- The service checks the traffic-aware and normal travel times on a fixed road segment approaching each entrance.
- The difference between those travel times becomes the baseline delay.
- Recent visitor timers can adjust that baseline, but cannot create an estimate when recent traffic data is unavailable.
- The service widens the displayed range when reports disagree or the traffic observation is aging.
- Old observations are labeled stale and then hidden.
1. Traffic-delay baseline
For each entrance, the service requests a current traffic-adjusted travel time and a normal travel time for a fixed approach route. It calculates the baseline as:
maximum of 0 and (traffic-adjusted travel time − normal travel time)
Example: if an approach normally takes 12 minutes but currently takes 32 minutes, the baseline delay is 20 minutes.
This calculation assumes that most unusual delay on the selected segment is related to the entrance queue. Construction, collisions, roadside activity, weather, or congestion unrelated to the gate can violate that assumption.
2. Qualifying community timers
A community timer can be considered only when it:
- Runs for at least 2 minutes and no more than 3 hours.
- Was completed during the previous 60 minutes.
- Meets the current quality threshold.
- Is not an additional recent submission from the same anonymous client.
The estimator considers no more than 30 recent reports per entrance. Reported locations are not currently required or used by default.
Recency weighting
The community signal is a weighted median, which is less sensitive to a single extreme report than an average. Newer reports count more:
| Age of completed timer | Weight in community median |
|---|---|
| 0–15 minutes | 1.00 |
| 16–30 minutes | 0.75 |
| 31–45 minutes | 0.50 |
| 46–60 minutes | 0.25 |
3. Blending traffic and community data
Let G be the traffic-delay baseline and R be the recency-weighted median community timer.
| Distinct recent timers | Center of estimate |
|---|---|
| None | 100% traffic delay |
| 1–2 | 70% traffic delay + 30% community median |
| 3 or more | 50% traffic delay + 50% community median |
No reports: C = G
1–2 reports: C = 0.70G + 0.30R
3+ reports: C = 0.50G + 0.50R
Community reports never create a public wait estimate by themselves. A recent usable traffic observation is always required.
4. Building the displayed range
The blended center is surrounded by an uncertainty spread:
| Available community reports | Starting spread around center |
|---|---|
| None | ±8 minutes |
| 1–2 | ±6 minutes |
| 3 or more | ±4 minutes |
The spread is widened when two or more community timers disagree. It also expands when the traffic observation is more than 10 minutes old. Each of those additions is capped at 12 minutes.
The lower bound is rounded down and the upper bound is rounded up to the nearest five minutes. This is why a calculated center of 26 minutes might appear as a range such as 20–35 minutes.
5. Freshness and availability
| Observation age or status | Public treatment |
|---|---|
| 0–30 minutes during polling hours | Current |
| 31–60 minutes during polling hours | Stale warning |
| More than 60 minutes | Estimate hidden as unavailable |
| Outside daytime polling hours | Shown as the last daytime observation only while within the age limit |
| Entrance manually marked closed | Wait estimate suppressed |
The public deployment does not substitute plausible sample wait numbers when live observations are unavailable.
6. Confidence and trend labels
The confidence score describes the available supporting information; it does not alter the displayed wait. It considers traffic-data freshness, report count, agreement among reports, and the amount of recent traffic history.
The current score also includes a temporary fixed incident component. Because incident-overlap logic is not yet spatially validated, confidence labels should still be treated as experimental.
The trend label compares the newest traffic delays with older recent traffic delays. A change of at least five minutes is labeled rising or falling; smaller changes are labeled stable.
7. The planning chart is separate
The hourly planning chart is not a live forecast and does not use the current wait calculation. It starts with manually defined seasonal templates and applies broad multipliers:
- Weekday: 62% of the base pattern.
- Weekend: 100% of the base pattern.
- Holiday weekend: 125% of the base pattern.
- May through September: full seasonal pattern.
- Other months: 35% of the seasonal pattern.
Known limitations and open questions
- The fixed route may not extend far enough to capture the back of a very long queue.
- Traffic delay may include congestion unrelated to the entrance booths.
- The relationship between traffic delay and booth wait may differ between Nisqually and White River.
- Community timers are not yet location-verified.
- The current blending percentages have not been calibrated against a large field dataset.
- The uncertainty formula is a beta heuristic, not a statistical confidence interval.
- Staffing, payment methods, closures, weather, construction, and unusual events may cause abrupt errors.
- The planning chart requires historical calibration before it should be described as a forecast.
How feedback will be used
Methodology feedback is stored privately and reviewed separately from community timers. It does not automatically change a live estimate. Useful comments may inform future route changes, weighting adjustments, uncertainty rules, field-validation priorities, or documentation revisions.
Especially helpful feedback identifies a specific assumption, explains why it may be wrong, and—when possible—provides an example or an alternative calculation.