BRouter onboarding: detect, install, and check segment coverage

## Goal Make the out-of-box enrichment path a good one. Right now it is the worst one. BRouter needs a separate install **and** region segment files. D13 makes online enrichment opt-in, default off. So a new user's default is tier 3, the geometric heuristic - which fires on every curve, roundabout and switchback while staying silent at junctions where the rider continues straight. The most common first experience of the app was its worst one, and nothing owned fixing that. "Prompt the user to install BRouter with a link" was the whole mitigation. That is not enough: installing BRouter does not mean BRouter can route where you are. ## Acceptance criteria - [ ] Detect whether BRouter is installed, by attempting the AIDL bind rather than by package name alone - [ ] If absent: a clear explanation of what BRouter is and why it is wanted, with a deep link to install it - [ ] **Segment coverage checked against the imported route's bounding box** - "installed" is not "can route here" - [ ] Missing segments named specifically (which `.rd5` tiles, for which area) with a link to the download - [ ] Coverage re-checked per import, not once at setup - [ ] Enrichment tier actually used is shown on the route in the library, not hidden - [ ] A route enriched at tier 3 is visibly marked as guessed, both in the library and in the cue-sheet review (#55) - [ ] Declining BRouter entirely is a supported path, not a dead end - the app keeps working at tier 0 or 3 - [ ] No nagging: the prompt is per-route-that-needs-it, and dismissible for good ## Files - `companion/.../route/enrich/BRouterAvailability.kt` - `companion/.../route/enrich/BRouterEnricher.kt` - `companion/.../route/import/` ## Notes See D27. Related tightening of the geometric fallback lives in #29. ## Update — 2026-09-02: reduced to a nudge on the komoot path **bikerouter.de is BRouter's own web front end and exports GPX with turn instructions** (D40). So BRouter-quality cues are reachable with no BRouter install, no segment-file download, no network at import and no privacy question — via tier 0 (#63). That changes what this issue is for. The out-of-box path is no longer "the worst enricher"; it is "plan somewhere that emits cues", which the new route-source guidance issue covers. - [ ] The install prompt drops to a **nudge**, shown only on the komoot path where cues genuinely are absent, and only when BRouter would actually help - [ ] **Keep the segment-coverage check** against the imported route's bounding box — that is the part that distinguishes "BRouter is installed" from "BRouter can route here", and nothing else does it - [ ] Keep: enrichment tier shown on the route in the library, tier-3 routes visibly marked as guessed, declining BRouter remaining a supported path, and no nagging - [ ] The explanation now names tier 0 first: the cheapest fix is to plan the next route somewhere that exports cues

robert commented

2026-09-01 17:35:44 +02:00

(Migrated from git.butzei.de)

Goal

Make the out-of-box enrichment path a good one. Right now it is the worst one.

BRouter needs a separate install and region segment files. D13 makes online enrichment opt-in, default off. So a new user's default is tier 3, the geometric heuristic - which fires on every curve, roundabout and switchback while staying silent at junctions where the rider continues straight. The most common first experience of the app was its worst one, and nothing owned fixing that.

"Prompt the user to install BRouter with a link" was the whole mitigation. That is not enough: installing BRouter does not mean BRouter can route where you are.

Acceptance criteria

Detect whether BRouter is installed, by attempting the AIDL bind rather than by package name alone
If absent: a clear explanation of what BRouter is and why it is wanted, with a deep link to install it
Segment coverage checked against the imported route's bounding box - "installed" is not "can route here"
Missing segments named specifically (which .rd5 tiles, for which area) with a link to the download
Coverage re-checked per import, not once at setup
Enrichment tier actually used is shown on the route in the library, not hidden
A route enriched at tier 3 is visibly marked as guessed, both in the library and in the cue-sheet review (#55)
Declining BRouter entirely is a supported path, not a dead end - the app keeps working at tier 0 or 3
No nagging: the prompt is per-route-that-needs-it, and dismissible for good

Files

companion/.../route/enrich/BRouterAvailability.kt
companion/.../route/enrich/BRouterEnricher.kt
companion/.../route/import/

Notes

See D27. Related tightening of the geometric fallback lives in #29.

Update — 2026-09-02: reduced to a nudge on the komoot path

bikerouter.de is BRouter's own web front end and exports GPX with turn instructions (D40). So
BRouter-quality cues are reachable with no BRouter install, no segment-file download, no network at
import and no privacy question — via tier 0 (#63).

That changes what this issue is for. The out-of-box path is no longer "the worst enricher"; it is
"plan somewhere that emits cues", which the new route-source guidance issue covers.

The install prompt drops to a nudge, shown only on the komoot path where cues genuinely are
absent, and only when BRouter would actually help
Keep the segment-coverage check against the imported route's bounding box — that is the part
that distinguishes "BRouter is installed" from "BRouter can route here", and nothing else does it
Keep: enrichment tier shown on the route in the library, tier-3 routes visibly marked as
guessed, declining BRouter remaining a supported path, and no nagging
The explanation now names tier 0 first: the cheapest fix is to plan the next route somewhere
that exports cues

Rows
Columns

BRouter onboarding: detect, install, and check segment coverage #64

Goal

Acceptance criteria

Files

Notes

Update — 2026-09-02: reduced to a nudge on the komoot path