Segments Phase 3: detection algorithm, CLI, ingest hook, and efforts API

- detect.py: ActivityTrack + detect_one/detect_all (bbox pre-filter →
  start/end proximity 25m → path conformance 50m/30% → effort extraction
  with avg speed/HR/power and Coggan NP)
- cli.py: `bincio segments detect` for retroactive detection over stored
  timeseries JSONs, with optional --activity-id / --segment-id filters
- ingest.py: non-fatal hook at end of ingest_parsed runs detect_all
- server.py: GET /api/segments/{id}/efforts and POST /api/segments/{id}/detect
This commit is contained in:
Davide Scaini
2026-05-13 00:50:39 +02:00
parent 61db0734d2
commit 4d2df860ce
6 changed files with 673 additions and 0 deletions
+189
View File
@@ -0,0 +1,189 @@
# Bincio Segments — Design Plan
## Overview
Segments are named GPS stretches that can be defined by any user. Every time an activity passes through a segment, an "effort" is recorded automatically. Users can track their personal history and PRs on each segment.
---
## Data Model
### Segment (global, shared)
File: `/var/bincio/segments/{segment-id}.json`
```json
{
"id": "climb-to-passo-rolle-a3f2",
"name": "Climb to Passo Rolle",
"sport": "cycling",
"polyline": [[46.123, 11.456], [46.124, 11.457], "..."],
"distance_m": 4320.5,
"bbox": [11.456, 46.120, 11.502, 46.135],
"created_by": "brut",
"created_at": "2026-05-13T10:00:00Z"
}
```
Segment ID: slugified name + 4-char hash to avoid collisions.
### SegmentEffort (per user)
File: `/var/bincio/data/{handle}/segment_efforts/{segment-id}.json`
Array of efforts, newest first:
```json
[
{
"activity_id": "2026-04-26T053013Z-ccbas-...",
"started_at": "2026-04-26T06:12:33Z",
"elapsed_s": 1842,
"avg_speed_kmh": 12.4,
"avg_hr_bpm": 158,
"avg_power_w": 245,
"np_power_w": 261,
"detected_at": "2026-05-13T10:05:00Z"
}
]
```
---
## Detection Algorithm
**Input:** activity GPS track (lat/lon, ~1 Hz), segment polyline
**Steps:**
1. **Bbox pre-filter** — skip if activity bbox doesn't overlap segment bbox (padded by ~50 m). O(1) per segment.
2. **Start proximity** — find all activity points within 25 m of `polyline[0]`. Each is a candidate entry point.
3. **End proximity** — from each candidate entry, scan forward (never backward) for an activity point within 25 m of `polyline[-1]`. Enforces correct direction.
4. **Path conformance** — between entry and exit indices, project each activity point onto the nearest segment polyline segment and compute perpendicular distance. If more than 30% of points exceed 50 m deviation, reject the match. Configurable thresholds.
5. **Effort extraction** — from the matched entry/exit indices, slice the timeseries and compute `elapsed_s` and avg metrics.
6. **Multiple efforts** — after a successful match, continue scanning from the exit point to detect repeat efforts in the same activity (e.g. repeat climbs).
**Configurable constants** (easy to tune):
- `MATCH_RADIUS_M = 25` — proximity to start/end points
- `CONFORMANCE_MAX_DEVIATION_M = 50` — max perpendicular distance
- `CONFORMANCE_MAX_FRACTION = 0.30` — fraction of points allowed to exceed max deviation
---
## Server-side Code Structure
```
bincio/segments/
__init__.py
models.py — Segment, SegmentEffort dataclasses
store.py — read/write segments and efforts to/from /var/bincio
detect.py — matching algorithm
cli.py — bincio segments detect [--activity X] [--segment Y] [--user U] [--all]
```
Detection is called:
- **At ingest time** — after each new activity is processed, reads all segment definitions (bbox pre-filter makes this fast), writes matches to the user's `segment_efforts/`
- **Retroactively** — via CLI or API endpoint, for one user re-running all activities against all (or one) segment(s)
---
## API Endpoints
All new, added to `server.py`:
```
GET /api/segments?bbox=lon_min,lat_min,lon_max,lat_max list segments in viewport
POST /api/segments create segment (auth required)
DELETE /api/segments/{id} delete (created_by or admin only)
GET /api/segments/{id}/efforts current user's efforts (auth)
POST /api/segments/{id}/detect retrigger detection for current user
```
Bbox filtering is done in memory at request time. All segment definitions are read from disk on startup (or lazily cached). Works fine for hundreds of segments.
---
## Frontend
### New pages / routes
| Route | Purpose |
|---|---|
| `/segments/` | Map + list of all segments; entry point for browsing and creating |
| `/segments/new/` | Segment creation flow |
| `/segments/{id}/` | Segment detail: polyline on map + user's effort history |
### `/segments/` page
- Full-width map showing segment polylines for segments whose bbox overlaps the current map viewport
- Segment list below (or sidebar): name, sport, distance, creator
- "New segment" button → `/segments/new/`
- Clicking a segment → `/segments/{id}/`
### `/segments/new/` — creation flow
1. Searchable list of the user's own activities with GPS → select one
2. Activity track shown on map
3. Dual-handle range slider below the map, one position per GPS point in the track
- Moving handles highlights the selected portion on the map in a contrasting colour
- Start and end coordinates are the GPS points at the slider handle positions
4. Name input + optional sport selector
5. Confirm → `POST /api/segments`
### `/segments/{id}/` — segment detail
- Segment polyline on map
- Metadata: name, sport, distance, created by
- Effort history table (sorted by date, newest first):
- Date, elapsed time, avg speed, avg HR, avg power, NP
- Delta vs. personal best highlighted
- "Retrigger detection" button → `POST /api/segments/{id}/detect`
### Activity detail page (existing)
Below the stats table: if any segment efforts were detected for this activity, show a compact list — segment name + elapsed time + Δ vs. PR.
### Athlete page (existing)
New "Segments" section: list of segments the user has efforts on, showing best time and effort count for each.
---
## Segment Creation UX (refined)
Standalone `/segments/new/` page with an activity picker. Additionally, the activity detail page gets a **"Create segment from this activity"** button that links to `/segments/new/?activity={id}`, pre-selecting the activity and skipping the picker step.
Rationale: users will typically think "I want to turn this climb I just did into a segment" — the shortcut from activity detail makes that fast, while the standalone page remains the canonical entry point for discovery.
---
## Implementation Strategy
UI-first, so users can start populating the segment collection immediately. Detection comes after.
**Phase 1 — Minimal backend to unblock UI**
1. `bincio/segments/models.py` — Segment and SegmentEffort dataclasses ✅
2. `bincio/segments/store.py` — read/write segments to/from disk ✅
3. `POST /api/segments` + `GET /api/segments?bbox=...` + `DELETE /api/segments/{id}`
**Phase 2 — Creation UI**
4. `/segments/new/` page — activity picker → map + dual-handle slider → name/save ✅
5. `/segments/` page — map + list of existing segments, bbox-filtered ✅
6. Activity detail — "Create segment from this activity" shortcut button ✅
**Phase 3 — Detection**
7. `bincio/segments/detect.py` — matching algorithm, tested in isolation ✅
8. `bincio/segments/cli.py` — retroactive detection CLI (`bincio segments detect`) ✅
9. Ingest hook — run detection at end of each ingest ✅
10. `POST /api/segments/{id}/detect` + `GET /api/segments/{id}/efforts`
**Phase 4 — Display** (next)
11. `/segments/{id}/` page — segment detail + effort history table
12. Activity detail — show matched segment efforts below stats
13. Athlete page — segments section