OpenTrips: should I go out this weekend, with a number you can check

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

CHECK OUR OPEN APP HERE: OpenTrips

Team: HONEYBEE

• Ashwin Temkar (@ashwintemkar ) and Kiranraj Chintada (@kiranrajchintada302 ).

What We Built

OpenTrips answers one question before you leave the house. Should I go out this weekend?

You type a place, two dates, and a sentence about yourself. "Beginner, bad knee, budget 3000 rupees, wants hills." You get three things back.

1. A go, caution, or wait verdict for rain and landslide risk, with the model's measured accuracy on the screen.
2. A day by day outdoor plan and a packing list from a model we fine tuned for that job.
3. A map of recorded landslides nearby, the forecast grid, and places to stay, so you can leave with the plan instead of researching it.

The screen is the planning step. The point of the plan is to close the laptop. It is for anyone planning a walk, a day in the hills, or a camp, anywhere a forecast exists. It is not a hotel trip planner. The itinerary is trails, viewpoints, and short walks sized to ability. Stays on the map are context, not the product.

Product	Outdoor go or wait, plus a plan and a packing list
Risk model	TabPFN on real NASA landslide events
Plan model	Qwen3 8B, fine tuned on Tinker
Weather and rain history	Open Meteo, no API key
Maps	OpenStreetMap and Leaflet
Hosting	Render, API and web app
Saved plans	Postgres, reopen by link, cached for no signal

Split	Majority guess	Logistic regression	TabPFN
Time, last 20 percent of each class	0.556	0.799	0.914 accuracy, 0.972 AUC
Geography, India never seen in training	0.390	0.821	0.899 accuracy, 0.956 AUC

The plan model, on 10 requests it never saw in training: base model 0 of 10, fine tuned model 8 of 10.

flowchart TD
    A[Place, dates, one sentence] --> B[OpenStreetMap coordinates]
    B --> C[TabPFN risk]
    B --> D[Qwen3 8B plan]
    C --> E[Go, caution, or wait plus accuracy]
    D --> F[Days, packing, warnings]
    F --> G[Rule checker]
    G --> H[Saved link]
    H --> I[Leave, plan cached for no signal]

Demo

Video: ADDING_SOON_THE_YOUTUBE_URL

Live app: OpenTrips

The API on a free Render instance can take about half a minute to wake up on the first request.

Screenshots

What the demo should show, in order:

1. Type a place, dates, and a constraint sentence.

2. The verdict appears with accuracy 0.899, not a buried footnote.

3. The day list, packing list, and whether the constraint check passed.

4. The map. Recorded landslides, rain grid, stays.

5. Refresh the saved link. The plan is still there.

Code

ashwintemkar / opentrips

Should I go out this weekend? Rain/landslide risk + AI trip planning, anywhere in the world. Built for Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

OpenTrips

Should I go out this weekend?

You name a place, pick dates, and describe yourself in one sentence. OpenTrips returns a rain and landslide risk verdict with the model's measured accuracy, plus a day by day outdoor plan and a packing list. The plan is for walks, hills, and camps. It is not a hotel itinerary.

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

Code	https://github.com/ashwintemkar/opentrips
Risk model	TabPFN on real NASA landslide events
Plan model	Qwen3 8B, fine tuned with Tinker
Weather	Open Meteo, no API key
Maps	OpenStreetMap

What you get

1. A verdict of go, caution, or wait, and the accuracy number 0.899 on the screen.
2. Days, distances, a packing list, and a pass or fail check against your budget and ability.
3. A map of recorded landslides nearby, the forecast grid, and places to stay.
4. A link you can reopen. A plan you…

View on GitHub

https://github.com/ashwintemkar/opentrips

File	What a judge can check
landslide_dataset.csv	3,935 training rows, events and non events, rainfall features
train_tabpfn.py	Time split and India held out split, versus majority and logistic regression
train_plan_model.py	Tinker fine tune of Qwen3 8B
compare_plans.py	Base model versus fine tuned model on held out requests
plan_examples.jsonl	The 24 outdoor prompt and JSON pairs
rule_checker.py	Budget and distance checks, used live by the API
main.py	POST /risk and POST /plan
frontend/	Form, results, map, saved plan page

How I Built It

Two services. Kiran built the Next.js app people touch. I built the data, TabPFN, the Tinker fine tune, and the FastAPI service. Open Meteo and OpenStreetMap sit in the middle. Neither needs a paid key.

flowchart LR
    U[Person] --> WEB[Next.js on Render]
    WEB --> GEO[OpenStreetMap place search]
    WEB --> RISK[POST /risk]
    WEB --> PLAN[POST /plan]
    WEB --> MAP[Map and nearby layers]
    RISK --> METEO[Open Meteo forecast]
    RISK --> TAB[TabPFN on NASA landslide rows]
    PLAN --> QWEN[Qwen3 8B fine tuned on Tinker]
    MAP --> NASA[NASA events near the pin]
    WEB --> DB[Postgres saved plan link]

sequenceDiagram
    participant P as Person
    participant W as Web app
    participant R as Risk API
    participant L as Plan model
    P->>W: Place, dates, constraints
    W->>W: Resolve the place on OpenStreetMap
    W->>R: Latitude, longitude, dates
    R->>R: Rain windows from Open Meteo
    R-->>W: Risk, verdict, accuracy 0.899
    W->>L: The sentence plus that risk
    L-->>W: Days, packing, warnings, checks
    W-->>P: Plan link they can reopen

TabPFN, on recorded events

The training table is the NASA Global Landslide Catalog plus rainfall from the Open Meteo archive. The raw export has 11,033 events in 142 countries. We kept events located within 10 km, kept all 786 India events that passed that filter, and sampled the rest down for runtime. Each event gets 1 day, 3 day, 7 day, and 14 day rainfall ending on the event date. Non events are random places and dates run through the same rainfall pipeline, plus 496 extra India non events so a held out India test actually contains both classes.

landslide_dataset.csv has 3,935 rows. It is committed so the result is not a claim judges have to take on faith.

flowchart TD
    A[NASA catalog, 11033 events, 142 countries] --> B[Keep location accuracy within 10 km]
    B --> C[786 India events kept in full]
    B --> D[960 events sampled from the rest of the world]
    C --> E[Open Meteo archive rain]
    D --> E
    E --> F[1, 3, 7, and 14 day rainfall]
    G[Random non events, same rain features] --> H[Plus 496 India non events]
    F --> I[landslide_dataset.csv, 3935 rows]
    H --> I
    I --> J[TabPFN fit at API startup]

flowchart LR
    subgraph timeSplit [Time split]
        T1[Older rows of each class] --> T2[Train]
        T3[Last 20 percent of each class] --> T4[Test]
    end
    subgraph geoSplit [India held out]
        G1[Every country except India] --> G2[Train]
        G3[India events and India non events only] --> G4[Test]
    end
    T2 --> M[TabPFN versus majority versus logistic regression]
    T4 --> M
    G2 --> M
    G4 --> M

flowchart TD
    R[Live forecast rain plus latitude and longitude] --> P[TabPFN probability]
    P --> W{Score}
    W -->|above 0.6| WAIT[wait]
    W -->|above 0.3| CAUTION[caution]
    W -->|otherwise| GO[go]
    WAIT --> UI[Shown with accuracy 0.899]
    CAUTION --> UI
    GO --> UI

At request time the API pulls the live forecast for those same rainfall windows and asks TabPFN for the probability of a landslide style event. Above 0.6 is wait. Above 0.3 is caution. Otherwise go. The number on the card is the geography split, 0.899. Precision and recall stay blank, because we did not compute them.

The first evaluation runs looked strong and were wrong. One split had no India non events, so the model was mostly saying "event." We fixed the data and published the number from the fixed split. The time split is stratified too. The last 20 percent of each class by date, not one global sort that dumped almost all of one class into the test slice.

Tinker, on an open weight model

The plan is not a second call to a general chat model. The base model is Qwen/Qwen3-8B, which is open weight. We fine tuned a LoRA of rank 16 on Tinker.

Training data is 24 hand written prompt and JSON pairs. Places include India, the US, the UK, Switzerland, Nepal, Japan, Peru, New Zealand, Kenya, France, Iceland, and South Africa. Constraints include a bad knee, asthma, an elderly parent, a toddler, fear of heights, and pregnancy. The instruction prefix is the same at training time and at request time.

The first run was a single gradient step. The model still wrote chain of thought and ignored the JSON. A 20 epoch loop fixed that. The model then repeated the answer until the token limit, because it never learned to stop. We keep the first balanced JSON object instead of training again.

A rule checker scores each plan. Valid JSON, at least one day, a packing list, budget at or under the number in the sentence, and distance per day inside a cap inferred from words like beginner or advanced. Held out result:

	Pass rate
Base Qwen3 8B	0 of 10
Fine tuned checkpoint	8 of 10

The live /plan route runs that checker. checks_passed is the checker result. It is not hardcoded to true.

Checkpoint: tinker://4deeaa51-09a3-5d86-8281-29ad275d2c0c:train:0/sampler_weights/opentrips-plan-v1

What the app does around those two models

The form resolves the place with OpenStreetMap Nominatim, then calls /risk and /plan. The results page shows the verdict, the accuracy, the itinerary, and a Leaflet map. Map layers are nearby NASA landslide points, an Open Meteo weather grid, and stays ranked by distance and by how close they are to a recorded landslide. A plan can be saved and reopened by link. A service worker caches a plan page you already opened, so that page still loads with no signal.

That is the offline behavior. The models do not run on the phone in the forest. The plan is made before you leave, then cached.

Why Does Open Innovation Matter?

A closed chat API can write a pleasant itinerary. It cannot show a measured error rate on landslide records it was never trained on, and you cannot ship the training table next to the code.

Closed default	What open made possible
Ask a hosted chat model if the weekend looks fine	TabPFN on a public CSV of real events
Labels the author wrote, then a model that copies them	Labels are recorded reports, with a majority baseline and a logistic regression baseline
One country, no held out region	Trained with India removed, tested only on India, 0.899 accuracy
A base model that chats	Fine tuned open weight Qwen3 8B that emits JSON, 8 of 10 versus 0 of 10
Weather behind a paid key	Open Meteo, no key
Maps behind a paid vendor	OpenStreetMap
Model swap means a new product	The CSV, the checker, and the API stay. The checkpoint can change

Qwen3 8B weights are public. Tinker let us change them for this task and keep the checkpoint. TabPFN let us treat a few thousand rows as a classifier without standing up a training cluster. The dataset is in the repo so someone else can rerun the comparison.

We do not claim the phone runs the model with no signal. A new plan needs the server, because the forecast and the models run there. The honest offline piece is the saved plan you already opened.

Prize Categories

• Best Use of TabPFN. The risk score is TabPFN on historical landslide rows. Baselines are in the table above. Accuracy 0.899 is on every result.
• Best Use of Tinker. Qwen3 8B fine tuned to write the plan. Held out pass rate 8 of 10 against 0 of 10 for the base model.
• Best Use of Render. The FastAPI model service and the Next.js app are both hosted on Render.

Thanks for reading. If the verdict says go, close the tab.

Comments

[Preethi Gorle]

Such a neat concept for anyone who loves spending their weekends outside! Getting a clear 'go or wait' verdict along with local trail and weather details all in one place makes planning so much easier. Awesome work👍️