Wellington Counter Methodology

Three cities, two sensor types

Christchurch and Auckland use inductive loop or pneumatic tube counters — a sensor buried in or strung across the path that fires once each time a wheel rolls over it. One cyclist crossing one sensor: one count.

Wellington uses VivaCity video sensors — cameras mounted above the road that use computer vision to detect and classify road users. Rather than a physical trigger, operators configure virtual lines in the camera software called countlines. Any object that crosses a countline in the right mode (Cyclist, Pedestrian, etc.) is recorded.

The video approach is more flexible — a single camera can monitor multiple lanes, paths, and directions simultaneously. That flexibility is also where the data gets complicated.

What is a countline?

A countline is a virtual line drawn across the camera's view. Picture a stripe painted across the road — any cyclist who crosses it gets counted, tagged with the direction they were travelling.

  Camera view (top-down)
  ─────────────────────────────────
  │                               │
  │    cyclist →  × ─────────── │  ← countline A (E/W orientation)
  │                               │
  │               │               │
  │               │               │  ← countline B (N/S orientation)
  │               ↓               │
  │            cyclist            │
  ─────────────────────────────────
  Countline A catches east-west cyclists.
  Countline B catches north-south cyclists.
  One camera. Two independent counts. Both correct.

At an intersection or shared path, a camera might have two or three countlines like this, each oriented to catch a different direction of travel. That is the intended use and the data is clean.

Problem 1: parallel countlines at the same camera

The first issue arises when a camera has multiple countlines oriented in the same direction, drawn close together. A cyclist moving north through the frame crosses all of them in quick succession — and each crossing is recorded as a separate count.

  Camera view — Cuba Street, Te Aro (simplified)
  ─────────────────────────────────
  │           ↑ cyclist           │
  │    ─────── × ──────  line 1  │  count: 1
  │    ─────── × ──────  line 2  │  count: 1  ← same cyclist
  │    ─────── × ──────  line 3  │  count: 1  ← same cyclist
  │                               │
  ─────────────────────────────────
  Reported: 3 cyclists.  Actual: 1.

WCC's raw Wellington feed exposes 397 active countlines across the city — versus 83 for Auckland and 37 for Christchurch. One camera at Cuba Street had nine countlines within a 21 m × 9 m patch, of which five captured north-south cyclists. Those five lines were all close together and roughly parallel, so a single northbound cyclist registered as five separate counts at that one camera location.

What we do about it: geometric deduplication

Each countline in the WCC data has a geometry — the actual coordinates of the line projected onto the map. That geometry encodes a bearing angle: a countline drawn east-west across the road sits at roughly 90°; north-south at roughly 0°.

Two countlines with similar bearing angles at the same physical location are likely measuring the same cyclist flow. We apply a conservative rule:

The thresholds (20 m, 20°) are deliberately conservative. At Luxford Street, three countlines sit within 15 m of each other at bearings 127.5°, 0°, and 63.4° — all more than 20° apart, capturing genuinely different directions of travel. The algorithm keeps all three. At Cuba Street, the nine countlines collapse to four canonical ones.

Being conservative means some parallel countlines that should ideally be merged survive because their bearings differ by 21–24° — just outside the threshold. We accept this: it is better to count a handful of things twice than to discard genuine cycling activity. After deduplication, 397 countlines reduce to roughly 209 canonical sensors.

Problem 2: sensor density

Deduplication fixes the within-camera inflation, but it does not fix a deeper structural difference: Wellington has far more camera locations per kilometre of cycling route than Auckland or Christchurch. A Wellington commuter cycling through Te Aro might pass eight or ten distinct camera locations on a single trip. Each one adds to the day's count.

The advocacy metrics on this site — fuel saved, CO₂ avoided, flat whites — all rest on the NZTA finding that 35% of counted rides replace a car trip. That figure was calibrated on trip counts, not sensor crossings. When a single cyclist trip generates ten sensor crossings, applying 35% to the raw count claims that trip replaced 3.5 cars. It didn't.

The City Leaderboard normalises by population (rides per 1,000 residents), which partially accounts for sensor density differences. It is a better basis for cross-city comparison than raw totals, but it is not a complete correction.

What changed in the data

In April 2026 we applied a retrospective correction to all historical Wellington data: counts from deduplicated countlines were removed, and daily totals were recomputed. All new data is processed with deduplication applied before it enters the database.

After correction, Wellington's monthly totals roughly halved. The remaining sensor-density difference means the numbers are still on the high side relative to a comparable loop-counter deployment — but the most obvious counting errors have been removed.

Remaining limitations

• Deduplication is geometry-based, not ground-truth verified. A small number of countlines may be incorrectly included or excluded at complex junctions.
• Sensor density differences between cities mean Wellington's absolute impact figures are not directly comparable to Auckland or Christchurch.
• The WCC feed does not include a canonical site ID linking countlines to their parent camera. If WCC publishes this in a future data release, deduplication could be made exact rather than geometric.
• A full correction would require knowing how many sensor locations a typical Wellington cyclist crosses per trip — data that is not currently available.