Aggregate bunching CV into a per-line and per-region regularity score

[NoamGaash]

⚠️ AI-generated draft — needs human validation

This issue was written by an AI agent from materials produced during the
hasadna Open Bus hackathon (July 2026). The underlying analysis was built fast,
under hackathon conditions, and has not been peer-reviewed. Figures,
endpoint behaviour and conclusions all need independent verification before
anyone acts on them or quotes them publicly.

Please validate before implementing. Corrections very welcome.

The one-sentence version

On a line that runs every 8 minutes, nobody reads the timetable — they just turn up.
"Bus bunching" measures whether buses actually arrive evenly spaced or in clumps of
three followed by a 25-minute hole. That measurement exists for one line over two
days; this ticket is about running it continuously and publishing a score per line,
per corridor and per region.

Background — what bunching is, and what already exists

Why not just measure lateness. On a high-frequency urban route, passengers don't
plan around a specific departure. If two buses arrive together at minute 18 and the
next comes at minute 38, the service has failed the passenger — even though both
buses might be "on time" against some loose timetable. Headway regularity, not
punctuality, is the standard international metric for frequent transit. Israel
currently publishes nothing equivalent.

How it's measured. Take consecutive actual departures on a line, compute the gap
between each pair (the headway), and compare against the scheduled spacing:

• Bunched — actual gap < 0.25 × target headway (buses nose-to-tail)
• Gapped — actual gap > 1.75 × target headway (the hole they leave behind)
• Normal — in between

Plus an overall coefficient of variation (CV = σ/μ of the gaps): 0 is perfectly
even spacing, higher is more chaotic.

The hackathon reports >30% of headways falling into "bunched" on busy Tel Aviv routes,
immediately followed by a matching share of "gapped" — the classic bunching feedback
loop (their finding, not independently verified here).

What's already ticketed: #1790 (the single-line bunching view) and #1789 (headway
CV along the route against the CV=1 Poisson benchmark). Both are one line, up to two
days, because of API fetch cost.

What this ticket asks for

Run it continuously across all high-frequency lines and publish a regularity score
per line, per corridor, per region.

Three design constraints, all of which the single-line version gets away with ignoring
and a national rollup cannot:

• Frequency threshold. CV is meaningless on a line running twice a day. Only
  apply this above some minimum frequency, and state the threshold on the chart.
• Per-hour scheduled headway, not one pooled median. The current
  implementation uses the median scheduled headway as a single "target" for the
  whole day. A route scheduled every 8 min at rush hour and every 25 min at noon
  will have every midday gap flagged "gapped" — a pure artifact. Bucket against
  that hour's own scheduled headway.
• Measure at several points along the route, not just the origin. Bunching
  develops along a route; measuring only at the terminal misses the entire
  phenomenon it's meant to detect.

Blocked on: #1778 — the departure-time proxy is wrong

This one genuinely invalidates the metric if left alone, so it's worth understanding
before you start.

There is no "the bus departed" event in the data. The current implementation uses the
earliest GPS ping of a ride as a proxy for its departure. #1778 documents that the
feed reports a vehicle while it is still parked — so the first ping can precede
actual departure by an arbitrary amount, and the size of that lead varies between
vehicles and operators.

That's fatal here specifically, because this metric is a variance measurement. A
bimodal reporting lead (some buses ping at the kerb, some ping once moving) manufactures
variance that looks exactly like bunching. You would publish a regularity score that
is partly measuring telematics hardware.

Fix or bound #1778 first, or at minimum quantify the lead distribution and show that
it's small relative to the headways being measured.

Why it's worth your time

It's the metric that best matches how people actually experience frequent transit, and
there is no Israeli equivalent published anywhere. A per-corridor regularity score is
the kind of number that changes operational decisions — bunching is fixable with
holding strategies and headway-based dispatching, but only if somebody is measuring it.

Getting started

• Skills: Python or TypeScript, basic statistics (standard deviation, coefficient
  of variation). Nothing beyond that.
• Reference implementation:
  analyses/bus_bunching.py,
  written up in
  algorithms/bus-bunching.md
  — read its "Criticism" section, which is where the two design constraints above come
  from.
• Data: /siri_vehicle_locations/list for GPS pings. Note the existing code skips
  Fri/Sat and lags the window by 3 days so SIRI data has finished landing — keep both.
• Good first contribution that isn't the whole ticket: implement the per-hour
  scheduled headway target on the existing single-line view (Bus bunching: headway regularity against scheduled spacing #1790). It's a
  self-contained fix, it measurably improves that chart today, and it's a prerequisite
  for this one.
• No API key needed — the checked-in .env points at production.

Related tickets

#1790, #1789 (the single-line views this rolls up) · #1778 (blocker — departure proxy) ·
#1799 (sibling rollup, for segment reliability) · #1803 (pre-aggregation)

---

Credit & provenance
Found during the hasadna Open Bus hackathon, July 2026 — analysis by the hackathon team.
· Method, evidence and caveats: algorithms/upstream-issues.md
· Original work: https://github.com/hasadna/open-bus-hackathon-26
· Issue drafts and the full defect list: algorithms/upstream-issues.md

Rewritten 2026-08-16 to be readable without the hackathon materials. The bunching
percentages quoted are the hackathon team's and were not independently verified.