Skip to content

The usage model

The engineering deep-dive behind How We Count, for planners and engineers who want the estimator, not the summary.

Sensing

Counters are solar-powered 24 GHz mmWave radar units with LTE backhaul. On-device processing tracks targets across the sensor's field of view and classifies each crossing by mode (cyclist / pedestrian) and direction from its speed and trajectory. Sensor characteristics — simultaneous-target ceiling, occlusion during bunched arrivals, a minimum-speed floor — are documented per sensor and carried through the estimators as measurement properties.

Site de-duplication (visits)

Counters at a site are clustered by position. Overlapping counters bound the true number of distinct passes: the cluster maximum (total overlap) and sum (zero overlap) form the published [max, sum] range for visits. No behavioral assumptions, no model — just interval arithmetic on the overlap structure, which is why visits are estimated but not modeled.

The flow field (person-miles and trips)

The trail network is a graph (segments × junctions/access points). The estimand is the flow λ(segment, time): people per hour by mode. Counters observe λ on their segments; connected trail components carry observed flow across unmonitored segments (reference-count expansion, FHWA TMG family), with disconnected spurs excluded from the carried flow rather than guessed.

  • Person-miles traveled = Σ λ(e, t) · length(e), published as a [low, point, high] range: low counts only miles both near and connected to a counter; high applies pre-deduplication flow to all corridor miles.
  • Trips = PMT ÷ mean trip length, published across a 3–8 mile trip-length band. The unknown origin–destination structure is deliberately reduced to this one interpretable, sensitivity-testable parameter. An intercept survey (planned) pins the per-network mean and narrows the band.

Coverage is reported alongside: monitored share of trail-miles and counter spacing versus typical trip length. There is no "critical mass" moment — there is a coverage → uncertainty curve, and adding a counter moves you along it.

The behavioral model (patterns, weather, outlook)

Every behavioral statement on the platform — weekend lift, weather response, growth, the 7-day outlook — comes from one model, fit per site:

  • Ridge-regularized log-linear regression of daily counts on day-of-week, temperature (quadratic), rain, and a linear time trend.
  • A log(active-counters) exposure offset so fleet growth cannot masquerade as demand — the guard against the classic aggregation error where installing counters in summer "proves" heat increases usage.
  • The trend term absorbs secular growth (near-collinear with season in the first year); forecasts carry the current level forward and never extrapolate the growth rate.
  • Uncertainty bands are empirical residual quantiles (10th–90th): "typical model miss," not confidence intervals — CI language waits for measured coverage against ground truth.
  • Network-level effects are volume-weighted blends of per-site models, never a fit over summed counts (Simpson's-paradox guard).

Our engineering rules reserve client surfaces for this per-site model: descriptive statistics over raw fleet-summed counts would measure the installation schedule rather than behavior, so every behavioral figure is model-derived.

Validation, current and planned

  • Ground-truth study (in progress): independent manual counting alongside the sensors, contracted to an outside counter. Produces detection-rate bounds and validates the visit ranges — the gate for any future confidence-interval language.
  • Cross-validation against municipal reference counters where a city publishes its own counts near ours.
  • Intercept survey to measure mean trip length directly.
  • The estimators are versioned; when a method changes tier (e.g. trips moving from modeled band to survey-calibrated), this page changes with it.

For access to the underlying data, see Data & API Access.