Construction activity dashboard

Street traffic and site activity, by the numbers.

The construction camera also powers an on-device computer-vision counter: estimated vehicle crossings on the street and at two site accesses, published as aggregates rather than identity data.


The daily pulse

Today, hour by hour.

The hour-by-hour pulse appears once the camera has logged a day of traffic.

The long run

How the traffic runs, week to week.

Stored hourly crossing buckets reveal weekday surges and longer trends. The series is sparse, however: missing coverage and observed zero are not distinguishable in the current public history, as documented below.

Methodology

From one-second frame to public count.

A fixed-camera crossing counter: vehicle detections are tracked across three calibrated lines, stored as events on the camera machine and published as aggregate time buckets.

  1. 01

    Sample

    A 960 × 540 computer-vision frame is read at about one frame per second from the same fixed camera that supplies the live stream.

  2. 02

    Detect

    In daylight, YOLOv8n looks for cars, motorcycles, buses and trucks in enlarged crops covering 106th Avenue, the west driveway and the east service road.

  3. 03

    Track and cross

    A centroid tracker associates detections between frames. A count is written only when a track crosses one of three calibrated line segments in a defined direction.

  4. 04

    Switch after dark

    Below a scene-brightness threshold, the system changes from vehicle-shape detection to moving bright-blob detection and attempts to merge a pair of headlights into one vehicle track.

  5. 05

    Aggregate

    Crossing events remain in local SQLite; roughly every three minutes the metrics service publishes aggregate totals, a trailing 60-minute count and Pacific-time hourly buckets. The metrics request contains counts, not vehicle images or identifiers.

Data dictionary

What each number counts.

Every total is a detected line-crossing event—not a unique-vehicle or occupancy count.

Definitions for the public construction-activity fields
FieldDisplay nameDefinitionUnit
entryEnteringA tracked crossing into the site through either the west driveway or the east service-road access.crossing event
exitLeavingA tracked crossing out of the site through either counted access. It is not a count of people or occupied vehicles.crossing event
streetStreet trafficA tracked passage across the calibrated 106th Avenue line. Hourly downloads combine both travel directions.vehicle pass
streetUp / streetDownDirectional street splitMovement up or down the camera frame in the latest live snapshot. These image-relative directions are not exported as cardinal compass directions.vehicle pass
lastHourLast hourA rolling 60-minute window ending at the latest camera-side aggregation, not the previous completed clock hour.crossing event
busiestHourBusiest hourThe Pacific civil-clock hour with the largest sum of street, entry and exit events so far that day.hour 0–23

Time semantics & gaps

Missing is not zero.

The live snapshot, stored hourly rows and long-run chart do not all express time in the same way.

Clock and freshness

  • Dates and hours use America/Los_Angeles local civil time. The ISO timestamp for the latest update remains UTC.
  • Today's totals and its current clock-hour bar are partial until the day or hour ends. Future hours in the 24-hour live array are display zeros, not observations.
  • At the autumn daylight-saving transition, both occurrences of the repeated local hour are combined into the same 0–23 bucket. The skipped spring hour has no observations.
  • The public CSV and JSON are cached, so a just-counted crossing can appear in the live snapshot before it appears in a download.

Coverage and zero

  • Only hourly buckets containing at least one entry, exit or street crossing are persisted to the public hourly table. An absent row therefore does not mean a verified zero.
  • For a continuous date axis, the long-run chart inserts zero-valued days between the first available date and today. A zero-height day can mean a genuinely quiet day, an unobserved day or an interrupted feed; the current dataset does not carry a coverage flag that distinguishes them.
  • The weekday-by-hour profile is also calculated from the sparse hourly rows. Missing hours can pull an average down as though they were zero, so use that view for pattern-finding rather than precise traffic engineering.
  • A numeric zero inside an exported row means no crossing of that type was recorded during a bucket that exists because another type was counted; it still is not proof that detection coverage was complete for the whole hour.

Detector history

The series changed as the counter was calibrated.

Configuration history checked August 23, 2026. These revisions are part of the evidence: an apparent change in the chart can reflect a detector change as well as a change on the street or site.

  1. Initial merged baseline

    The first repository version used YOLOv8n with ByteTrack on the full camera frame, with one lot-entrance line and one 106th Avenue line.

    Comparability: This narrow, full-frame configuration is not method-equivalent to the later cropped, three-gate detector.

    Review the code change
  2. Night mode and directional street split

    A brightness switch added moving bright-blob detection after dark, attempted to merge paired headlights, and separated street movement by image direction.

    Comparability: Day and night observations use different detectors; the night series is a rougher estimate and should not be treated as interchangeable precision.

    Review the code change
  3. Upscaled daytime crop and centroid tracking

    Daylight detection moved to an enlarged road crop and a centroid tracker because small, fast vehicles were being missed or losing track identity at the one-frame-per-second sample rate.

    Comparability: This is a material method break: counts before and after the change should not be read as a clean trend without acknowledging the detector revision.

    Review the code change
  4. Current three-gate layout

    The detector added separate west-driveway, east-service-road and 106th Avenue line segments, with two daylight crops and common entry/exit aggregation across both site accesses.

    Comparability: Gate coordinates and crop calibration are tied to the present fixed view. A camera move, zoom or reframing would create another method break and require recalibration.

    Review the code change

Detector limitations

Useful signal, bounded precision.

Crossings, not unique vehicles

A vehicle that leaves and returns can be counted more than once. The aggregates cannot measure unique vehicles, occupancy, dwell time, people or material quantities.

One oblique view

Trees, fencing, parked equipment, other vehicles and the edges of the two detection crops can hide or partially obscure a crossing.

Low sampling rate

At about one frame per second, small or fast vehicles can move a long distance between samples. Tracks can be lost, joined to the wrong detection or split into more than one track.

Night is a different detector

Rain, reflections, work lights, headlight glare and closely spaced vehicles can merge, split or hide bright blobs. Night counts are materially rougher than daylight counts.

Calibration can drift

The three crossing lines are pixel coordinates tied to this exact crop and angle. Any camera movement, zoom or framing change requires recalibration before the series is comparable again.

Not an official survey

The counter is an independent observational estimate. It is not Bellevue traffic-count data and should not be used alone for safety, permitting or engineering decisions.

Open data

Download the sparse hourly record.

Each file contains the stored non-zero hourly buckets since the pipeline came online. Neither format supplies a complete hourly coverage grid, so retain the missing-data caveat when analysing it.

Compare the numbers with the construction cam →