docs(backlog): plan almanac-driven satellite selection (022a/b/c) #37

Closed
ykp wants to merge 1 commit from docs/almanac-plan into main
Owner

Backlog plan for the almanac-loader feature ("realistic satellite choices from existing realistic values", follow-up to 021). Three work orders, dependencies and acceptance criteria per the backlog conventions:

  • 022a — core (022a-almanac-core.md): Yuma + SEM parsers, visibility computation (observer lat/lon/epoch/min-elevation), JSON interchange format, nominal-registry fallback, cached fetch with retries. Stdlib only, no new dependencies.
  • 022b — CLI (022b-almanac-cli.md): gengnss almanac subcommand (table / --json / --save), --visible flag on run/show that resolves the visible set at run time and freezes it in the sidecar so regeneration stays bit-reproducible even when the live constellation changes.
  • 022c — GUI (022c-almanac-gui.md): "Load almanac…" dialog (background-thread fetch, file import with content sniffing, position filter, apply-to-system) pre-checking the 021 satellite palettes with healthy/visible satellites.

Scope verified against live data (2026-09-29)

  • CelesTrak Yuma and SEM almanacs fetched and inspected live (week 390) — the only machine-readable public GNSS almanacs; they carry GPS only (PRN, health, elements).
  • GLONASS: RSA IAC constellation-status page is JavaScript-rendered behind an authenticated API — no public machine-readable almanac. Plan: JSON interchange format + the nominal 24-slot registry table as fallback; a scraper is explicitly out of scope.
  • Galileo/BeiDou: no public open-service almanac with PRN↔SV mappings — the 021 ICD ranges remain their source of truth; documented as out of scope.

Tests are network-free by design (fixtures embedded in the test files, fetch monkeypatched); CI stays green without live-network dependencies.

Execution order: 022a first, then 022b and 022c (may run in parallel). docs/backlog/000-overview.md index rows + a "v1.2 — almanac-driven selection" section added.

Backlog plan for the almanac-loader feature ("realistic satellite choices from existing realistic values", follow-up to 021). Three work orders, dependencies and acceptance criteria per the backlog conventions: - **022a — core** (`022a-almanac-core.md`): Yuma + SEM parsers, visibility computation (observer lat/lon/epoch/min-elevation), JSON interchange format, nominal-registry fallback, cached fetch with retries. Stdlib only, no new dependencies. - **022b — CLI** (`022b-almanac-cli.md`): `gengnss almanac` subcommand (table / `--json` / `--save`), `--visible` flag on `run`/`show` that resolves the visible set at run time and **freezes it in the sidecar** so regeneration stays bit-reproducible even when the live constellation changes. - **022c — GUI** (`022c-almanac-gui.md`): "Load almanac…" dialog (background-thread fetch, file import with content sniffing, position filter, apply-to-system) pre-checking the 021 satellite palettes with healthy/visible satellites. ## Scope verified against live data (2026-09-29) - CelesTrak **Yuma** and **SEM** almanacs fetched and inspected live (week 390) — the only machine-readable public GNSS almanacs; they carry GPS only (PRN, health, elements). - **GLONASS**: RSA IAC constellation-status page is JavaScript-rendered behind an authenticated API — no public machine-readable almanac. Plan: JSON interchange format + the nominal 24-slot registry table as fallback; a scraper is explicitly out of scope. - **Galileo/BeiDou**: no public open-service almanac with PRN↔SV mappings — the 021 ICD ranges remain their source of truth; documented as out of scope. Tests are network-free by design (fixtures embedded in the test files, fetch monkeypatched); CI stays green without live-network dependencies. Execution order: 022a first, then 022b and 022c (may run in parallel). `docs/backlog/000-overview.md` index rows + a "v1.2 — almanac-driven selection" section added.
docs(backlog): plan almanac-driven satellite selection (022a/b/c)
All checks were successful
ci / test (3.12) (push) Successful in 1m56s
ci / test (3.14) (push) Successful in 2m36s
ci / test (3.9) (push) Successful in 2m14s
ci / test (3.12) (pull_request) Successful in 2m52s
ci / test (3.14) (pull_request) Successful in 2m56s
ci / test (3.9) (pull_request) Successful in 3m28s
85398b5304
Three-step plan for "realistic satellite choices" from live almanacs,
following the user's earlier request. Scope verified against live data
2026-09-29:

- 022a (core): Yuma + SEM parsers (both fetched and inspected live from
  CelesTrak; same-week cross-check test), visibility computation
  (observer lat/lon/epoch/min-elev), JSON interchange format so GLONASS
  or hand-curated data can be fed from anywhere, nominal-registry
  fallback, cached fetch with retries (stdlib only, no new deps)
- 022b (CLI): gengnss almanac table/JSON/save subcommand + --visible
  flag on run/show; --visible composes with the existing flags and
  freezes resolved selections in the sidecar (reproducibility kept)
- 022c (GUI): Load almanac dialog (fetch in background thread / from
  file, position filter, apply-to-system) pre-checking the 021
  satellite palettes with healthy/visible satellites

Scope decisions recorded: GPS Yuma/SEM are the only machine-readable
public almanacs; GLONASS status page is JS-rendered/authenticated (no
public API) -> JSON interchange + nominal fallback; Galileo/BeiDou have
no public open-service almanac with PRN<->SV maps -> 021 ICD ranges
remain their source of truth. Tests never touch the live network
(fixtures embedded, fetch monkeypatched).
ykp closed this pull request 2026-09-29 19:46:34 +02:00
All checks were successful
ci / test (3.12) (push) Successful in 1m56s
ci / test (3.14) (push) Successful in 2m36s
ci / test (3.9) (push) Successful in 2m14s
ci / test (3.12) (pull_request) Successful in 2m52s
ci / test (3.14) (pull_request) Successful in 2m56s
ci / test (3.9) (pull_request) Successful in 3m28s

Pull request closed

Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
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
ykp/gengnss!37
No description provided.