In Delhi NCR, "go touch grass" can be bad advice. So I built a tool that checks the air first.

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

What I Built

Every October, the advice around me in Delhi NCR quietly changes. "Go for a walk" becomes "check the AQI first." Diwali is less than a month away, and the air is about to get worse.

Checking the AQI is easy. Deciding what to do with the number is harder. Is this a good time for a walk? Would another hour be better? What if a child, or someone with a lung condition, is going out? And if I do go, where is the nearest park?

Roamwise checks the air before you go touch grass. You say who is going and what you plan to do, and it answers in one line: Good to go, Go easy or Stay in. Then it shows the cleanest daylight window in the next 24 hours and the nearest parks. It is for anyone in Delhi NCR (or any city) who wants to be outside and does not want to decode a chart first.

It gives you:

• A verdict that changes with the person and the plan. Choose "most adults" or "children, older adults, heart or lung conditions," and "a relaxed walk" or "running or hard exercise." The thresholds shift with each choice. A reading of 70 µg/m³ means Go easy for most adults on an easy walk, but Stay in for a child, an older adult or someone with a heart or lung condition.
• Open-Meteo's hourly PM2.5 forecast for the next 24 hours, with the cleanest daylight window highlighted.
• A short explanation in English, Hindi or Hinglish.
• Parks within 3 km, with walking time and a map, from OpenStreetMap.
• Voice input and an assistant, Ask Roamwise. Voice input lets users speak their outdoor-planning questions instead of typing, while Ask Roamwise answers questions about air quality, weather, and suitable times to visit nearby parks.

The challenge says the best builds make the screen the shortest part of the experience. So the page leads with one coloured banner and one sentence. The chart, parks and map are there if you want them, but the answer comes first, and then you go outside.

Taking it outside

In Delhi NCR, deciding when to go for a run isn't always as simple as checking the weather. Some mornings look foggy, evenings can feel hazy too, and by midday the sunlight makes the outdoors look more inviting. But a sunny sky doesn't necessarily mean the air is clean.

That was one of the real-life problems behind Roamwise. I wanted to make it easier to look beyond what the sky looks like and check the air-quality forecast before heading outside. The goal is to help people find a more suitable time for outdoor activities instead of relying on appearance alone.

What my friend said

I asked a friend who goes running every day to try Roamwise. He often finds it difficult to decide when to run because the air can look foggy in the morning and evening, while the daylight and sunshine can make conditions seem better.

The problem isn't just whether to go running; it's figuring out which time of day might be better for it. Roamwise is my attempt to make that decision easier by combining hourly PM2.5 forecasts with activity-specific recommendations.

What matters to me is that the app doesn't simply tell someone what they want to hear. It uses explicit rules to produce the verdict, while the AI explains it in plain language.

Demo

Search a city, check the air-quality verdict for different activity levels, explore the hourly PM2.5 forecast, and find nearby parks and a better window to head outdoors.

Try it: roamwise-4e26.onrender.com.

Code

KomalDeep355 / Roamwise

Roamwise 🌿

Check the air before you go touch grass.

Roamwise helps you decide whether it is a good time to go outdoors by showing current air-quality conditions, the cleanest daylight window in the next 24 hours, and nearby parks.

Built with Delhi NCR in mind, where "go outside" can be bad advice around Diwali, Roamwise is designed to work for other cities too.

Live demo: https://roamwise-4e26.onrender.com

Write-up on DEV:

---

The one design rule

The go / go easy / stay in verdict is computed using fixed PM2.5 rules, not a language model.

An open-weight language model explains that verdict in plain language in English, Hinglish or Hindi. If the generated explanation contradicts the verdict or makes a medical claim, Roamwise replaces it with a template explanation.

For a health-adjacent application, the language model explains the decision; it does not make the underlying safety decision.

Features

• Air-quality forecast: Hour-by-hour PM2.5…

View on GitHub

A Python and FastAPI backend with a plain web frontend. It is open source and runs locally with Ollama.

How I Built It

Air quality and weather come from Open-Meteo. Parks come from OpenStreetMap through the Overpass API. A SQLite cache cuts repeated requests and serves the last good data if a source is down.

The rule I did not give to the model

A language model does not write the verdict. It comes from fixed PM2.5 thresholds in plain Python, and the model only explains the result. This is a health-adjacent decision, and a fluent explanation is not evidence that the recommendation is right.

# (go_max, caution_max) in µg/m³ of PM2.5
THRESHOLDS = {
    ("general", "light"): (60, 90),
    ("general", "vigorous"): (30, 60),
    ("sensitive", "light"): (30, 60),
    ("sensitive", "vigorous"): (15, 30),
}

These are my application's practical heuristics, based on India's CPCB PM2.5 bands. They are not official CPCB activity-specific recommendations and not medical limits. CPCB defines its bands for 24-hour averages, whereas Roamwise applies the thresholds to hourly forecast values. They live in one dictionary so anyone can read them, change them and argue with me.

The model takes the verdict, best window, and nearest park as fixed facts and writes a few plain sentences. If its text contradicts the verdict or makes a medical claim, the app drops it and shows standard wording instead, and says which one you are reading. I tested the core decision logic against different activity levels and user sensitivity settings. The verdict is rule-based, so the AI explanation cannot override a “Stay In” recommendation.

Open-Meteo (air quality + weather) ─┐
OpenStreetMap / Overpass (parks) ───┤
                                    ▼
                  SQLite cache (stale fallback)
                                    ▼
        Fixed rules: PM2.5 thresholds, daylight, rain, heat
              ▼ verdict + windows + ranked parks
        Open-weight LLM explains it (template fallback)
                                    ▼
             FastAPI  ──►  page with chart, parks and map

Where the forecast comes from

Roamwise uses Open-Meteo's hourly PM2.5 air-quality forecast for the next 24 hours. It does not currently use a separately trained forecasting model. Its own contribution is the decision layer: applying configurable thresholds, considering relevant weather conditions, and identifying potentially better outdoor windows from the forecast data.

The open models and deployment

Locally, Roamwise uses Gemma 3 4B through Ollama. The deployed version is configured to use gemma3:4b through an OpenAI-compatible endpoint. In both configurations, the model explains the rule-based verdict rather than deciding it. The app is deployed as a FastAPI service on Render using render.yaml, with a health-check endpoint and environment variables for the model connection.

What went wrong

• The forecast-versus-verdict distinction needed care. I had to make sure Roamwise clearly separates the hourly PM2.5 forecast from the rule-based activity recommendation, rather than implying that I had trained a separate forecasting model.

• The AI needed boundaries. I wanted the assistant to explain the recommendation, not invent a more reassuring answer when the rules say “Stay In.” Keeping the verdict rule-based helps maintain that separation.

• Local and deployed configurations weren't identical. Locally, I use Gemma 3 4B through Ollama, while the Render deployment uses an OpenAI-compatible endpoint. That meant I needed to verify the deployed model and provider separately instead of assuming the local setup carried over.

• I had to be careful about what I claimed. It would be easy to describe the activity thresholds as official health guidance or imply that every feature had been thoroughly tested. I kept the distinction between practical heuristics and official guidance explicit and avoided claiming unverified test results.

What it can't do

• Air quality is a regional model estimate, not a reading at a particular park.
• The thresholds are heuristics, not medical limits.
• A park is not automatically cleaner than the street outside it. Parks are ranked by distance only, which does not show air quality.
• Forecasts can be wrong or change.
• This is a planning aid, not medical advice or a replacement for official alerts. If you have a heart or lung condition, follow your doctor's advice.

Why Does Open Innovation Matter?

1. I can swap the model. The explanation layer works with local Ollama or a hosted endpoint, so I can try different open models without touching the part that decides the verdict.

2. Local mode keeps more on my machine, but not everything. When I run Gemma locally, the choices about who is going (for example, a child or someone with a lung condition) and the explanation request are processed locally. The place searched still goes to Open-Meteo and OpenStreetMap to fetch data. On the hosted demo, the explanation request goes to the configured OpenAI-compatible API provider and is subject to that provider’s data-handling practices.

3. The rules are inspectable. The thresholds are Python code, not instructions hidden in a prompt. Anyone can read them, test them and change them. A closed API would have made that decision invisible.

4. Small and open has a cost. I haven't published a reliable benchmark comparing local Gemma 3 4B with the hosted model, so I won't pretend I have one. Models can differ in response speed and the quality of their explanations. That's why the verdict never depends on the model: the rules determine the recommendation, and the model explains it.

Prize Categories

• Best Use of Gemma: Gemma 3 4B, run locally through Ollama, generates plain-language explanations in English, Hindi, or Hinglish from fixed facts. It explains the rule-based verdict; it never decides whether going outdoors is recommended. I haven't recorded a reliable latency benchmark yet, so I won't claim a speed advantage.

• Best Use of Render: One FastAPI web service deployed using render.yaml, with a health-check endpoint and environment variables for the hosted model connection. This keeps deployment configuration separate from the application code.

• Best Use of ElevenLabs: Integrated ElevenLabs into Roamwise’s AI agent to support a more natural, voice-enabled interaction. This lets users interact with the assistant beyond traditional text-based input.

If you live in Delhi NCR, try Roamwise this week and tell me what is missing. Which city should I test next? Next, I want to rank places by more than distance, for example how close a park is to a major road.