-
-
Centralized alerts dashboard showing alert status, delivery, and device confirmations.
-
System status dashboard displaying backend health, data sources, device connectivity, and monitoring coverage.
-
What-If Simulation Studio for evaluating landslide risks under different environmental scenarios.
-
Alert management interface for sending targeted landslide warnings to registered devices.
-
Map view showing monitored areas and landslide risk levels across the region.
-
Critical landslide risk monitoring near Mangan, Sikkim, with contributing risk factors.
-
Area-specific risk analysis displaying risk scores, rainfall, and terrain factors.
-
Satellite-based monitoring of a selected area with its landslide risk assessment.
-
Satellite imagery view visualizing terrain conditions and monitored landslide risk zones.
-
Live monitoring dashboard displaying landslide risk zones across Northeast India using terrain mapping.
Inspiration
Northeast India sits at the confluence of three tectonic plates, receives some of the highest rainfall on Earth, and yet remains among the most underserved regions in the country when it comes to disaster preparedness infrastructure. Every monsoon season, communities in Sikkim, Assam, Meghalaya, Manipur, and neighboring states face landslides with little to no advance warning — and when warnings do exist, they often fail to reach the most vulnerable people because cellular networks collapse at exactly the moment they're needed most.
We were inspired by a deceptively simple question: what if a community could receive a life-saving landslide warning even with zero internet connectivity? That question became LandGuard AI.
What It Does
LandGuard AI is a full-stack, AI-assisted landslide early-warning, monitoring, and resilient alert distribution platform purpose-built for Northeast India.
Continuous Hazard Monitoring
- Tracks 139 real-world hazard hotspots across 8 northeastern states, clustered from the NASA Global Landslide Catalog
- Fuses live hydrometeorological telemetry (72-hour precipitation, 24-hour forecast) from Open-Meteo with cached SRTM 30m DEM elevation and slope models
- Produces deterministic, weighted risk scores (0–100) mapped to four bands: Low, Moderate, High, and Critical
- Automatically fails over to OpenWeatherMap when Open-Meteo hits cloud IP rate limits, ensuring uninterrupted live feeds
Authority Control Center (Web)
- Interactive GIS risk map with severity-coded markers, satellite/terrain base layers, and per-zone factor breakdowns
- Send Alert console with fuzzy area search, risk-level templates, configurable expiry (1–72 hours), and live Android notification preview
- Two-Person Rule & RBAC: High/Critical alerts require a second Incident Commander to approve before dispatch — preventing false alarms in high-stakes scenarios
- What-If Simulation Studio for interactive hazard drills without affecting live operations
- Real-time WebSocket delivery telemetry, FCM status, and device registry
Resilient Alert Distribution
- Firebase Cloud Messaging (FCM) for instant high-priority push to online Android devices
- Offline P2P mesh via Google Nearby Connections: phones that receive alerts relay them via BLE and Wi-Fi Direct to nearby devices with no internet — up to 6 hops deep
- Store-and-forward receipts: offline devices queue delivery confirmations and flush them back to the API when connectivity is restored
How We Built It
| Layer | Stack |
|---|---|
| Frontend | React 19, TypeScript, Vite, Tailwind CSS, TanStack Query, Leaflet |
| Backend | Node.js, Express, WebSocket (ws), SQLite / JSON AlertStore |
| Push | Firebase Admin SDK (FCM HTTP v1 data-only multicast) |
| Auth | JWT, bcrypt, role-based middleware (operator / incident_commander / admin) |
| Android | Kotlin, Jetpack Compose, Room DB, Google Nearby Connections API |
| ML Pipeline | Python 3.10, pandas, NumPy, scikit-learn (HistGradientBoostingClassifier) |
| Geospatial | rasterio, shapely, Google Earth Engine, Microsoft Planetary Computer STAC |
| Data Sources | NASA GLC, Sentinel-1 SAR, Sentinel-2 L2A, SRTM 30m DEM, Open-Meteo, OWM |
| Infra | Docker Compose, Caddy (auto TLS), Vercel (frontend preview) |
We designed a unified alert contract — a standardized payload schema shared identically across REST endpoints, WebSocket frames, FCM data messages, Android Room databases, and the offline mesh protocol — so that a single alert created by an authority operator flows seamlessly all the way down to a phone with no internet in a remote valley, and its delivery receipt flows back up.
A zero-cold-start seed architecture (seed-cache.json) ships precomputed Copernicus GLO-90 DEM terrain models and NASA GLC clusters directly inside the container image, so fresh cloud deployments boot instantly with 100% data coverage — no waiting for external APIs.
Challenges We Faced
1. Offline-first mesh networking at the application layer Getting Google Nearby Connections to work reliably as a store-and-forward relay — maintaining alert deduplication across mesh hops, preserving alert IDs across 6 relay nodes, and ensuring receipts survive disconnected round-trips — required designing a custom hop-count protocol and careful Room database conflict resolution strategy.
2. Satellite data at cloud-budget scale Ingesting Sentinel-1 SAR coherence, Sentinel-2 NDVI, and SRTM slope across 139 hotspots without a petabyte-scale compute budget meant we had to combine Google Earth Engine's serverless geospatial processing with Microsoft Planetary Computer STAC queries and offline rasterio pipelines to build a realistic feature matrix for the ML model.
3. Weather API instability in production Open-Meteo applies per-IP rate limits on cloud egress IPs, causing HTTP 429 failures during peak refresh cycles. We built a transparent dual-provider fallback pipeline — Open-Meteo → OpenWeatherMap — with spatial grid aggregation at ~0.1° resolution to minimize token consumption while keeping live 24-hour rainfall forecasts uninterrupted.
4. Firebase credential portability across environments Handling Firebase service account JSON across local, CI, and containerized environments — where credentials arrive as raw JSON, quoted Base64, prefixed environment variables, or with copy-paste artifacts — required building an adaptive credential parser that auto-detects and sanitizes all formats before initializing the Admin SDK.
5. Two-Person Rule UX without friction Designing a safety mechanism that genuinely prevents accidental Critical alerts while remaining fast enough for emergency operators under stress required careful thinking around role feedback, WebSocket-driven real-time approval notifications, and audit trail design.
What We Learned
- Real disaster systems live and die by trust and auditability — every actor, every action, every delivery must be logged
- Resilience beats speed: a warning that reaches 300 people offline is more valuable than an instant push that reaches 0 when the cell tower falls
- Geospatial ML is only as good as its data honesty — we explicitly label missing sensor readings as unavailable rather than imputing synthetic values into an emergency system
- The Two-Person Rule is a UX problem as much as a safety one
What's Next
- Integration with IMD (India Meteorological Department) real-time radar feeds
- Seismic sensor telemetry ingestion for combined earthquake-triggered landslide risk
- SMS/USSD fallback channel for feature phones with no data plan
- Expanding coverage to Himalayan zones in Uttarakhand and Himachal Pradesh
Built With
- bcrypt
- cors
- express.js
- firebase-admin-sdk
- google-earth-engine
- jwt
- leaflet.js
- lucide-react
- microsoft-planatery-computer-stac
- node.js
- numpy
- pandas
- pystac-slient
- python
- react
- recharts
- scikit-learn
- shapely
- sqlite
- tailwind
- tanstack
- typescript
- vite
- ws
Log in or sign up for Devpost to join the conversation.