PahadPath

रास्ता खुला है या बंद? निकलने से पहले जानें।

Is the road open or closed? Know before you leave.

Inspiration

Every year, lakhs of people drive into Uttarakhand's hills without knowing whether the road ahead is open.

More than 51 lakh pilgrims made the Char Dham Yatra in 2025, according to an SDC Foundation factsheet. The same factsheet links many low-footfall days to landslides and route closures.
On 20 August 2025, All India Radio reported that around 150 roads across Uttarakhand were blocked by landslides. The Gangotri highway was obstructed at eight points, including Dharasu, Harsil and Dharali, and the Yamunotri highway was closed near Kalyani and Junglachatti.

Information about these closures does exist, but it is scattered. It sits in WhatsApp forwards, police announcements, news tickers and word of mouth. It also arrives late. A driver usually finds out a road is blocked by reaching the debris.

The worst part is that mobile signal disappears exactly where landslides happen. The person who has just seen a blockage, and could warn everyone behind them, often has no network to send that warning.

We wanted to build something that works the way the mountains actually work: patchy signal, fast-changing conditions, and people who look out for each other.

What it does

PahadPath is a free, open-source web app that shows the live condition of mountain roads, segment by segment, and keeps working offline.

🗺️ A route map in traffic-light colours. Major routes are split into short segments of about 1–2 km. Each segment shows as 🟢 Clear, 🟡 Slow/Debris or 🔴 Blocked, with the time of its last confirmation.

📍 One-tap reporting. A user taps Blocked, Slow or Clear. GPS location is captured automatically, and a photo is optional. Reporting takes under 10 seconds and needs no typing, so it can be done from a stopped car.

📴 Offline-first, the core of the product.

Before a trip, the user saves a route. Its map, the last known status and nearby safe stops are stored on the phone.
A report made with no signal is queued on the device and sent automatically as soon as the phone reaches coverage, even if that is 20 km later.
One traveller who passes a blockage and then reaches signal updates the map for everyone behind them.

✅ A trust layer, so rumours don't close roads.

A segment turns red only when two or more independent reporters confirm it, or when a verified authority account (police, SDRF or PWD) marks it.
Every report decays over time, so a 6-hour-old "blocked" report slowly loses weight unless someone confirms it again.
Reporters build reputation when other people confirm their reports later.

🧭 A "Should I leave now?" card. The user picks a destination. PahadPath checks every segment on the route, together with recent report activity, and gives a plain answer: Route clear, Expect delays near Tilwara, or Blocked at Sirobagad since 2:10 pm: consider waiting.

🔓 Open road-status API. All verified status data is published as open JSON under an open licence. Hotels, taxi unions, tourism portals and other developers can embed it, and nobody has to pay for safety information.

Why existing options fall short

Today	What's missing
Navigation apps	Need live internet, and update slowly for sudden local blockages on hill roads
WhatsApp groups	Unstructured, unverified, not tied to a route, and forwarded hours later
Official bulletins	Accurate but periodic, and not shown on a route map at the moment you decide to leave
Asking at a dhaba	Works, but only once you are already on the road

PahadPath does not replace official sources. It brings them together with verified ground reports on a single map that still works offline.

How we built it

Frontend: Next.js + TypeScript, built as an installable PWA so no app-store download is needed. Styled with Tailwind CSS.
Maps: Leaflet with OpenStreetMap data. Routes are cut into segments from OSM road geometry.
Offline: a Workbox service worker caches the app shell and route map tiles, and IndexedDB stores the report queue. The Background Sync API (with a fallback for browsers that lack it) sends the queue when connectivity returns.
Backend: Supabase, using Postgres with PostGIS to snap reports to the nearest road segment and Supabase Realtime to push status changes to every open map instantly.
Trust engine: each segment has a confidence score. Each report adds weight × e^(−age/τ), where weight comes from the reporter's reputation (verified authority accounts carry the most) and τ depends on the report type (blocked reports decay more slowly than "slow traffic"). A segment turns red only when the score crosses a threshold and at least two distinct reporters agree, or when an authority marks it.
Hosting: Vercel (frontend) + Supabase (database), both on free tiers, so the service can run at near-zero cost.

Challenges we ran into

Designing for no network. Most web apps assume they are online. We had to design every screen for the offline state first, including what the map shows when its data is 3 hours old, and how to say so clearly.
Stopping false reports without killing speed. A single prank should not close a highway on the map, but a real blockage must show up fast. Getting the two-reporter rule, the time decay and authority overrides to work together took several iterations.
Matching messy GPS to the right road. In the hills, GPS can jump between switchbacks. Snapping a report to the correct segment of a road that folds back on itself needs PostGIS distance checks plus the reporter's direction of travel.
Keeping it simple. Many users will be tired drivers or first-time pilgrims. Every extra tap costs reports, so we cut the core reporting action down to one tap.

Accomplishments that we're proud of

Mapped and segmented the main Char Dham approach routes from OpenStreetMap data.
Designed an offline reporting flow where a report made with zero signal reaches every other user once the reporter regains coverage.
Built a trust model that is simple enough to explain in one sentence and strict enough to resist single fake reports.
Made everything open source from day one, including the road-status data.

What we learned

Real problems are local. The most useful project we could think of came from roads we know, not from a trending technology.
"Offline-first" is a design philosophy, not a feature you add at the end.
Crowdsourced data is only as good as its trust model, so verification had to be designed as carefully as the map.

What's next for PahadPath

SMS reporting: send "BLOCK" by SMS from a basic phone, for drivers without smartphones.
Hindi and Garhwali interface, with voice prompts.
Authority dashboard: a simple panel for police, SDRF and PWD control rooms to post official closures and expected reopening times.
Rain alerts: combine official weather warnings with segment history to flag high-risk stretches before they close.
Partnerships: taxi unions, hotel associations and Char Dham travel operators as the first reporters and users.
Beyond Uttarakhand: the same open model works for Himachal Pradesh, Sikkim, J&K and the Northeast.

Team

Yashveer — FullStack Developer — IIIT Bhagalpur, 3rd year Jatin Rawal — Backend Developer — IIIT Bhagalpur, 3rd year Himank — UI/UX & pitch — IIIT Bhagalpur, 3rd year Vikrant Rai — AI/ML — IIIT Bhagalpur, 3rd year