So, I put together a toolchain that generates maps from OpenStreetMap data, some other open data sources, plus some manually inputted things, and produces static HTML+CSS+JS maps of individual trail systems. The map does geolocation, allows you to turn on and off markers for things like parking, points-of-interest, toilets, water, trail direction, etc. I then host these on trailmaps.app. They are simple, static, and effective for showing where you in a way you can relate to the actual trail system.
What differentiates this from a lot of other map systems (MTB Project, Trailforks, Strava, Gaia, RideWithGPS, onX, Mapy.cz) is while these these all show these trails, they either color them with difficulty designations or don't color them at all. This isn't that.
In interest of a bunch of things ranging from privacy for users to simplicity for me, there's just no tracking, no logins, no cookies (just some local storage to preserve map settings), and all libraries used are hosted on trailmaps.app. Everything gets cached locally (it's typically 15-25MB/map), which means once loaded it works when there isn't cell service. And it can be installed as a PWA. For a few of the trails I've made maps for (eg: RAMBA) and some others that I intend to... There isn't cell service over the whole area, so offline use is almost a must. And people seem to like the app-like PWA shortcut. (And yes, it does check for and prompt the user to reload the page if the map gets updated.)
Another benefit to the static, self-contained nature of the maps is that clubs and non-profits who maintain the trails can very easily link to, embed, or just host the map themselves like they would a print map. There's no login or payment required, and if they want to generate their own, they can. (A example of why they might prefer this is visitors. For example, Trailforks: unpaid users of the app can only see trails near their house on mobile devices. So if someone is traveling, doesn't subscribe, and the only map is on Trailforks... they can't see the trails. This sidesteps that.)
And yes, this does mean these maps are all hand-curated. I see this as benefit, because it means that only things relevant to the trail are shown on the map. Like, there could be dozens of "parking" areas near by, but there might only be one or two that's good for accessing the trail system. Or, the curator might know to include this local rail trail, or that multi-use trail, but not this other.) Curated, just like how a good print map is.
Because the maps are static once they are on the site, it also means that errant (or rogue) OSM modifications don't cause problems with the map. Sure, it means trail changes require manual work to update the map, but trail changes don't happen all that often, and maps can be updated and deployed in sync with the print/trailhead maps. And sure, it doesn't scale, but I'm okay with that for now.
There's still a bit to do. I could really use a logo, I want to make more maps (we've got a lot of trail networks here in Southeast Michigan), probably some refiguring of the indexing once I reach a certain threshold of maps, documentation cleanup on the generator repo, support for a new trail difficulty designation system (ITRS), and the inevitable bug fixes. But, I'm pretty happy with where it is right now. It's usable, and it works.
