By Kennedy K. – Rwanda Chapter Head, Ecolyst.org
The Problem
East Africa is one of the most climate-vulnerable regions on the planet. Floods, droughts, and food insecurity don’t happen occasionally – they happen predictably, and people still die from them.
The IGAD Climate Prediction and Applications Centre (ICPAC) produces high-quality hazard data for the region. Flood zones, drought risk areas, rainfall anomalies – it’s all there, updated regularly, and freely available through GeoServer endpoints. The science exists.
The gap is between that data and the people who need it.
A farmer in western Kenya doesn’t check GeoServer. A community health worker in Burundi doesn’t parse GeoJSON. The hazard data sits in a format that requires technical literacy to interpret, and by the time it trickles down through radio announcements or government memos, the window to act has often already closed.
What’s missing isn’t data. It’s a translation layer – between satellite-derived hazard intelligence and the SMS that reaches someone at 6 AM, telling them to move their family before the river floods.
What Existed Before
Traditional early-warning systems in the region follow a one-way model: a meteorological agency produces a forecast, it gets published somewhere, and communities are expected to access it. This works for urban populations with internet access. It doesn’t work for the communities most at risk.
Some projects have tried to bridge this gap with mobile apps. But apps require smartphones, data plans, consistent connectivity, and the willingness to download and check an application regularly. In rural eastern Africa, that’s a narrow slice of the population.
What doesn’t require a smartphone? SMS. Virtually every adult in East Africa has a phone that can send and receive text messages. The infrastructure already exists. The challenge is
building a system that can receive those messages, understand what they mean, and turn them into actionable intelligence.
What We Built
Community Voice EWS is a two-way disaster alert platform. It does two things:
First, it pulls live hazard data from ICPAC’s GeoServer. Four WFS endpoints provide flood hazard zones, drought hazard zones, rainfall anomaly data, and multi-hazard risk areas. The system fetches this as GeoJSON on demand, normalizes severity levels to a simple low/moderate/high/critical scale, and displays it on an interactive map.
Second, and more importantly, it lets communities report what they’re seeing on the ground. Anyone with a phone can send an SMS describing a hazard — flooding in their neighborhood, signs of drought, an unusual insect infestation on crops. The system receives that message through a webhook, runs it through a bilingual NLP pipeline, classifies the hazard type and severity, and plots it on the map alongside the satellite-derived data.
The result is a two-way feedback loop. ICPAC tells you where the models predict risk. Communities tell you what’s actually happening. The intersection of those two signals is where the real intelligence lives.
The Technical Stack
The platform is built in Python (FastAPI) on the backend, with React on the frontend and SQLite for storage.
NLP Pipeline: The heart of the SMS processing is a keyword-based classification engine. The system maintains a dictionary of hazard-specific terms in English and Swahili – words like “mafuriko” (flood), “njaa” (hunger), “ukame” (drought), and “wadudu” (insects). Each hazard type has two keyword arrays (en and sw), and incoming messages are matched against them to classify the hazard type. Swahili coverage is intentionally broad rather than deep – roughly 5–10 keywords per category – because the goal is recall, not precision. It’s better to over-flag an ambiguous message than to miss a real report.
SMS Integration: Africa’s Talking is the primary SMS gateway, with Twilio as a fallback. Outbound alerts are sent via the Africa’s Talking SDK. Inbound reports arrive through a webhook endpoint (POST /api/webhooks/sms) that parses the incoming payload, runs it through the NLP engine, and stores the classified report in the database. Both paths have been tested end-to-end with real phone traffic – a phone sends an SMS, the system receives it, classifies it, and plots it on the map.
Hazard Data Ingestion: Four ICPAC GeoServer WFS endpoints are fetched as GeoJSON:
● icpac:flood_hazard: flood hazard zones
● icpac:drought_hazard: drought hazard zones
● icpac:rainfall_anomaly: rainfall anomaly data
● icpac:multi_hazard: multi-hazard risk areas
Severity is normalized from the raw hazard_class, severity, or risk_level properties to a consistent low/moderate/high/critical scale. Data is fetched on-demand, not cached, to ensure freshness.
Frontend: A React dashboard displays the hazard map with two layers, the satellite-derived ICPAC data and the crowd-sourced community reports. Users can filter by hazard type, severity, and date.
What This Means for Climate Resilience
The real value of Community Voice EWS isn’t the code, it’s the model. A two-way early-warning system that combines satellite hazard data with ground-truth community reports is fundamentally more useful than either signal alone.
ICPAC can tell you that a flood zone is at risk. A farmer in that zone can tell you the river is already two meters above normal. That second signal, the ground truth, is what makes the difference between a warning that gets ignored and one that saves lives.
The bilingual NLP pipeline matters because language shouldn’t be a barrier to disaster reporting. Swahili is spoken by over 100 million people across East Africa. An SMS system that only understands English misses a huge portion of the population it’s supposed to serve.
What’s Next
The immediate next steps are:
1. Deploy to a real community. The prototype needs to move beyond seed data. The goal is to partner with a local government or NGO in a flood-prone area of Rwanda, Kenya, or Uganda to run a pilot.
2. Expand Swahili coverage. The current keyword dictionary is shallow. A more comprehensive lexicon, ideally developed with native Swahili speakers in the target communities, would improve classification accuracy.
3. Add more languages. Kinyarwanda, Amharic, Oromo, and Somali are all spoken by significant populations in the IGAD region. Each additional language makes the system accessible to more people.
4. Move off SQLite. For any real deployment, the database needs to be persistent – PostgreSQL on a proper hosting provider, not ephemeral Render free-tier storage.
5. Build offline capability. In the areas most at risk, connectivity is unreliable. An offline-first architecture that can queue reports locally and sync when a connection is available would make the system far more resilient.
The infrastructure for disaster early warning exists. The data exists. The phones exist. Community Voice EWS is an attempt to connect them – honestly, simply, and in a way that works for the people who need it most.
About Project Owner
Kennedy K is from Kigali, Rwanda, studying at Rwanda Coding Academy. He builds climate data platforms, fintech systems, and AI tools. His projects include Community Voice EWS, Hydro Orbit (solar-powered IoT irrigation), and AFRPowerOS (African energy infrastructure data). He has 21 merged open-source contributions across 16 projects and 91 public GitHub repositories.
