TreeTrail: Bengaluru Tree Walks Curated by Local Gemma

A developer built TreeTrail, a walking app that maps Bengaluru's BBMP tree census — 72,456 trees in the bundled January 2025 South Zone snapshot — and uses Gemma 3 4B running locally through Ollama to generate tree trivia and curate short exploration loops exportable as GPX. The app shows the 450 nearest trees out of thousands in a pocket, adds observation prompts at each stop, and offers an optional live OpenStreetMap mode via Overpass for areas like Lalbagh and Cubbon Park, with no hosted inference calls or per-query AI costs.

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass https://dev.to/challenges/hacktoberfest-week1-2026-10-05 Most apps that tell you to go outside start with a goal: Walk 5,000 steps. Burn 300 calories. Hit your daily target. I wanted to try something different. What if the reason to walk was simply: Go find these five trees. So I built TreeTrail — a small walking app built around Bengaluru's public tree data. It takes a tree census, puts the trees on a map around you, lets you tap them for local-AI trivia, and turns a handful of trees into a short exploration loop you can save or export as GPX. No fitness score. No leaderboard. No gamification. Just a map full of trees and a reason to go look at them. The surprising part: there are a lot of trees The starting point is the BBMP tree census. For the current South Zone snapshot, I bundled the January 2025 public-domain dataset directly into the app. It contains 72,456 mapped trees across the dataset. When you open a small pocket around Basavanagudi, TreeTrail can find thousands of trees. For the initial view, I show the 450 nearest. That little counter — 450 shown / 6,850 found — ended up being one of my favorite parts of the demo. It makes the density of the city visible. These aren't abstract numbers in a spreadsheet anymore. They're dots you can actually go and look for. The basic loop The flow is deliberately simple: Pick a pocket → explore trees → choose a few → curate a loop → walk it. For example, start in Basavanagudi. The map fills with nearby trees. Tap one. Instead of getting a giant botanical database entry, you get a small piece of context generated locally by Gemma 3 4B running through Ollama. Then add another tree. And another. Maybe five is enough. Hit Curate loop. The model orders your selected stops into a compact exploration loop. Save it. Or export the GPX and take it with you. The point isn't to optimize the perfect route. It's to give you a reason to leave your screen. A walk with something to notice There's another small feature that matters more than I expected. At each stop, TreeTrail gives you an observation prompt. Look at the leaves. Compare the bark. Notice the shape of the canopy. Look at the tree next to it. That changes the nature of the walk. You're not just accumulating distance. You're paying attention. A 20-minute walk suddenly has a little mission attached to it: Can you find the five trees? And when you get there, you actually have something to look at. The AI is intentionally local One of the reasons I built this this way was to see how much of the experience could happen locally. The tree trivia and trail curation run on my laptop using Gemma 3 4B. There are no hosted inference calls and no per-query AI bill. That also makes the architecture a little more interesting. The tree census is local data. The model is local. The app can work from the bundled dataset without an API key. There is still an internet dependency: map tiles come from the internet, and the optional OpenStreetMap mode queries Overpass for live community-mapped data. I think being explicit about that distinction matters. "Local AI" shouldn't quietly become "the whole application is offline." Then I added OpenStreetMap TreeTrail also has an optional live OpenStreetMap mode for places like Lalbagh, Cubbon Park and Indiranagar. That gives the app a second, very different kind of open data source. The BBMP dataset is a civic snapshot. OpenStreetMap is a continuously editable community map. And the app labels the source of each tree so you're not left wondering where a particular point came from. The Lalbagh pocket is particularly fun because the OSM data there is surprisingly rich. It turns the app into something slightly bigger than a viewer for one government dataset. You can compare what different open datasets know about the same city. The data story is the point I deliberately didn't build an API layer for this prototype. The BBMP tree census is bundled directly into a Python file. No API key. No complicated ingestion pipeline. No mysterious backend. You can inspect the source data and see where the trees came from. That makes the project useful beyond the demo. BBMP did the work of counting and mapping these trees. TreeTrail is basically an experiment in asking: What else can we do with that public data once we make it human-scale? A spreadsheet can tell you that a tree exists. A map can show you where it is. A walking trail can give you a reason to go see it. The honest limitations There are a few things I don't want the demo to imply. First: the generated loop is not walking directions. It's a straight-line exploration loop. The dashed lines are a guide for the order of exploration, not turn-by-turn navigation. Second: the AI's source notes are species-level knowledge phrased by the model. They're not live research about that individual tree. If TreeTrail tells you something interesting about a rain tree, that doesn't mean the model has inspected that particular rain tree. Third: the BBMP data is a January 2025 South Zone snapshot. It's not a live, citywide inventory. And some mapped trees may be on private property. That last one is particularly important. A point on a map doesn't automatically mean you can walk up to it. Which brings me to the part I'm most interested in. I want people to try to break the map The best test isn't whether the demo works on my laptop. It's whether someone takes a TreeTrail walk and discovers something the dataset got wrong. Maybe the "tree" is inside someone's compound. Maybe it's gone. Maybe the species note doesn't match what you see. Maybe the point is technically correct but completely inaccessible. Or maybe you find an incredible tree you would have walked past a hundred times. That's the experiment. Take one walk. Pick a handful of trees. Take one photo. Tell me what TreeTrail got right — and what it got wrong. Because that's where an open-data project becomes interesting: when the map stops being an artifact on a screen and starts getting checked against the real world. Code Repo TreeTrail is built around a simple idea: use local AI to turn open civic data into something you can experience on foot. The core dataset is the BBMP tree census — a public-domain snapshot of 72,456 trees from the January 2025 South Zone census. I bundled the data directly into the Python application, so the project doesn't depend on a tree-data API or API keys. For the AI layer, I use Gemma 3 4B through Ollama, running locally on my laptop. The model has two small but useful jobs: Tree trivia — when I tap a mapped tree, the model generates a short species-level note that gives me something to notice when I reach the tree. Trail curation — after selecting a handful of trees, the model helps order them into a compact exploration loop. The rest of the application is deliberately straightforward: a map, nearby-tree filtering, stop selection, loop creation, saving, and GPX export. There's also an optional OpenStreetMap/Overpass mode for places such as Lalbagh, Cubbon Park and Indiranagar. This provides live community-mapped data alongside the bundled BBMP snapshot, with the source clearly identified. The important part is that the AI isn't trying to replace the map or the data. The data tells me where to look. The local model gives me something to look for. The walk is where I find out whether any of it is actually true. And because the inference happens locally, there is no hosted AI endpoint or per-query inference cost sitting behind every tap. There are still internet dependencies — map tiles load online, and OSM mode queries Overpass — but the core AI experience can run on my own machine. TreeTrail exists because several pieces of open technology can be connected in ways that weren't possible — or weren't nearly as interesting — as isolated datasets. The BBMP has already done the hard civic work of counting and mapping trees. OpenStreetMap provides another layer of community-maintained geographic data. Ollama makes it practical to run an open-weight model such as Gemma locally. And open-source mapping and Python tooling make it possible to glue these pieces together without building the project around a proprietary AI platform. A closed AI API could certainly generate tree trivia and suggest an order for a list of stops. But the open approach changes the economics and the relationship with the data. There is no per-query AI bill for every tree someone taps. The model runs on my machine. The tree census can be inspected and bundled with the application. The OSM data can be explored and improved by its community. More importantly, the pieces remain replaceable. The dataset can change. The local model can change. The mapping source can change. Someone else can fork the project, use a different city tree census, swap in another open-weight model, or build an entirely different experience on top of the same civic data. That's what open innovation makes possible here: the project doesn't have to end at the prototype I built. The BBMP tree census was created as civic data. TreeTrail is one experiment in making that data useful at street level. A closed API might have helped me build the demo. Open data and open AI make it possible for someone else to take the idea somewhere I haven't thought of yet.