Trestle
A GPS dashboard for rail-trails. Zero mapping libraries.
- 0Trails
- 0Waypoints
- 0Trail miles
- 0Mapping libraries
The problem
Trail apps assume cell service. Rail-trails, by their nature, run through the places that do not have any. And an unfamiliar domain is the cleanest possible test of whether the pattern in this file is real or just a story about a career.
Why it mattered
It is the one project here with no business justification whatsoever, which makes it the most honest evidence on the site: a domain I knew nothing about, taken to working software, alone, because I wanted it to exist.
The old process
- Existing apps degrade or fail without connectivity
- Trail data published by agencies in PDFs of varying reliability
- Mapping handled by heavy third-party libraries with their own assumptions
The idea
Build it offline-first from the beginning, draw the map engine rather than importing one, and verify the source data before trusting it — because the data turned out to need verifying.
The system
A browser-based progressive web application with live GPS instrumentation and full offline capability. A Web Mercator map engine drawn from scratch on canvas. Offline satellite imagery cached through a service worker. Waypoint proximity logic, geotagged photo capture, weather integration, a Stripe donation flow, and Android packaging.
How it works
- Web Mercator projection and vector trail rendering drawn on canvas with no mapping library
- USGS National Map tile layers cached locally through a service worker for offline use
- Live GPS speedometer with analog and seven-segment readouts
- Waypoint logic with 80-metre proximity stamping
- Geotagged photo capture and Open-Meteo weather integration
- Stripe donation flow; Android packaging for install
- A steam whistle synthesized from oscillators rather than an audio file
Design decisions
- No mapping library
- Importing one means importing its projection assumptions and its performance characteristics. Drawing it means understanding it. Also, it is faster.
- Offline is the default state
- Not a degraded mode. The app is designed for no signal and treats connectivity as a bonus.
- Ride data stays local
- Nothing leaves the device unless the rider exports it. There is no reason for me to hold somebody's location history.
- Every asset is geometry
- Drawn, not sourced. It keeps the payload small and means nothing on screen was licensed from anyone.
Controls
- Source trail coordinates reconciled against published mileposts before use
- Physically impossible coordinate entries identified and corrected
- Offline cache integrity handled through the service worker lifecycle
Testing
Bolted to the handlebars of a fat-tire e-bike and ridden. The honest way. Also the only way to discover what a GPS readout does when the trail goes under a ridge.
Result
Live at trestle.allenhbuilds.com, deployed on edge infrastructure, in regular use.
Impact
- A working offline-first PWA in a domain I had no prior experience in
- Source data errors found and corrected in a state agency's published trail coordinates
- Evidence that the loop in Operating System is a method, not a narrative
What I took from it
The verification instinct is not a finance habit that I apply to finance. It is how I handle data, full stop — which is why the trail app has an audit trail of its own source data. Nobody asked for that. It is just what I do before I trust something.
What I would build next
More trail networks, and a cleaner import path so adding one does not require me.