Per-region SIRI coverage scorecard

[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

Almost every number דאטאבוס publishes is really a statement about the GPS tracking
record, not about what happened on the road — so publish a standing measurement of how
complete that tracking record actually is, per operator, per region, per hour.

Background — why this matters more than it sounds

Here is the problem in one example, measured live on 2026-08-16 for the window
2026-08-01 → 08-15:

• כרמלית (operator_ref 20): 2,040 planned rides, 2,040 with no recorded
  actual. Zero rows in /siri_rides/list. It's the Haifa funicular — it simply has no
  SIRI feed.
• כפיר (operator_ref 21): 4,490 planned rides, only 3.3% with a recorded
  actual — but it does appear in /siri_rides/list, so a naive "is this operator
  in the feed?" check passes.

Feed a cancellation metric that data and כפיר becomes the worst operator in Israel. Feed
a punctuality metric that data and כרמלית has no punctuality at all. The metric isn't
wrong — the coverage is missing, and nothing currently tells the reader that.

This is why this ticket was flagged in the source material as the highest-leverage
item in the whole batch: it's not another metric, it's the thing that tells you when
the other metrics mean something.

What already exists

#1788 — a per-line view showing what fraction of planned stops got a matching GPS ping,
bucketed by hour of day. The method:

1. Take the planned stop list for a ride from /route_timetable/list
2. Take the actual GPS pings from /siri_vehicle_locations/list
3. A stop counts as covered if some ping is its nearest and falls within
   ±20 minutes of the scheduled arrival (the time gate stops a route that loops back
   near its origin from matching the wrong stop)
4. Report the covered fraction, grouped by the ride's departure hour

The hackathon reports coverage varying from below 40% to above 95% depending on line,
operator and hour — i.e. systematic tracking blackouts rather than actual service
failures (their finding, not independently verified here).

What this ticket asks for

Run that across all lines and publish it as a standing scorecard: coverage per
operator, per region, per hour.

• Add a distance ceiling to the nearest-stop match — do this first. Right now
  the match takes the nearest ping with no maximum distance, so a ping 2 km away
  still "covers" the stop. Without a ceiling every coverage number is an upper
  bound, and publishing an upper bound as a coverage figure is worse than
  publishing nothing. (For calibration, the segment-reliability work uses 150 m as
  a loose match and 300 m to drop a stop entirely.)
• Batch job, not a live query. The original full-network scan was estimated at 1–2
  hours. There is already a two-stage screen in the source work — a cheap
  ride-volume pass to find candidates, then the expensive per-stop matching — reuse it.
• Surface operators with no feed at all as a distinct category, not as 0% coverage
  (see stride-db: some operators never appear in the SIRI feed at all #1780).

The framing matters — please keep it

Copying the source material's own caveat, because it's the thing most likely to get
lost:

A bus that ran perfectly but had a broken GPS unit, or drove through a cellular dead
zone, reports 0% coverage. That is indistinguishable in the feed from a cancelled
ride.

So this is a tracking-feed quality metric, not a service reliability metric, and
the chart has to say so. Get that wrong and דאטאבוס publishes "operator X doesn't run
its buses" when the truth is "operator X has bad telematics hardware" — which is a
real and serious problem, but a completely different accusation.

Why it's worth your time

Every other metric in this milestone is downstream of this one. A coverage figure
published next to a reliability figure is what lets a reader — or a journalist, or a
regulator — know whether the reliability figure is trustworthy. It's also the piece
that turns "our data looks odd here" into an actionable, evidenced report to the
Ministry of Transport about which operators aren't meeting their reporting
obligations.

Getting started

• Skills: Python or TypeScript, basic geospatial work (point-to-point distance,
  nearest-neighbour matching). No advanced maths.
• Reference implementation:
  analyses/siri_coverage.py
  (the _ride_coverage function is the core), written up in
  algorithms/siri-coverage.md.
• Nothing blocks this — unlike the other scale-up tickets it doesn't depend on
  Pre-aggregate derived arrival times so these analyses can run interactively #1803. You can start today.
• Good first contribution that isn't the whole ticket: add the distance ceiling to
  the existing single-line view (SIRI GPS coverage of planned stops, by hour #1788) and report how much the coverage numbers move.
  That alone is a useful, self-contained result — and if they move a lot, that's worth
  knowing before anyone builds a national scorecard.
• No API key needed — the checked-in .env points at production.

Related tickets

#1788 (the single-line view this scales up) · #1780 (operators absent from SIRI) ·
#1801 (a metric currently at risk of mistaking feed gaps for cancellations) ·
#1775 (SIRI→GTFS ride matching)

---

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 כרמלית and
כפיר figures were measured live on that date; the 40%/95% coverage range is the
hackathon team's and was not independently verified.