How we count¶
Trail counting starts with a subtle distinction: a counter measures crossings at a point, while managers want trips on a trail. Those are different quantities, and our platform is built around measuring the first precisely and estimating the second rigorously.
This page is the method behind every number on our platform. It is public on purpose: when a council member, grant reviewer, or auditor asks where your number came from, you can show them exactly how it was made.
Three kinds of numbers¶
We publish three tiers. Each is labeled on every surface of the platform, and each answers a different question.
| Tier | What it is | |
|---|---|---|
| measured | Counts | One person crossing one counter, once. Exact and auditable — what the sensors actually recorded, after on-device classification. |
| estimated | Visits | Counts at a site after merging overlapping sensors, shown as a range. Two counters watching the same spot don't get to count the same person twice. |
| modeled | Estimated trips | Whole-trail journeys, estimated by a published model with a stated uncertainty band. |
Ride past three counters on one ride and you are three counts but one trip. Publishing summed counts as "trips" or "users" double-counts every journey that crosses more than one monitored point — and worse, the total jumps every time a counter is added, with nothing changing on the trail.
The design rule that protects every number¶
A metric is never defined as "add up whatever sensors we happen to have." The quantity being estimated is defined independently of the sensor set; sensors are observations of it.
Under this rule, adding a counter can only sharpen an estimate — a narrower range, finer spatial detail. It can never inflate it. That is the difference between our numbers and summed-counter totals: our totals don't grow because our fleet did.
Engineered around the sensor's physics¶
Like every measurement instrument, a radar counter has known physical properties. We document them and design the network around them:
- Busy moments. A tight group can register as fewer crossings than people. Where counters overlap we recover part of this automatically, and an ongoing ground-truth study — manual counts run side-by-side with the sensors — is quantifying the rest.
- A minimum-speed floor. Very slow or stationary passers-by fall below the radar's detection threshold. Because the floor is consistent network-wide, trends and comparisons stay valid.
- Transparent uptime. If a counter was offline, the gap is visible in your data. Where the model fills a gap for display, it is drawn as modeled — dashed and banded — so measured data stays pristine.
From counts to visits¶
Where several counters watch the same site, their fields of view overlap. The true number of distinct passes lies between the largest single counter's total (as if all overlap were perfect) and the sum of all of them (as if there were no overlap at all). We publish that range — never a point value where sensors overlap. This is why "Visits" on your dashboard is labeled estimated.
From visits to trips¶
Trail-level questions — "how many trips this season?", "how many person-miles?" — need a model, and we publish it as one.
We model the trail network as a graph and estimate the flow on each segment: people per hour, by mode. Each counter is an observation of the flow on its segment; the model carries flow across unmonitored segments and states how much of the network is actually observed. Person-miles fall out directly (flow × segment length); trips are person-miles divided by average trip length, published as a band across the plausible range of trip lengths rather than a false-precision point.
Because the quantity is defined on the trail, not on the sensor set, this estimate has the same property as everything else here: more counters mean a narrower band, not a bigger number.
This is the same family of method as the FHWA Traffic Monitoring Guide's bicycle/pedestrian program — permanent counters plus modeled expansion — with one difference: our expansion factors are learned from your network's own data, and the whole chain is published. The engineering detail lives in The Usage Model.
The standard every figure meets¶
| Our standard | What it gives you |
|---|---|
| Figures name what they count — crossings, visits, or trips | No inflated "user" totals to walk back later; each term maps to a defined, published quantity. |
| Annual figures come from a full year of measured history | A trailing-twelve-month total you can put in a grant application without an asterisk. |
| Ranges are validated before they become confidence intervals | Bands are labeled as typical model miss today; a ground-truth study underway upgrades them to formal intervals once coverage is measured. |
| Every number carries its tier — measured, estimated, or modeled | You always know exactly what kind of figure you're quoting. Always. |
This page is the specification for the platform: every figure is built to match it, and that rule is written into our engineering process.