A Colorado Trail relay
The Colorado Trail runs about 490 miles from Denver to Durango.
In July 2025, my wife Kelly and our friend Bex did a unique relay of the trail; Kelly ran the wilderness sections, where bikes are not allowed, and Bex mountain biked the rest.
They carried a Garmin InReach with them, and those of us watching the adventure used the (kinda jankey but serves its purpose) share.garmin.com
site to follow them when they were out on the trail.

share.garmin.com — it's not pretty, but it serves its purpose.
I wanted a way to show their progress through the state1, and help folks get a better picture of how the relay worked in a day-to-day sense (who was on the trail, how far they were going, etc). So I built a site to track their progress, https://www.gadom.ski/ct-relay/, and few of the bits of work to build the site seemed interesting enough to share.

I am so not a frontend engineer.
Source data
The first thing I needed was the Colorado Trail itself, and that proved trickier than expected. There's plenty of folks' personal GPS tracks out there on the internet, but I wanted to use an "authoritative" source — you can't just trust anything you find on the internet, you know what I mean? After wasting some time on portals2 like https://trails.colorado.gov/, I found my way to Colorado Parks & Wildlife's (CPW') ArcGis portal, and specifically their COTREX Trails dataset. Can't get much more authoritative than that!
The GeoJSON feature collection weighs in at 229MB with almost 100k features, and (surprise surprise) there's no single "Colorado Trail" feature.
However, there are many (229) segments in that dataset that include a Colorado Trail Segment N
name.
A little bit of SQL (via DuckDB and its excellent spatial extension), a bit of manual cleanup with QGIS, and I had myself a single line string of the Colorado Trail3.

Wow, look, a line.
Tracking data
Now I needed to overlay their progress on that line.
There's no pretty way to say it — I (lightly, legally4) reverse-engineered Garmin's API5.
share.garmin.com
uses a WebSocket API to ship data for the current viewport to your browser.
To get Kelly and Bex's locations, all I had to do was open up their live tracker, zoom to the day's points, open up Developer Tools, and grab the latest UpdateUser
message from the WebSocket connection.
Easy enough, right?6

Neerrrrrrd
Putting it together
The rest was straightforward — if we were living in a different timeline where I actually know how to write frontend code. The rest was pretty hard but a learned a lot 🤣.
- The site: https://www.gadom.ski/ct-relay/
- The code: https://github.com/gadomski/ct-relay/
- Just the Colorado Trail stuff (w/o the relay): https://github.com/gadomski/colorado-trail.

Adventure is out there!
I also was recovering from a back injury and couldn't exercise much. Can you say "cabin fever"?
For more on my dislike of geospatial portals, see "Let's apply dumb economics to the use of remote sensing data".
Eastern Collegiate route, if you were wondering.
Maybe?
Almost. I didn't quite figure out the sequence of calls to plug their data my own site to use their live updates directly. For now, the process requires a human to grab the data at the end of each day.
This sort of cash grab business model, where companies will send you geospatial data but not in a way that's easy to use, drives me bonkers.