trails/openspec/changes/journal-elevation-profile/design.md
Ullrich Schäfer 26b59b9c95
openspec: propose journal route/activity detail catch-up changes
Three OpenSpec proposals to bring the journal's route/activity detail and feed
closer to best-in-class outdoor apps, in the order we'll implement them:

- activity-sport-type: nullable sport enum on activities (hike/walk/run/
  ride/gravel/mtb/ski/other), set on create or normalized on import,
  shown as a badge + feed verb, federated as a Note PropertyValue.
- activity-stats: one reusable StatRow + canonical metric set, sport-aware
  avg pace/speed, moving-vs-elapsed time. Derive-only, no schema change.
- journal-elevation-profile: elevation profile chart + chart<->map
  "active distance" hover/click sync on the read-only detail pages.

All three validate with `openspec validate --strict`. Specs only; no code.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-12 13:56:24 +02:00

2.8 KiB

Context

@trails-cool/gpx already parses trackpoints with elevation; the detail loaders already build GeoJSON for the map. The Planner's elevation-map-interaction spec defines the hover/click/drag behavior in an editing context (Yjs-backed). The Journal detail pages are read-only React Router routes that render a Leaflet map (ClientMap / RouteMapThumbnail.client) but no chart.

Goals / Non-Goals

Goals

  • A self-contained, read-only elevation profile on both detail pages.
  • A shared "active distance" so the map and chart highlight the same point.

Non-Goals

  • No editing (the Planner owns reshape/drag-select-to-zoom); clicking the chart centers the map but changes no data.
  • No multi-series overlay (HR/pace/cadence) — we don't store per-point fitness data, and it's out of scope/ethos.
  • No schema or API changes; the series is derived from existing gpx.

Decisions

D1: Series derivation

A helper returns an array of { distance, elevation, lat, lng } samples from the GPX (reusing the gpx package's parse), downsampled to a sensible cap (e.g. ~500 points) for chart performance. Computed in the loader (server) so the chart component stays presentational.

D2: Chart rendering

An SVG area chart (no charting dependency): x = cumulative distance, y = elevation, gradient fill keyed to gradient steepness using the existing map-core elevation/gradient color scale. A summary strip beneath shows ascent, descent, highest, and lowest — formatted via the shared stat helpers from activity-stats when present, else local formatting.

D3: Shared "active distance" state

The detail page lifts an activeDistance | null state above both the map and the chart:

  • Hovering the chart sets activeDistance; the map shows a marker at the interpolated lat/lng for that distance.
  • Hovering the route polyline on the map sets activeDistance (nearest sample); the chart draws a crosshair/marker at that x.
  • Clicking the chart pans/centers the map on that point. This mirrors the Planner's interaction conceptually but is read-only and implemented independently for the Journal surface.

D4: Graceful absence

If the derived series has no elevation variation or no elevation data (e.g. a flat import or a planned route without elevation), the chart is not rendered and the existing gain/loss numbers stand alone.

Risks / Trade-offs

  • Map↔chart coupling: the shared state must avoid render thrash on hover; throttle pointer updates and memoize the interpolation.
  • Reuse vs. duplication with the Planner: we deliberately implement a separate read-only component rather than lifting the Planner's editing component, to keep the Journal free of Yjs/editing concerns. The shared piece is the gpx series helper and the map-core color scale, not the component.