gabogg/hikcentral
Watch
1
0
Fork
You've already forked hikcentral
 0
Code Issues 113 Pull requests 8 Projects Releases Packages Wiki Activity Actions

feat(analytics): per-entrance breakdown for a statistics period #86

New issue
Closed
opened 2026-09-24 23:23:41 +00:00 by gabogg · 1 comment
gabogg commented 2026-09-24 23:23:41 +00:00
Owner
Copy link

Route

GET /api/statistics/periods/{granularity}/{start}/entrances

One row per counted camera: visitors (IN), OUT, share of period visitors, and change vs the previous period; change vs the same period last year is added only when last year has data.

Used by

Entrance share graphs in all three periods.

Notes

  • Per-camera figures for a multi-camera group are estimates (ADR 0005, Camera Group States); the response must say so.
  • Cameras added or removed within the comparison window need a defined rule (compare only cameras present in both periods, or flag new ones).

Context

Part of the statistics deck redesign, draft RFC in #80 (docs/architecture/rfc-statistics-deck-display-model.md; mockup linked there). Period selection was decided in #81 (closed): a period is identified by granularity (day / week / month) and its first business day; see the glossary terms Complete Period and Partial Period. A year period is out of scope.

Shared constraints (all statistics-deck routes)

  • Periods are closed business periods in facility time (daily_reset_time boundaries, app/facility_time.py); an in-progress cycle is never returned.
  • Only counted cameras contribute (_COUNTED_CAMERA_JOIN / _COUNTED_CAMERA_FILTER); quarantined events never do.
  • Every period-level figure carries its data quality: gap-estimated days (ingestion anomaly ledger), Data Trust and Cycle Completeness for the cycles involved, so the deck can mark estimates.
  • Dwell means the open-window Mean Dwell (ADR 0006), not the retired definitions.
  • Access: any logged-in user, read-only (require_auth). Deck routes live in a separate /api/statistics/ router so admin-only /api/analytics/ routes can't leak into the deck.
  • Controllers stay thin; aggregation lives in analytics_service, SQL in repositories.

Triage decisions (2026-09-24)

  • Route: GET /api/statistics/periods/{granularity}/{start}/entrances.
  • Share always uses every counted camera in the current period.
  • Change figures only for cameras present in both periods; a camera new in this period is marked NEW with no change; a camera that disappeared is not listed.
## Route `GET /api/statistics/periods/{granularity}/{start}/entrances` One row per counted camera: visitors (IN), OUT, share of period visitors, and change vs the previous period; change vs the same period last year is added only when last year has data. ## Used by Entrance share graphs in all three periods. ## Notes - Per-camera figures for a multi-camera group are estimates (ADR 0005, Camera Group States); the response must say so. - Cameras added or removed within the comparison window need a defined rule (compare only cameras present in both periods, or flag new ones). ## Context Part of the statistics deck redesign, draft RFC in #80 (`docs/architecture/rfc-statistics-deck-display-model.md`; mockup linked there). Period selection was decided in #81 (closed): a period is identified by `granularity` (`day` / `week` / `month`) and its first business day; see the glossary terms **Complete Period** and **Partial Period**. A year period is out of scope. ## Shared constraints (all statistics-deck routes) - Periods are **closed** business periods in facility time (`daily_reset_time` boundaries, `app/facility_time.py`); an in-progress cycle is never returned. - Only **counted cameras** contribute (`_COUNTED_CAMERA_JOIN` / `_COUNTED_CAMERA_FILTER`); quarantined events never do. - Every period-level figure carries its data quality: gap-estimated days (ingestion anomaly ledger), **Data Trust** and **Cycle Completeness** for the cycles involved, so the deck can mark estimates. - Dwell means the open-window **Mean Dwell** (ADR 0006), not the retired definitions. - Access: any logged-in user, read-only (`require_auth`). Deck routes live in a separate `/api/statistics/` router so admin-only `/api/analytics/` routes can't leak into the deck. - Controllers stay thin; aggregation lives in `analytics_service`, SQL in repositories. ## Triage decisions (2026-09-24) - Route: `GET /api/statistics/periods/{granularity}/{start}/entrances`. - Share always uses every counted camera in the current period. - Change figures only for cameras present in both periods; a camera new in this period is marked `NEW` with no change; a camera that disappeared is not listed.
gabogg commented 2026-09-25 17:09:07 +00:00
Author
Owner
Copy link

Implemented by #92, merged into master as cf20ef2 after two review passes (Standards + Spec). Non-blocking follow-ups are tracked in #96–#100. Closing; this unblocks #80.

🤖 Generated with Claude Code

Implemented by #92, merged into `master` as cf20ef2 after two review passes (Standards + Spec). Non-blocking follow-ups are tracked in #96–#100. Closing; this unblocks #80. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
feat/historical-flow-statistics
feat/historical-flow-publication
docs/test-policy-217
feat/historical-flow-curation
fix/holiday-stamping-followups
chore/schedule-p3-followups-186
fix/test-isolation
test/silent-camera-trace-199
No results found.
Labels
Clear labels   
blocked
Waits on the issues listed in its "Blocked by:" line before implementation

  
bug
Category: something is broken; behaviour differs from the spec or docs

  
enhancement
Category: new feature or improvement, including refactors, chores and docs

  
high-priority
Address before ordinary-priority work; independent of triage readiness and blockers

  
low-priority
Address after ordinary-priority work; independent of triage readiness and blockers

  
needs-info
Waiting on reporter for more information

  
needs-triage
Maintainer needs to evaluate this issue

  
ready-for-agent
Fully specified, ready for an AFK agent

  
ready-for-human
Requires human implementation

  
referenced
Previously closed issue reopened or referenced by an open issue; visible history marker

  
research
Needs investigation (internet or local resources) before it can be triaged down; used alongside a category and a triage role

  
wontfix
Will not be actioned

No labels
blocked
bug
enhancement
high-priority
low-priority
needs-info
needs-triage
ready-for-agent
ready-for-human
referenced
research
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gabogg/hikcentral#86
No description provided.