This document preserves the future-feature inventory that has accumulated during Libration development.
It is not a commitment to implement anything. It is a retention document so that good ideas are not lost when they are deliberately deferred.
It is not a status surface. For what the product does today see docs/IMPLEMENTATION.md. Nothing here should be read as approved or scheduled work; an idea reaching this list means only that it was worth keeping.
The Eclipse System (E1–E6) is production. Remaining ideas in Moon, Sun-Moon-Earth, and observer astronomy are unapproved. Lunar visibility and moonlight geometry remains the strongest candidate in that family; it is not approved. Strategic next direction is scene camera then scene reference frame (docs/ROADMAP.md), not this inventory.
- Candidate — worth considering later.
- Planned — a likely direction, not current work.
- Blocked — depends on architecture that does not exist yet.
- Rejected — intentionally not desired.
Several sections describe extensions to subsystems that already exist. Those subsystems are described in docs/IMPLEMENTATION.md, and work in those areas should extend them rather than introduce parallel mechanisms — see design principles 7–9 in docs/PROJECT_STRATEGY.md.
This family is the retained product intent from the post-LIB-011 architecture discussion. Moon visual development through LIB-011 is complete. The Eclipse System through E6 is production (LIB-012 through LIB-019). Ranking below is future-work preference only: it is not permission to start implementation, and it is not an E7.
Strategic pointer: docs/ROADMAP.md (preferred next is scene camera / map reference frame, not this family). Current development state: docs/STATE.md. What already exists: docs/IMPLEMENTATION.md.
| Rank | Role | Entry |
|---|---|---|
| 1 | Preferred remaining direction | Lunar visibility and moonlight geometry |
| 2 | High-value follow-on | Reference-city Moon altitude and azimuth |
| 3 | High-value follow-on | Lunar nodes and eclipse relationships |
| 4 | Later Moon enhancement | Earth-Moon distance, perigee, and apogee |
| 5 | Later Moon enhancement | Symbolic lunar surface and face orientation |
| 6 | Longer-term product direction | Astronomical Events |
| 7 | Longer-term product direction | Accessible versus technical terminology |
Apply design principle 9 in docs/PROJECT_STRATEGY.md: the default map should remain beautiful and usable as an ambient display. Do not add large map-spanning geometry merely because it can be calculated. Large geographic effects should earn their visual footprint by communicating important geographic information. Prefer small decorations on existing geometry when possible.
For this family, distinguish three roles:
| Role | Suitable for continuous display? | Examples in this family |
|---|---|---|
| Ambient astronomy | Yes | Sun and Moon glyphs, phase, libration, lunar locus, solar analemma, planetary subpoints/tracks/loci, Milky Way zenith ribbon and GC altitude contours, illumination |
| Explanatory astronomy | Optional | Lunar horizon, nodes, altitude/azimuth, distance information |
| Event astronomy | Only when something unusual is approaching or occurring | Eclipse forecast bands, live eclipse alignment, dramatic beam/shadow visualization |
The point is to keep Libration an instrument, not a cluttered astronomy diagram.
Production through E6 (LIB-012 through LIB-019; docs/IMPLEMENTATION.md). Architecture and authority: docs/specs/scene/eclipse-system.md. There is no approved E7.
Shipped: offline NASA/Espenak–Meeus authority; global solar forecast and live footprint; lunar Earth-shadow on the Moon glyph; lunar advance forecast (separate 7-day horizon); event-static lunar eclipse visibility footprint (LIB-054) with a configurable line color (LIB-055); reference-city circumstances that never filter global truth; live alignment/beam; grouped configuration; event information; restrained labels; type filters; independent styling; factory solar/lunar masters on; honest unsupported-range copy. Instantaneous Moon-visible hemisphere geography was removed (LIB-046) and is not restored by the footprint. LIB-047 / LIB-052 add Eclipse event playback under Data → Event playback as Demo-time navigation (not a second clock, not eclipse authority). LIB-020 is a post-E6 reconciliation, not E7. LIB-021 is a later presentation reconciliation (map info panel, moonlight attenuation, spatial Earth-shadow, label avoidance), also not E7. LIB-042 reconciles HUD/placard/map-label copy and moves solar event labels off the path onto the Sun/Moon cluster; it is not E7.
The following remain unapproved recoverable extras, not a continuation of the planned sequence:
- past/future active-corridor split
- swept penumbra union (E2 uses a representative greatest-eclipse partial outline)
- event browser / history / search-by-date catalog
- map click-inspect of eclipse overlays (scene pointer inspection remains Phase 11)
- atmospheric eclipse color (horizon shifts, corona, Purkinje, sky color); map illumination attenuation from local obscuration is production (LIB-027)
- advanced style options beyond the E6 color / thickness / opacity families
- About-page authority provenance (identity remains durable internally)
- notifications
Do not treat those extras as approved work. Related inventory pointer: the derived overlays list below points here rather than keeping a separate one-liner.
Candidate. Strong follow-on / enabling feature. Related to, but not the same as, the Eclipse System. Lunar eclipse presentation no longer paints the geometric current-instant Moon-above-horizon contour (LIB-046); illumination still uses that geometry internally (lunarDot ≥ 0). LIB-054 adds an event-static visibility footprint for lunar eclipses only. A standing ambient Lunar Visibility overlay remains unapproved.
Expose the geometry behind Moon visibility and the existing moonlight / solar-shading behaviour, rather than inventing an unrelated night-side effect. Current moonlight already participates in the upstream illumination raster; see docs/IMPLEMENTATION.md.
Related but distinct concepts:
- Lunar horizon boundary. A precise geographic boundary separating locations where the Moon is above the horizon from those where it is below. Attractive because it is geometrically meaningful, visually lightweight, conceptually related to the solar terminator, and useful for understanding Moon visibility.
- Moonlight participation. Optionally expose the geometry that determines where the existing moonlight contribution can actually participate. Integrate with current solar shading / moonlight behaviour.
- Lunar illumination / intensity contours. Configurable boundaries for meaningful moonlight intensity or illumination thresholds. Not assumed to be required in a first realization.
Preserve an expectation of options, without freezing controls: off; boundary line; line plus subtle region; illumination contours; styling choices.
This is explanatory astronomy. A default ambient map should not be forced to show it.
Candidate. LIB-049 shipped the zenith ribbon. LIB-050 shipped Galactic-center altitude contours. LIB-051 / ADR 0018 introduced a reference-city Milky Way Viewing Window. LIB-057 / ADR 0021 collapsed Viewing / Strong / Prime into one primary window and added a static peak-UTC line-only viewing footprint. LIB-052 / LIB-053 keep sequencing under Data as one chronological Event playback stream. That is still not an aggregated observing-quality forecast: the footprint is event geography at peak UTC, not weather, transparency, or light pollution.
Keep four concepts distinct:
- Galactic ribbon — where the band is overhead.
- Galactic-center altitude contours — how high the bright central Milky Way is in the sky from each location (production as of LIB-050).
- Milky Way viewing window — when the Galactic center is favorably elevated from the reference city under astronomical darkness and low modeled moonlight, with a static peak-UTC footprint (production as of LIB-057).
- Observing favorability — a later aggregate. Not implemented.
A later feature could still combine:
- Galactic center altitude (LIB-050 contours already expose this geographically; LIB-051 already uses it for the city)
- fraction of the sampled Galactic plane/band above 10° / 20° / 30° (possible additional contours such as 25/50/75% of the band above 20°)
- astronomical darkness / Sun altitude
- Moon altitude, lunar phase / moonlight, lunar-eclipse attenuation
- optionally clouds
- potentially light pollution if an authority is introduced later
That would answer: “Where on Earth can the Milky Way be seen well right now?” Do not treat LIB-049 night-side emphasis, LIB-050 contour alpha, LIB-051/057 city windows, or the LIB-057 peak-UTC footprint as that forecast.
Related but distinct, also unapproved:
- Milky Way Band Viewing Window — a separate event family for northern observers when the Galactic center is poor but Cygnus/Cassiopeia band is high. Do not merge into GC windows.
- a terrestrial envelope of locations from which some portion of the band is above the geometric horizon (deferred from LIB-049 as semantically ambiguous)
- modest longitude-dependent band width without pretending to be photometry
- renaming Layers → Space objects to something like “Space & sky”
- a static “best latitude for Galactic-center culmination” helper (the moving altitude contours already communicate it)
Do not implement stars, constellations, photographic Milky Way imagery, or star catalogs as a side effect of this idea.
Candidate. High-value follow-on. Observer information for the existing reference-city concept — the same city already used by chrome time presentation and by LIB-011 observer-oriented libration. Do not create a separate Moon observer location.
At minimum, preserve: Moon altitude; Moon azimuth; compass direction; above/below horizon state.
Possible later extensions: Moon rise time; Moon set time; rise/set direction; additional observer circumstances. The existing sunrise/sunset for selected city idea remains a sibling, not a replacement.
Two independently configurable presentation modes are desired:
- Inspectable / detail presentation. A richer Moon information surface, tooltip, or inspection view. Possible contents, not a frozen list: altitude; azimuth; above/below horizon; phase; illumination percentage; distance; rise/set information.
- Persistent chrome presentation. Optional compact always-visible status associated with the reference city. Conceptual example only, not syntax or placement:
☾ +38° · SE. Related chrome inventory: status readouts and current reference city readout.
A possible later sibling is equivalent Sun altitude/azimuth information. That is not a complete solar-observer design and should not expand this item into one.
Candidate. High-value follow-on. Nodes should help explain why eclipse conditions arise, not merely add orbital trivia.
The explanatory relationship to preserve:
lunar locus
→ nodal crossing
→ Sun/Moon phase alignment near a node
→ eclipse possibility
The lunar locus is a natural candidate surface on which node crossings could eventually be represented. The ~18.6-year nodal regression is already visually apparent through changes in lunar-locus geometry (major versus minor standstill amplitude); node decorations should be able to speak to that cycle.
Potential configurable decorations, without freezing glyphs or rendering: off/on; ascending node; descending node; symbols; labels; node-related annotations; proximity-to-node emphasis; eclipse-relevance emphasis.
Prefer restrained decorations over additional large map-spanning lines. This is explanatory astronomy that may become more prominent when eclipse-relevant.
Lunar standstill envelopes remain a separate unapproved derived-overlay idea, related to the same nodal cycle, not absorbed into the Eclipse System.
Candidate. Later Moon enhancement.
Potential information: current Earth–Moon distance; apparent angular diameter; approaching/receding state; perigee; apogee; timing relative to the nearest perigee/apogee; position within the anomalistic cycle.
Do not automatically resize the production Moon glyph according to physical distance. The existing user-selected Moon glyph size is a presentation control with clear semantics. Distance variation should be communicated through information and/or optional event decoration.
Default future product presentation should favor familiar terminology such as Supermoon and Micromoon where appropriate, while keeping precise astronomical values available. Colloquial labels such as “supermoon” may not have a single universally binding astronomical threshold; Libration must eventually define and document whatever classification it uses rather than treating the term as a fundamental celestial state.
A product-wide accessible-versus-technical terminology preference, if ever introduced, should apply here; see Accessible versus technical terminology.
Candidate. Later Moon enhancement. This refines the earlier “apparent lunar orientation / lunar north rotation” backlog idea. LIB-011 shipped map-versus-observer libration-marker orientation; that marker-frame rotation is not this item.
Preferred first realization: a symbolic lunar surface, not a photographic texture. Conceptually a small number of recognizable simplified maria / surface features so that actual apparent movement of the lunar face becomes visible.
The purpose is not lunar cartography. The purpose is to let the observer perceive libration rocking, apparent face orientation, and lunar-north / sky orientation.
Preserve independence among:
- phase;
- libration indicator (ring / crosshair / off);
- symbolic lunar surface detail.
A future user should be able to use these together or independently. Complements, and must not replace, the existing optical-libration mark.
Reuse the observer-frame foundation established by LIB-011 rather than creating a competing orientation model.
Prefer an experimental / DEV visual exploration before committing to production surface detail.
Candidate. Longer-term architectural / product direction. Not a framework, not an implementation plan, and not a reason to generalize the Eclipse System into an events platform on the way in.
Conceptual purpose: determine what noteworthy astronomical events are approaching, active, or recently passed at Libration’s authoritative / simulated product time.
Directional examples, not committed scope: solar eclipses; lunar eclipses; notable perigee / full-Moon combinations; solstices / equinoxes; conjunctions; meteor-shower peaks; other future astronomical events.
Events must follow product time. If the user accelerates demo time by months or years, future event behaviour should eventually arrive, activate, and pass according to simulated time. Do not tie event detection to wall-clock time. See the time model in docs/IMPLEMENTATION.md and ADR 0004.
Candidate. Longer-term product-wide presentation preference. Recorded here because distance / perigee / apogee and eclipse language will need it; not a complete terminology-system design.
Conceptually two styles:
- Accessible / familiar — the normal / default experience (for example Supermoon, Micromoon, everyday eclipse wording).
- Technical / precision-oriented — more exact terminology, quantities, units, and distinctions.
Do not settle the preference name, schema, or complete consequences now.
Families already in the bundled catalog are listed in docs/IMPLEMENTATION.md; the entries below are extensions beyond them.
- geology: alternate styles, higher-resolution scientific linework.
- terrain: higher-resolution or alternate-source terrain, month-aware DEM families, neutral terrain-only palettes.
- bathymetry: alternate products such as GEBCO-only styling, higher-resolution grids, additional hypsometric palettes.
- natural-color seasonal imagery.
- further Blue Marble variants.
- political: alternate styles, borders-only overlay-friendly variants.
- borders-only overlay-friendly maps.
- population density: alternate GPW epochs, WorldPop grids.
- land cover: Copernicus 100 m discrete map, alternate MODIS epochs, higher-resolution products.
- biome / ecology.
- climate: temperature and precipitation climatologies, alternate Köppen epochs (Beck V3), Köppen border-only variants.
- precipitation.
- temperature normals (distinct raster products).
- cloud climatology.
- additional night-light or light-pollution map substrate products beyond the bundled Black Marble composition input.
- light pollution.
- shaded relief.
- terrain-only neutral substrate.
- antique or paper-style reference map if visually differentiated.
- high-contrast accessibility map.
- dark-friendly overlay substrate.
- stronger source provenance in the catalog, beyond per-family
licenseNoteandsourceLinks. - clear placeholder versus sourced status.
- map source processing notes.
- validation checklists per family.
- fixed-month override for comparison or demonstration.
- presentation presets per map role.
- borders overlay.
- graticule overlay.
- time-zone boundary overlay as informational layer, not structural model.
- city labels.
- reference cities.
- custom pins.
- user-defined routes.
- shipping lanes.
- flight routes.
- satellite ground-track static references.
- tectonic plates.
- ocean currents.
- climate bands.
- daylight terminator reference lines.
- solar shading / dark-side visualization (continuous solar-altitude twilight gradient encoded in the same upstream illumination raster, with civil/nautical/astronomical thresholds retained as semantic anchors, not a separate twilight layer).
- solar subpoint.
- lunar subpoint.
- moon phase beyond the existing sublunar-marker phase representation.
- Symbolic lunar surface / apparent face orientation — see Symbolic lunar surface and face orientation. Replaces the earlier “apparent lunar orientation / lunar north rotation” one-liner. LIB-011 marker-frame rotation is not this item.
- analemma variants.
- equinox and solstice reference overlays.
- Eclipse System — see Eclipse System. Replaces the earlier “eclipse path overlays” one-liner. E1–E6 are production. Deferred extras remain unapproved. Architecture in
docs/specs/scene/eclipse-system.md. - lunar horizon / moonlight-participation / illumination-contour geometry — see Lunar visibility and moonlight geometry.
- lunar standstill envelopes (related to the nodal cycle already visible as lunar-locus amplitude change; not a production control today). See also Lunar nodes and eclipse relationships.
- lunar nodes on or near the lunar locus — see Lunar nodes and eclipse relationships.
- Earth-Moon distance / perigee / apogee presentation — see Earth-Moon distance, perigee, and apogee. Do not auto-resize the Moon glyph.
- great-circle paths.
- antipode markers.
- local noon/midnight curves.
- reference-city meridian line.
- read-point alignment marker.
- UTC meridian reference.
- Milky Way observing quality — see Milky Way observing quality. LIB-049 shipped the zenith ribbon; LIB-050 shipped Galactic-center altitude contours; LIB-057 shipped one primary reference-city viewing window plus a static peak-UTC line-only footprint. An aggregated observing-quality forecast remains unapproved.
New consumers reuse the existing lifecycle subsystem; its contract, and the sources already wired, are in docs/specs/scene/dynamic-data-lifecycle.md. Weather participation models are explored in docs/specs/scene/weather-cloud-composition-plan.md.
Adding any of these is a product decision requiring explicit scope, not a consequence of the seam supporting it. Prefer free-for-personal-use sources; paid sources are acceptable when the benefit is clear.
ISS current-position (SGP4 at the product instant, not the future track tip) is production as of LIB-035. ISS live provenance, TLE freshness (≤18 h live / 18–48 h degraded / >48 h hidden), and hide-on-live-TLE-failure are production as of LIB-036. Immediate-on-enable acquisition, 2-hour TLE refresh, 8 s timeout, and ordered CelesTrak → Where the ISS at failover are production as of LIB-040 / ADR 0014. Layers → Space objects is the ISS presentation home as of LIB-038 (orbit track, past/future segments, glyph). Multi-orbit past/future horizons derived from TLE mean motion, local SGP4 window expansion, orbit-distance fading, and ISS silhouette glyph-color are production as of LIB-041. Planetary sub-object points, continuous planet ground tracks, and daily same-time planetary loci for Mercury–Neptune plus Pluto are production as of LIB-048 / ADR 0016. They share Space objects (Planets) with one Planets layer master. They are offline astronomy at product time, not current-only live data, and they are not solar analemmas. Remaining unapproved: local altitude/azimuth, conjunction/event detection, planet-visible hemispheres, other dwarf planets, moons. The Milky Way zenith ribbon (Galactic plane, approximate band, sparse ribs, Galactic center) is production as of LIB-049 / ADR 0017. It shares Space objects after Planets, with one Milky Way layer master (factory off). It is zenith-projection geometry, not naked-eye visibility and not a star field. Remaining unapproved for that family: above-horizon visibility envelopes, Galactic-center altitude thresholds, observing-quality forecasts, photometric longitude-dependent band width, and renaming Space objects to something like “Space & sky.” It is the intended configuration home for future satellites and spacecraft; those objects are not implemented. Earthquake live provenance (no production fixture-as-live), snapshot-age stale policy (≤10 min live / 10–60 min stale / >60 min hidden), 15 s USGS timeout, and Layers → Earthquakes local filters (minimum magnitude factory 2.5+, maximum age factory 24 h, earthquakes-only, persistent labels 4.0+, show label on hover factory on) are production as of LIB-059 / LIB-060. The live feed remains USGS all_day.geojson at 5 min. Hover is presentation-only (same compact M4.6 · place label; no network; no selection). Clouds v3 is production as of LIB-065 (presentation from LIB-063 / coverage from LIB-064; ADR 0022, ADR 0023): freshest valid GOES-East, GOES-West, Meteosat FES, and Himawari IR independently, with the EUMET geostationary ring as coverage backstop; IR-derived white/gray overlay; source-local freshness and 8 min poll; no production fixture-as-live; physical illumination participation off; Layers → Weather holds Clouds opacity + observation-age range (no provider selector, no sync-mode toggle). LIB-067 keeps that composition and separates coverage authority (provider valid-data) from cloud signal (derived highlight) so valid-clear observations replace older cloud. LIB-069 / ADR 0024 adds a per-source quality plane and quality-aware lexicographic overlap so extreme GEO limb observations do not overwrite substantially better views merely because they are modestly newer. LIB-071 / ADR 0025 interprets heterogeneous provider display rasters into canonical display IR, then one conservative shared cloud-confidence transfer; Rec.601-of-GIBS-false-color is not the production path. LIB-073 prefers a geometrically usable EUMET ring over q=0 regional coverage; LIB-075 gives the ring its own component-geometry quality plane so poor ring can yield back to q=0 regional. LIB-077 routes GIBS Band13 near-gray pixels through the warm-gray legend so WMS-resampled gray cannot snap onto the cold gray branch; chromatic cores keep the 64³ LUT. LIB-079 interprets the EUMET ring with the same identity grayscale as Meteosat. Usable q>0 regional authority is unchanged. Current-only live layers are also suppressed when product time is not live-enough. The WEATHER-5 IR corrective sequence is complete. Remaining Clouds items below are inherent IR/provider limits or future weather capabilities, not unfinished WEATHER-5 work. The following hardening remains unapproved and must not be treated as started:
- global persistent snapshot cache / snapshot-store eviction (Clouds already trims to ~4 in-memory versions for that source)
- GIBS / EUMETView historical
TIMEquerying (Clouds sends explicit current mosaic TIME only) - earthquake clustering, depth presentation, magnitude color bands, age fading, click selection / detail, tsunami/alert symbology, historical FDSN, or Event Playback
- API-key / proxy / desktop
fetchFn - historical USGS / TLE-history providers
Weather beyond the current-observation IR Clouds foundation remains unapproved. Future radar, lightning, wind analysis, and tropical/severe products inherit the same doctrine (ADR 0023): most recent valid observation beats artificial timestamp synchronization; domains must not wait on one another; each keeps its own observation time and freshness. Do not implement them here. Do not start another IR Clouds corrective item from this list.
- polar LEO gap-fill (the geostationary ring leaves polar holes; do not treat holes as clear sky)
- Clouds overlap feathering in dual-coverage q>0 interiors (not at coverage/no-data limbs, not at q=0 GEO skirts). LIB-075 refined ring-vs-q0 using component geometry. Remaining NATL East/MSG and Pacific West/Himawari handoffs are usable-quality crossovers; do not start a blend LIB automatically. Dual q>0 MSG∩Himawari over India remains empty after LIB-079; do not start q>0 blending as the next step.
- Inherent IR Clouds limits after LIB-079 identity grayscale: warm/low-cloud ambiguity, cold-surface / polar ice, GIBS false-color convective cores versus ring gray, residual provider texture. These are not a missing black-point and do not automatically justify blending, polar special cases, or another corrective calibration LIB.
- GEO limb-saturation filtering on a selected source’s own disk (quality authority no longer selects the MSG western rim over GOES-East)
- scientific Cloud-top temperature layer (retired MODIS CTT rainbow is not the default Clouds path)
- GeoColor / visible-light / terminator-blended cloud modes (WEATHER-6)
- physical cloud optical-depth / transmittance participation in illumination (requires a real mask/OD product, not display cloud confidence)
- weather radar (newest valid radar independently; no wait for Clouds)
- precipitation forecast
- temperature forecast
- wind fields (analysis valid-time remains independent of Clouds)
- pressure systems
- hurricane tracks / tropical cyclones (official advisory issuance times are independent; safety-critical provenance will be stricter)
- lightning (likely a short recent-event window; do not couple freshness to Clouds)
- severe weather watches/warnings
- Weather Event Playback or lower-left weather alerts (do not reuse the astronomy event sequencer)
- aurora forecast
- volcano activity
- aircraft ADS-B feed
- marine AIS feed
- satellite live positions
- spacecraft beyond the ISS
- wildfire smoke
- air quality.
Planetary illumination and overlay readability are existing upstream subsystems; see docs/IMPLEMENTATION.md. Everything below extends them and requires explicit product scope. None of it is standing work, and none of it should be read as reopening a settled baseline.
- layer blending modes.
- multiply, screen, additive, normal.
- alpha masks.
- geometric clipping.
- viewport clipping.
- composition-aware day/night illumination.
- atmospheric scattering and haze, or further narrow tuning passes in
src/renderer/illuminationShading.tsbeyond the current constants. - shadow and glow effects expressed upstream as RenderPlan intent. Dramatic eclipse alignment / beam decoration is a separate event-astronomy idea; see Eclipse System.
- overlay-readability extensions beyond the current model: per-layer readability contracts for stack rows that do not have one; finer multi-row semantics, such as separate tuning per static-raster row; additional catalog or resolver substrate heuristics beyond the current intrinsic hints.
- per-layer contrast/brightness/saturation/gamma where appropriate.
- high-contrast accessibility mode.
- scientifically grounded day/night and twilight attenuation.
- configurable twilight softness as a persisted scene axis, if the product ever warrants exposing it.
- additional night-light data products as composition or substrate inputs.
- emissive readability presets tied to overlay density or zoom, once those modes exist.
- seasonal illumination effects.
- solar altitude shading.
- reference-time comparison modes.
Strategic sequence: zoom is implemented (LIB-080); pan is implemented (LIB-081); Earth-fixed reference-frame foundation is implemented (LIB-082); Moon longitude-lock is implemented (LIB-083); Moon position-lock is implemented (LIB-084); Sun longitude-lock and Sun position-lock are implemented (LIB-085); the shared anchored production model is implemented (LIB-086); automatic scene-cover zoom for position-lock is implemented (LIB-087); the trackable-map-object target identity is implemented (LIB-088); ISS tracking is implemented (LIB-089); Tracking target + Tracking mode UX is implemented (LIB-090); direct click-to-track for Moon, Sun, and ISS is implemented (LIB-091); city pins and eligible planetary current glyphs are trackable (LIB-092, ADR 0036); Galactic Center and Galactic Anticenter are trackable (LIB-093, ADR 0037). A generic target picker remains on docs/ROADMAP.md. Architecture: docs/specs/scene/camera-and-reference-frame.md. Do not start additional trackable-target work from this file.
This list is map viewing and projection, not civil time reference.
Candidates not absorbed by the camera / Moon-frame sequence:
- Additional trackable targets beyond Moon, Sun, ISS, city pins, eligible planetary current glyphs, Galactic Center, and Galactic Anticenter, only if a candidate satisfies the trackability contract in ADR 0032. City and planet tracking is implemented (LIB-092, ADR 0036). Galactic Center and Anticenter tracking is implemented (LIB-093, ADR 0037). Not a generic picker. Earthquakes remain excluded from tracking. The galactic-plane band is not a target. Do not invent a synthetic
"milkyWay"identity. - animated transitions between Earth-fixed and entity-fixed.
- full-world fixed view with additional aspect rules beyond the current scene-strip stretch.
- orthographic globe.
- perspective globe.
- Mercator.
- Robinson.
- Winkel Tripel.
- projection switcher.
- inverse projection for a general pointer inspector (earthquake hover already inverts the scene mapping).
- click-to-inspect lat/lon/time. A richer Moon inspection surface is a separate idea; see Reference-city Moon altitude and azimuth.
- viewport clipping beyond the existing scene-strip clip.
- tile preparation.
- high-resolution map assets.
- camera-state persistence; URL/shareable view.
- map rotation; heading / orientation lock.
- semantic zoom (layer density by scale).
- entity-relative path/trail presentation.
- one-click reset/recenter polish beyond the zoom/pan reset requirement.
This section is civil time presentation (display mode, zone, reference city). It is not the scene/map reference frame (Earth-fixed vs entity-fixed) in docs/specs/scene/camera-and-reference-frame.md.
Candidates:
- reference city selector refinement.
- saved reference cities.
- custom reference meridian.
- read-point visualization.
- local 12 hour and local 24 hour display modes.
- UTC-style display mode clarity.
- demo mode timeline.
- time scrubber.
- historical time playback.
- future time preview.
- compare two reference cities.
- meeting-planning mode.
- sunrise/sunset for selected city. See also Reference-city Moon altitude and azimuth for Moon altitude, azimuth, and possible later rise/set information using the same reference city.
- Moon altitude / azimuth / compact chrome status for the reference city — see Reference-city Moon altitude and azimuth.
- civil-date boundary visualization.
- date-line explanation aids.
- leap second and time standard notes if ever needed.
Candidates:
- top-band layout presets.
- accessibility size controls.
- high-contrast top chrome.
- alternate hour-marker visual families.
- analog clock polish.
- radial line polish.
- radial wedge polish.
- text font curation.
- NATO row visibility and styling controls.
- tickmark density controls.
- bottom information bar expansion.
- status readouts. A compact always-visible Moon altitude/azimuth chip associated with the reference city is one candidate; see Reference-city Moon altitude and azimuth.
- current reference city readout. Reuse the same authoritative city; do not add a second observer location for Moon or eclipse information.
- selected map/source readout.
- layer legend area.
Planned direction:
- named partial config presets.
- composable preset stacks.
- explicit application order.
- last-write-wins conflicts.
- scene presets.
- chrome presets.
- map/layer presets.
- accessibility presets.
- export/import user presets.
- reset selected domain to defaults.
- compare current config to preset.
- preset migration support.
Candidates:
- Improved settings organization — Layers (LIB-030, LIB-031) and Chrome (LIB-032) topic subpanels are production. Remaining organization (search, other-tab grouping) is still a candidate.
- search/filter in settings.
- map selector with thumbnails.
- source attribution panel.
- layer stack drag-and-drop.
- visibility and opacity quick controls.
- undo/redo for config edits.
- reset individual setting groups.
- onboarding wizard.
- diagnostics panel.
- failed raster diagnostics.
- asset validation report.
- performance overlay.
- screenshot/export frame.
- portable config export/import.
Candidates:
- stronger Cursor rules.
- docs freshness checklist.
- source validation scripts.
- map catalog validation command.
- visual regression tests where practical.
- RenderPlan inspection tools.
- scene debug overlays.
- config diff tooling.
- typed schema export.
- test fixtures for map catalogs.
- release checklist.
- public contribution guide.
These are larger future directions, not near-term tasks:
- wallboard or appliance mode.
- presentation mode.
- packaged desktop distribution through the Tauri shell.
- hosted dashboard mode only if AGPL/network implications are intentional.
- local network display endpoint.
- OBS/streaming background mode.
- kiosk mode.
- educational mode explaining longitude, time, seasons, and projection. Explanatory astronomical overlays should still follow the visual-design principle.
- astronomical events following product time — see Astronomical Events. Longer-term direction, not a framework to build before or instead of the Eclipse System.
- mission-control style scene packs.
- personal travel/world-clock dashboard.