Platform overview

This section is the technical documentation for the IDS-DRR components, geared at teams looking to either contribute to the codebase or adopt the platform for their own region.

Is this for me?

IDS-DRR adapts to your region’s data, language, and branding.

The platform is designed for teams that:

• Operate (or partner with) a sub-national disaster management authority or equivalent body.

• Want to publish a public-facing risk-analytics website backed by their own data.

• Have or can acquire administrative boundary geometries (GeoJSON) and periodic indicator data (monthly is typical) for hazard, exposure, vulnerability, and coping-capacity factors.

• Have a developer (or contractor) comfortable with Docker, Django, Node.js, and basic geospatial tooling.

Two reference deployments demonstrate this:

• India: The original deployment, covering Assam, Bihar, Himachal Pradesh, Odisha, and Uttar Pradesh. Lives in ids-drr-india-plugin (backend config and Django plugin) and ids-drr-india-branding (frontend branding package).

• Paraguay: A multilingual (Spanish and Guaraní) deployment showing portability to other countries and languages. The ids-drr-paraguay-data (backend) and ids-drr-paraguay-branding (frontend) directories live within open-contracting/data-support.

Platform components

Component	Repository	Docs	Description
Frontend	IDS-DRR-Frontend	Frontend	User-facing web application with interactive maps and dashboards
Data Management	IDS-DRR-Data-Management	Data Management API	Backend APIs for analytics and risk data
Risk-score model	risk-score-model-generic	Risk model	Generic, methodology-driven scoring model used to produce indicator values
DataSpace Backend	DataSpaceBackend	DataSpace Integration	Datasets catalog, search, and chart visualisations (optional)
QA Automation	IDS-DRR-QA-Automation	QA & Automation	Automated testing and quality assurance (optional)

Quick-start

The IDS-DRR repository ties the core platform together via its docker-compose.yml file. Frontend, Data Management, and the risk-score model are git submodules of that repository; per-deployment branding/data packages are separate repositories to clone or create alongside, as needed.

git clone --recurse-submodules https://github.com/CivicDataLab/IDS-DRR.git
cd IDS-DRR

docker compose up -d --build

docker exec context_layer_Backend python manage.py makemigrations
docker exec context_layer_Backend python manage.py migrate
docker exec context_layer_Backend python manage.py import_geojson
docker exec context_layer_Backend python manage.py import_indicators
docker exec context_layer_Backend python manage.py import_data

The frontend will be available at http://localhost:3000 and the backend API at http://localhost:8000. No .env files are needed; all services have sensible defaults.

Localizing IDS-DRR

Adapting IDS-DRR to your region involves four pieces of work. The platform handles schema enforcement, query caching, and rendering; adoption is about producing the right inputs and branding.

1. Assemble administrative boundaries. Collect GeoJSON for each geography level you want to show (e.g. district, sub-district). manage.py import_geojson stores these as PostGIS MultiPolygons.

2. Prepare indicator data. For each region, produce two CSVs: indicator definitions in the fixed 8-column schema, and indicator values indexed by object-id × timeperiod in the data CSV format. The values come from the risk model, run by you or supplied by whoever owns the methodology for your region.

3. Write the backend configuration. A config.toml ties together the GeoJSON, the per-region CSVs, the indicator whitelist, and any feature flags. See Data Management → Configuration.

4. Build a frontend branding package. A small TypeScript npm package supplies the logo, hero imagery, region list, locale messages, tile-layer URLs, etc. See Frontend → Configuration.

The India and Paraguay deployments referenced above are working examples of all four pieces, end-to-end. You can clone either as a starting template.

Keeping data fresh

Once live, refreshing data means updating the input files and re-running the importers:

docker exec context_layer_Backend python manage.py import_indicators
docker exec context_layer_Backend python manage.py import_data

import_data deletes existing rows for the affected geographies and time periods before reinserting, so it’s safe to re-run for the same period after a correction. Most deployments run this on a monthly schedule via cron (or another scheduler) after their upstream risk-model pipeline produces a new CSV.

Production deployment checklist

The platform is a stock Django + Next.js + PostgreSQL/PostGIS + Redis stack; a production setup follows the usual patterns for that stack. Things to confirm before going live:

• [ ] Set DJANGO_ENV=production, generate a real SECRET_KEY, and populate ALLOWED_HOSTS for the backend (see Data Management → Production).

• [ ] Set NEXT_PUBLIC_DATA_MANAGEMENT_LAYER_URL and SITE_URL on the frontend to your public hostnames (see Frontend → Environment Variables).

• [ ] Front the frontend and backend with a reverse proxy that terminates TLS (nginx, Caddy, Traefik, or a managed load balancer).

• [ ] Configure a backup strategy for the PostGIS database. pg_dump of the postgres database is sufficient for most deployments, since all data is reproducible from the source CSVs.

• [ ] Confirm Redis persistence settings match your cache-warmth requirements (the default in-memory mode is fine; data is re-cached on first request after eviction).

• [ ] (Optional) Wire up Sentry for runtime error reporting.

• [ ] (Optional) Wire up analytics and verification tokens via environment variables.

Privacy, accessibility, and security

• Privacy: The platform processes only public administrative data, no PII. Analytics (Google Analytics, Hotjar) are off by default; each requires an explicit environment-variable opt-in per deployment. The DataSpace integration, when enabled, can host published datasets but inherits whatever privacy posture that service is configured for.

• Accessibility: Built with accessible component primitives (opub-ui, react-aria). Keyboard navigation and ARIA semantics are part of the component library’s contract. Choropleth maps include a legend and offer a tabular view of the same data.

• Security: Report vulnerabilities to info@civicdatalab.in. Component secrets (database password, Django secret key, Sentry tokens) live in environment variables, never in config.toml or the branding package.

• License: All components are licensed under GNU Affero General Public License v3 (AGPL-3.0). Each component repository includes its own LICENSE file. Deployments that customise the code and offer it as a service must make their modifications available under the same terms.

Contributing

See Contributing for issue trackers and contact information, and Development for design notes for code contributors.