The idea came from using the Strava heatmap in JOSM to trace the proper location of mountain bike trails. I'm trying to use Strava less, and usually have ridden the trails enough myself before mapping them that I could use my own routes... So I figured why not have my own heatmap tile server?

It's also cool to just look at.

I could take it a lot further with time boxing what's displayed and whatnot, but generating the tiles is computationally expensive, so I just stuck with what I have for now. It meets the need.

This one generates maps from OpenStreetMap data + some custom curated info in YAML: https://github.com/c0nsumer/trailmaps.app-map-generator

This one converts a basic chunk of OpenStreetMap data to an SVG so I can mark it up (by hand) in Adobe Illustrator to make specifically-styled print/PDF maps, such as what get installed at trailheads: https://github.com/c0nsumer/osm_to_ai

This one takes GPS recorded rides and builds custom/personal heatmaps serving up the map tiles so I can use them in map editing software: https://github.com/c0nsumer/local-heatmap-tile-server

And all of this has been put together to make the custom, local, specific-use-case maps that are at https://trailmaps.app (which, via local curation, are overall better mobile/online maps than many of the bigger auto-generated systems such as Trailforks, Gaia, RideWithGPS, etc, for visualizing local systems).

It's neat stuff where I understand all the inputs, outputs, and how most of it works, but AI tooling (Claude, mostly) has allowed me to bolt it together much faster than I would have writing it myself.

Just something as simple as "that ceiling fan doesn't work so well, and squeaks once in a while when on high" can easily be remedied yourself when owning the house by just going buying and installing a new ceiling fan.

Regardless of how handy one is, with a landlord that's generally not allowed without permission, the landlord often won't install as nice of one as you might like, etc.

This goes for every fixture that's not part of the rental. Major appliances, flooring, even door knobs... Like if you suddenly want an electronic keypad on your deadbolt.

Of course, this flexibility has to be something you care about. Not everyone does, but for those of us that do...

There's no reason why it couldn't be used anywhere else. This just makes maps that fit within the bounding box of a relation. The only thing US specific about it is the elevation data, and I'm sure something else could be used to get that elsewhere. Or else it could just be turned off for a given map with show_terrain: false.

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.

Comments URL: https://news.ycombinator.com/item?id=48144262

Points: 1

# Comments: 2

So while the content is in RAM on the Pi, a lot of the heavier lifting (TLS termination) is done elsewhere, which saves a ton of CPU load on the Pi.

Comments URL: https://news.ycombinator.com/item?id=47817040

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47677268

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47349793

Points: 1

# Comments: 0

It builds more a nice picture of what was going on when paired with the users description. Or sometimes, depending on the user, you just don't have anything else to go on besides "it crashed".

An uneven wall material (plaster on lathe, or even plaster on drywall as we have in most of our house) can be quite a hassle to find the actual timbers/studs behind.

You're welcome.

Yeah, give borg a look. It's just faster to back up, faster to delete old backups, and just easier to do restores because so long as you have the appropriate credentials you can list the archive from any machine.

I think there's still a place/use for --link-dst and hardlinks, but as a backup system I think borg does it better.

For reference: https://nuxx.net/blog/2019/11/10/using-borg-for-backing-up-n...

And then once all references to the inode are removed (by rotating out backups) it's freed. So there's no maintenance of the deduping needed, it's all just part of how the filesystem and --link-dest work together.

I did the same thing, but with a more detailed writeup, in 2009: https://nuxx.net/blog/2009/12/06/time-machine-for-freebsd/

It was really handy, but I now use borg as it just works better.

Comments URL: https://news.ycombinator.com/item?id=46760124

Points: 2

# Comments: 0

And I know this is a whole lot of personal preference, but I like macOS. It works well for me. It's a good UNIX(-like?) with professional-level apps.

I support/maintain/use Windows systems for a living so I'm comfortable there as well, and I'd be mostly fine on a Linux but the lack of pro-level apps for some of my hobbies (namely, map making) and sufficiently-user-friendly equivalents for a few other apps (eg: rubiTrack, Hazel, Photos.app) is a problem.

(A bunch of years back I made a conscious choice to do less sysadmin-ing at home, even if I have to pay a bit more. It's freed up mental capacity for using computers as a means to an end vs. an end itself. And it means I don't have the flexibility of Linux or other OSS things at times, but I've been able to work within that. But I'm getting way off topic here...)

The PA27JCV (which I don't expect to have back from warranty repair for 3+ weeks) looked fine, and I'm now at day 5 of using the U3223QE and it's fine. So this is my solution to the problem I guess.