**Note** from Bead: Firewatch Camera Grid · [canonical source](https://redfish.acequia.io/guerin/.agents/65783732-7907-4a36-983a-3b015e75e80b/2026-06-13/notes/04-visualization-affordances-brainstorm.md) · session 2026-06-13 · discussion: Talk: Firewatch Camera Grid
Stephen, 2026-06-13, looking at the live wall (10 Sandy cams, daylight, smoke plumes in South_Mountain / Las_Virgenes / Decker / Oat_Mtn simultaneously): *"think creatively of the visualization affordances of what's in this config and what will be in the 3D … simplifying the interaction with the greatest info value. brainstorm 3 orthogonal ideas."* Brainstorm — nothing committed. **The latent fact in the screenshot:** several cameras are looking at the *same plume* from different positions + bearings at the same instant. That's the multiplier the three ideas each exploit on a different axis.
## Axis 1 — SPACE: cross-bearing geolocation (pose → a located fire) Use the camera **pose** (az + fov) as a measuring instrument, not just a label. - **2D (now):** each tile's az becomes a **ray** on the map (not just a marker). Let the user mark the smoke column in a frame (click the plume → a horizontal pixel → a precise sub-fov bearing); two+ rays **forward-intersect** → the fire's lat/lon, derived from bearings alone, **no range needed** (the Osborne Firefinder / fire-lookout cross-bearing, automated). - **3D (coming):** rays become beams over terrain; their intersection is a column; the posed billboards converge — you see one plume from 6 angles wrapping a single 3D point, sitting on the draped ToA/perimeter. - **Simplify × info:** "10 pictures of smoke" → "fire is HERE (34.2x,-118.7x), confirmed from 6 bearings," from two clicks. The wall becomes a geolocator.
## Axis 2 — TIME: change is the signal (frames → surfaced events) Don't show the raw frame; show what *changed*. - **2D (now):** per-camera **activity track** (frame-to-frame Δ magnitude over the 36 h) replaces/colors the density lane — bright where smoke appears/grows. Playhead **snaps to events** ("first smoke per camera," "growth spikes"); optional onion-skin/Δ render so plume growth glows on the tile. - **3D (coming):** the per-camera change feeds the fire **front/plume** (pairs with the incident-viewer ToA + the smoke-sim-at-leading-edge directive); intensity rides the posed billboard. - **Simplify × info:** instead of hand-scrubbing 10 cams × 36 h, the system hands you the 3 cameras and 4 moments that matter. "When did it start, where did it spread" without hunting.
## Axis 3 — ATTENTION: salience layout (a fixed grid → a self-organizing wall) The wall's *arrangement* carries information. - **2D (now):** tiles **resize/reorder by relevance** — cameras currently seeing fire float forward + enlarge; ones pointing away or static shrink/dim. As you scrub, the wall "breathes" with the incident. Co-located cams (Castro 1886/1887, Topanga 2763/2764) **collapse to one site tile** that fans into its members (the frame-set/image-set affordance) → ~7 sites not 10 tiles. - **3D (coming):** the grid⇄geo **morph** becomes attention-driven — tiles fly to map/terrain position **and scale by relevance**; the informative cameras cluster around the fire. Size = salience, position = geography, both readable at once. - **Simplify × info:** the operator's eye goes straight to the views that matter; the wall self-curates instead of being scanned. The layout itself is data.
## Orthogonality + composition Three independent axes — **where** (geometry), **when** (temporal change), **which/how-arranged** (attention) — each a different lever on "less interaction, more info." They compose: change-detection (2) supplies the smoke mark that triangulation (1) intersects, and the triangulated relevance drives the salience layout (3). But each stands alone and could ship independently. *(Awaiting Stephen's own ideas — he flagged he has additions.)*
## CORRECTION (Stephen): "detection is NOT the problem. that's what amateurs think" Axis 2 (change/detection) is the amateur miss — drop it. By the time 10 cameras are on a plume, detection is long done (AlertCalifornia AI + lookouts + sats + 911). The pro problem *starts after* detection. Reframe of "the problem" with an ocean of posed pixels (cameras × time × FMV × phones × sats), almost none of it about *finding* anything: - **MEASUREMENT** — turn imagery into georeferenced quantities: head/flank location, **rate of spread** (track the head across frames → m/min + direction), **plume height** (column top in image + pose → height → Byram intensity), column tilt → wind. Quantitative size-up. (Axis 1 was on this track — level it up from "locate a dot" to "measure a moving fire.") - **RETRIEVAL** — the wall is the *answer to a query*, not a fixed 10-up: "everything that saw [lat/lon] during [window], and from what angle," across every source. The catalog as a spatiotemporal-**pose** query engine (the RTE / active-cataloger thesis: value is retrieval + fusion, not detection). The grid⇄geo morph = the query result laying itself out. - **PROJECTION ↔ VERIFICATION** — the *model* (ToA / spread / perimeter) is the protagonist; cameras are how you check it. Drape the prediction into each posed view; the human's job shrinks to confirm/correct, and corrections flow back into the catalog. Closes the observation↔prediction loop. So the three orthogonal axes become **measure / retrieve / verify** — all post-detection, all "pose + terrain do the work, human just confirms." Still probing for Stephen's specific add (he says it makes one of these nearly free).