Touch Grass: Natural Language Outdoor Discovery

Radhika Godambe — Sun, 11 Oct 2026 19:57:21 +0000

Submission for the Hacktoberfest Open-Source AI Challenge – Week 1: Touch Grass

What I Built

Finding somewhere to go outdoors shouldn't require browsing through multiple websites, filtering endless map results, or scrolling through hiking forums.

Touch Grass is an open-source, AI-powered outdoor discovery application that lets users search for trails, parks, and running clubs using natural language.

Instead of navigating multiple filters, users can simply ask:

"Show me easy shaded trails under 3 miles."
"Which parks in Austin have restrooms and allow dogs?"
"Find me a weekend run club that runs less than 5 miles."

The application uses an LLM-powered Text-to-SQL agent to translate these questions into SQLite queries, retrieve matching records, and display the results in a responsive dashboard.

The idea is simple: spend less time searching for outdoor activities and more time actually doing them.

Demo

Application Features

1. Natural Language Search

Users can enter questions directly into the search bar or choose from predefined example queries to get started.

2. SQL Query Inspector

The application displays the SQL generated by the model, allowing users to see how their natural language request was translated into a database query.

3. Dynamic Results Table

Results are displayed in a responsive table with formatting based on the returned data:

Color-coded difficulty badges (Easy, Moderate, Hard).
Readable boolean indicators (✅ Yes / ❌ No).
Trail distances in miles.
Location and activity information.

4. Loading and Error States

The interface handles loading, empty results, and invalid queries with appropriate feedback.

Example Interaction

User input:

"Show me easy trails under 3 miles with shade."

Generated SQL:

SELECT
    name,
    length_miles,
    has_shade,
    location
FROM trails
WHERE LOWER(difficulty) = 'easy'
    AND length_miles < 3
    AND has_shade = 1
LIMIT 50;

Example Results:

Trail	Distance	Shade	Location
Sunset Ridge Loop	1.8 mi	✅ Yes	Austin, TX
Lady Bird Lake	1.3 mi	✅ Yes	Austin, TX
Piedmont Park Loop	2.4 mi	✅ Yes	Atlanta, GA

The generated SQL is also visible in the interface, making the application's behavior easier to understand and debug.

Code

The project is open-source and organized as a full-stack monorepo.

GitHub Repository: (https://github.com/radhikaaa25/touch-grass)

Tech Stack

Layer	Technologies	Purpose
Backend	Python 3.11+, FastAPI, Uvicorn	REST API
AI Agent	LiteLLM, Gemini / Open-weight Llama	Natural Language to SQL
Database	SQLite3	Outdoor activity storage
Frontend	React 19, Vite, Tailwind CSS v4	User interface
Tooling	Pydantic v2, TypeScript	Data validation and type safety

Architecture

The application follows a straightforward request-response pipeline:

             User
               |
               v
      React Frontend
               |
               v
        FastAPI Backend
               |
               v
       Text-to-SQL Agent
               |
               v
      LiteLLM Model Router
               |
               v
       Generated SQL Query
               |
               v
        Query Validation
               |
               v
         SQLite Database
               |
               v
         JSON Response
               |
               v
       Dynamic Results UI

How I Built It

1. Schema-Grounded Text-to-SQL

One of the main challenges was making sure the language model generated queries using actual database tables and columns rather than inventing its own structure.

To address this, the backend retrieves the SQLite schema and includes it in the agent's system prompt.

The model receives both the database structure and a set of query-generation rules.

SYSTEM_PROMPT = f"""
You are a SQL query generator for an outdoor activities SQLite database.

DATABASE SCHEMA:
{get_schema_string()}

RULES:
1. Output ONLY a single valid SQLite SELECT query.
2. Do not include markdown, code fences, or explanations.
3. Never generate INSERT, UPDATE, DELETE, DROP, ALTER, or CREATE statements.
4. Use only the tables and columns provided in the schema.
5. Boolean columns (has_shade, has_restrooms, allows_dogs)
   use 1 for true and 0 for false.
6. Use LOWER() for case-insensitive string comparisons.
7. Always include 'name' and 'location' in the results.
8. Limit results to a maximum of 50 rows.
"""

This helps constrain the model's output and makes the generated queries more consistent with the available data.

2. Model-Agnostic Integration with LiteLLM

I used litellm to keep the application independent of a single LLM provider.

The backend can be configured to use Google Gemini, local open-weight models through Ollama, or supported cloud-hosted models through providers such as Groq.

The model can be changed through an environment variable without rewriting the agent logic.

response = litellm.completion(
    model=self.model,
    messages=[
        {
            "role": "system",
            "content": SYSTEM_PROMPT
        },
        {
            "role": "user",
            "content": question
        },
    ],
    temperature=0.0,
    max_tokens=300,
)

This also makes it possible to experiment with different models and compare their Text-to-SQL performance.

3. SQL Validation and Error Handling

Since the SQL is generated by a language model, it needs to be checked before execution.

The backend includes a validation layer that:

Removes surrounding Markdown code fences when present.
Checks that the generated query begins with SELECT.
Rejects queries that do not satisfy the expected format.
Handles SQLite execution errors using try/except sqlite3.Error.
Returns readable error messages to the frontend.

These checks provide an initial safeguard against unintended queries. For a production deployment, I would strengthen this further with SQLite read-only connections, single-statement enforcement, and stricter SQL validation rather than relying on prompt instructions or prefix checks alone.

4. Building the Frontend

I wanted the interface to feel like an outdoor discovery tool rather than a conventional database search application.

The frontend uses React, Vite, and Tailwind CSS with an earth-toned visual theme.

Design choices:

Forest greens (#1d3818 to #8dba7e), bark browns, and soft sky accents.
A prominent natural-language search bar.
Example query chips for first-time users.
A terminal-inspired SQL inspector.
Dynamically generated result columns based on the API response.
Custom formatting for distances, difficulty levels, and boolean fields.
Responsive layouts for different screen sizes.

The frontend does not need to know which database table the user is querying beforehand. It builds the results table from the returned column names and values.

This allows the same interface to display trails, parks, and running clubs without separate result components for every category.

Why Open Innovation Matters

I wanted Touch Grass to be easy to run, modify, and extend without depending entirely on proprietary services.

Three aspects of open innovation influenced the project.

1. Local Model Support and Privacy

Outdoor discovery applications can involve location information and personal activity preferences.

By supporting local models through Ollama, Touch Grass provides an option to process natural-language queries locally instead of sending them to a cloud-hosted LLM.

This gives developers more control over where their data is processed.

2. Flexibility Across AI Providers

Using LiteLLM allows developers to experiment with different supported models without changing the application's core architecture.

Someone running the project locally can choose an open-weight model, while another developer can configure a hosted provider.

The application is not tied to one model or vendor.

3. Community-Driven Outdoor Data

SQLite provides a lightweight starting point for maintaining a curated collection of trails, parks, and running clubs.

The project can be extended with additional locations, activity categories, and community-contributed datasets.

The goal is to make outdoor discovery accessible and adaptable to different cities and communities.

My Agent Session

I used Google DeepMind Antigravity during development to assist with scaffolding, implementation, and debugging.

The development process involved:

Setting up the FastAPI and React monorepo.
Implementing the Text-to-SQL agent and database integration.
Building the search interface and dynamic results table.
Resolving Python dependency and virtual environment configuration issues.
Testing backend functionality and verifying the frontend build.

Antigravity was useful for iterating across the backend and frontend while keeping the application architecture consistent.

Challenges and Learnings

The most interesting part of building Touch Grass was connecting natural-language input to structured database operations.

A few key takeaways:

Schema context matters. Providing the model with the actual database structure makes Text-to-SQL generation more reliable than relying on generic instructions.

LLM output still needs validation. Even with explicit prompting, generated SQL should be treated as untrusted input.

Model flexibility is useful. Separating the model provider from the application logic makes experimenting with local and hosted models significantly easier.

A simple interface can hide a fairly interesting backend. From the user's perspective, the entire workflow is just asking a question and viewing matching outdoor activities.

What's Next?

Some improvements I'd like to explore:

Integrating OpenStreetMap data for broader location coverage.
Adding geolocation-based searches for nearby trails and parks.
Supporting community submissions for new outdoor locations.
Improving SQL validation and database access restrictions.
Testing Text-to-SQL accuracy across different open-weight models.
Adding map-based visualization alongside the existing results table.

Prize Categories

Primary Challenge: Hacktoberfest Week 1 – Touch Grass

Featured Categories:

Best Use of Open-Source AI / Open Weights
Full-Stack Developer Experience

Built with Python, React, SQLite, and LiteLLM.

Less scrolling. More strolling. 🌿

Source code: GitHub – Touch Grass

DEV Community: Radhika Godambe