I Built a Trek Planner That Works Where Your Phone Doesn't

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Trail Buddy is a trekking companion for the hills around Mandi, Himachal Pradesh. You tell it where you're starting and where you want to go, and it gives you a stage-by-stage roadmap with distance, climb, elevation profile and realistic timings. A local AI model then adds short, practical tips for the trek.

The problem is simple. The best trails here are exactly where mobile signal disappears. Most "smart" trip planners need a connection at the one moment you're standing at a fork with no bars. Trail Buddy does the cloud-dependent part once, at home or at the bus stand, and saves the route as a plain GPX file. After that, the roadmap, the notes and the AI chat all work with no internet.

It's built for beginners and families doing day treks like Prashar Lake, and for anyone who'd rather look at the hills than at a phone.

Demo

Code

b25246-star / trail-buddy

Trail Buddy 🥾

An offline-first trekking companion for the hills around Mandi, Himachal Pradesh, powered by a local open-weight LLM.

Plan a route between any two places while you have internet, save it, and reuse it later with no signal. The chat assistant runs entirely on your own machine through Ollama, so nothing about your trip is sent to a cloud AI.

Built for the Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass.

---

Why this exists

The best trails are exactly where mobile signal disappears. Most trip planners need a connection at the moment you are standing at a fork with no bars. Trail Buddy does the internet-dependent part once, at home or at the bus stand, saves the route as a plain GPX file, and everything else (roadmap, notes, AI chat) keeps working offline.

Features

• Stage-by-stage roadmap with distance, climb, high point and estimated up/down times.
• Plan…

View on GitHub

The project is small on purpose:

• trail_buddy.py: the command-line chat and planner
• rag.py: a tiny local retrieval system over my trail notes
• route.py: the route engine (GPX to roadmap, SVG map, HTML export)
• online.py: one-time online planning for any start and destination
• webapp.py and web/planner.html: the interactive map planner with live GPS
• data/trails/: plain Markdown notes and GPX files

How I Built It

The open pieces

• Ollama runs everything locally.
• qwen2.5:3b is the open-weight chat model. It's small enough for an ordinary laptop.
• nomic-embed-text is the open embedding model for search.
• OpenStreetMap supplies the walking, bike and road routing and the map tiles, and Open-Meteo supplies elevation.
• Leaflet draws the live map, and the rest is the Python standard library.

Grounded answers instead of confident guesses. A 3B model will happily invent a tea stall that doesn't exist, which is dangerous on a mountain. So the chat uses a tiny retrieval pipeline. Each trail's Markdown notes are split into sections, embedded, and searched by cosine similarity. The top three chunks go to the model with a strict system prompt: answer only from the notes, and otherwise say "I don't have that in my notes" and suggest asking a local guide. The index is cached in a JSON file and rebuilt only when the notes change, using a SHA-256 fingerprint of the notes and the embedding model name.

A route engine with no dependencies. route.py parses GPX, smooths the elevation, snaps waypoints to the track with haversine distance, and splits the route into stages. Time estimates use a simple rule of thumb: 4 km/h on the flat, plus an extra hour for every 500 m climbed. The same data feeds an elevation profile and an inline SVG map. That map works with no internet at all, and upgrades itself to a live Leaflet map with a topographic layer when tiles can load.

Plan once, reuse offline. For a new trek, online.py geocodes both places, asks the OSM foot router for a path, samples elevation along it, auto-generates checkpoints, and saves the result as a GPX file. Next time, even with no signal, /roadmap prashar lake opens it straight from disk.

An interactive planner. Typing /web serves a browser planner from localhost, which browsers treat as a secure origin, so live GPS works. You can choose walk, bike or cab, compare alternative routes, and scrub along the elevation profile to see each point light up on the map. Tracking shows distance left and warns you when you drift off the route. The "tips" button talks directly to the Ollama instance on your machine, so no data leaves your computer for the AI part.

I also made the AI's job deliberately narrow. It never invents the route. Distances, climbs and times are calculated by code, and the model only turns those facts and my notes into tips.

Why Does Open Innovation Matter?

Because of the trail itself. A closed API needs a connection, and the whole point of this project is the place where there isn't one. With an open-weight model on my own laptop:

• It works where the signal doesn't. The chat, retrieval and saved roadmaps all run with no internet.
• Local knowledge stays local. The "knowledge base" is a folder of Markdown files that a villager or guide can read, correct and extend. I'm not sending their knowledge to someone else's server to be retrained on.
• I can swap the model freely. One environment variable (TB_CHAT_MODEL) changes the model. When a better small model appears, Trail Buddy gets better without a rewrite.
• It costs nothing per question. A family asking twenty questions on a hike shouldn't be metered.

An honest limit: the AI is small, so it's only as good as the notes behind it. That is also why I think the open approach fits. When the model says "I don't have that," the fix is to add a line to a text file, not to wait for a vendor.

[Add your real field-test story here: where you took it, what worked, what the model got wrong, and what you changed. This is the "touch grass" part, and judges will want it.]

Thanks for reading, and go outside. 🥾