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. Our platform measures the first precisely and estimates 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 | |
|---|---|---|
| observed | Counts | One person crossing one counter, once. Exact and auditable: what the sensors recorded, after on-device classification. |
| estimated | Visits | Counts at a site after merging overlapping sensors. Two counters watching the same spot don't get to count the same person twice. |
| modeled | 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 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 data validation 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 estimated, dashed and banded, so observed data stays pristine.
From counts to visits¶
Where several counters watch the same site, their fields of view overlap. In every 15-minute window we merge each overlapping group down to the member that saw the most complete picture of that window, so no person is double-counted. That is a deliberately conservative floor on the true number of distinct passes. Merging follows the counters' actual positions on each day (positions are versioned, so corrections recompute history), and an in-field data validation study measures how close the floor sits to hand-counted truth. This is why "Visits" on your dashboard is labeled estimated. How counters are arranged inside a site decides which of them merge: see Counter placement strategies.
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 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 observed 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 data validation study underway upgrades them to formal intervals once coverage is measured. |
| Every number carries its tier: observed, estimated, or modeled | You always know exactly what kind of figure you're quoting. |
This page is the specification for the platform: every figure is built to match it, and that rule is written into our engineering process.