← Zach Donnenfield
No. 01 product systems

Segment Atlas

Drop in a Garmin or Strava file and the ride replays as a ghost over real lidar terrain, with efforts compared section by section against your own past attempts.

Role
Solo. Concept, product, engineering, testing, docs.
Period
2026
Team
No one. Personal time, personal equipment, personal accounts.
Live
segmentatlas.com
Code
github.com/zdonnenfield/segment-atlas
The Segment Atlas interface. A ride replays over 3D terrain of the Marin Headlands and the Golden Gate Bridge, with labelled course segments. A panel on the left lists saved rides and reports device storage of 111 MB for one ride.
A ride on Hawk Hill, mid-replay. The library panel is the privacy argument in one frame. The rides live in this browser, the storage figure is the device's, and the delete button is real.

The path

  1. FIT/GPX file
  2. parsed and decoded off the main thread
  3. replayed over USGS lidar terrain

The problem

You finish a ride with a file holding a few thousand data points and no good way to look at any of it. The tools that do exist want the file uploaded to someone’s server before they will show you anything.

What I built

Past the replay, it models the wind cost of a result separately from the rider’s actual effort, and plans record attempts against forecasts. The route builder turns any ride into a new mapped 3D route anywhere in the continental United States, pulling public USGS elevation and aerial imagery live in the browser. Nothing is pre-baked.

None of it touches a server:

125 automated tests across 33 files cover the physics model, file parsing, comparison logic, route topology, storage lifecycle, and performance budgets.

What changed

It shipped, and it works for a stranger: a real ride file, no account, no setup, and it runs on a phone.

There are no usage numbers, and I am not going to imply an audience it does not have. What it proves is narrower and still worth something. I took a product from concept to a working public URL alone, covering concept, brand, roadmap, UX, engineering, tests and docs.

It is also the only piece of my work a hiring manager can open. Everything else I have built sits behind an employer’s login.

The pattern

Three decisions here are about the same thing: not letting the app claim more than it actually knows.

The matcher reports its own evidence, returning coverage and monotonicity rather than a bare pass or fail, so a partial match is explainable. The builder checks route length, terrain area and shape before any network request goes out, and explains a refusal in plain language. And recorded results are never overwritten by estimates.

The ride comparison panel. A sections table lists four segments with two riders' times side by side, and a smaller calm-equivalent time printed under each. A rank-order control switches between Recorded and Calm-equivalent. A "Where to improve" note reads: upper wall was 41 seconds slower, at 19 fewer watts and 1 beat per minute higher.

The third decision, on screen. Every recorded time carries its modeled calm-equivalent underneath rather than in place of it, and switching the ranking to modeled numbers is a deliberate act with its own control.

The applied-AI work in this drawer runs on the same rule.

The builder, before it spends anything

In

A ride the rider wants turned into a new 3D route

Checked against

  • Route length
  • Terrain area
  • Route topology
  1. All three inside budget

    Fetch USGS elevation and aerial imagery, and build the route

  2. Any one over

    Refuse, and name the budget it blew in plain language

The call

Decided

Everything runs in the browser. No server, no accounts, no upload.

Instead of

A backend that could do the geospatial work server-side, sync a library across devices, and let riders share routes with each other.

What it cost

No sync and no sharing. Terrain decoding has to fit inside a browser's memory budget, which is why the raster budgets are adaptive and why moving the work into Web Workers was not optional.

How it's built

  1. What the rider touches

    • Ride replay
    • Route builder
    • Section-by-section comparison
  2. What holds it together

    • Ride library & route lifecycle
    • Live elevation & imagery fetch
    • Off-thread parsing & decoding
    • Offline asset caching
  3. What the numbers rest on

    • Wind-cost & effort model
    • Evidence-reporting matcher
    • Automated test suite

Stack