P7 GAIA - Autonomous Control Center

Inspiration

What it does

Shows the current population density
Shows the current setup of the different health facilities
Looks at the current coverage of the population
Proposes sites around a selected hub
Ranks all the groups of proposed sites
Looks at the impact on coverage after new sites were proposed

How we built it

Constraint Optimisation Details

Objective: Maximise total daily demand served by a mobile clinic fleet while respecting per-site capacity and travel constraints.
Assumptions:
- Each Hub is based from a district hospital (24)
- Each health facility can service people within a 5 km radius
- Each new district will service at most 5 sites
- Maximum one-way travel time is 60 minutes
- Each mobile health clinic services ~1,000 people, similar to existing health centers or posts
Core Technique:
- Build candidate locations inside a hub-specific isochrone envelope generated from the MAP 2020 motorised friction raster (grid-based Dijkstra cost distance).
- Score candidates via greedy coverage: for each candidate, track which population cells fall within the configured hub catchment radius and sum residual demand.
- Run a jittered hill-climbing search (randomised swap heuristic) over the candidate pool for N iterations to converge on the best k-site subset.
- Break ties through stochastic acceptance to avoid local minima; seedable RNG ensures reproducibility when required.
Data Inputs
- Population: Meta High Resolution Population Density Maps (polars-backed parquet/CSV ingestion), filtered by demographic variant.
- Facilities: MHFR dataset (district hospitals, clinics, private facilities) providing current service supply and hub metadata.
- Friction Surface: Malaria Atlas Project motorised travel-time raster (minutes-per-metre) for realistic accessibility envelopes.
- District Boundaries: geoBoundaries ADM-level polygons to mask candidate sampling and population aggregation.
Constraint Layers
- Catchment radius (km) for both hubs and individual facilities (tunable per config).
- Maximum travel minutes from hub (converted to isochrone threshold).
- Vehicle daily capacity + average population serviced per day to compute service-days per site.
- Optional jitter radius (km) to slightly perturb candidate coordinates for robustness.
Outputs
- Ranked list of proposed sites with demand served, travel minutes, and coverage diagnostics.
- GeoJSON isochrone for frontend visualisation.
- Comparative district ranking (new) aggregating total demand served across all hubs.
Implementation Notes
- Python backend (FastAPI) orchestrates demand surface construction, reachability sampling, and optimisation loop.
- Heavy geospatial work done with geopandas, shapely, rioxarray, and in-memory numpy operations (no external GIS binaries required).
- React/Vite frontend consumes optimisation APIs, renders heatmaps, facility layers, and the new district comparison card via React Query hooks.

Challenges we ran into

Figuring out how to merge different types of data with each other (e.g., surface friction with geodata with population density)
Not having recent information about Malawi readily available (for example, to figure out the catchment values for a hospital vs. a dispensary)
Figuring out how to "intuitively" display the different maps crammed with information (still working on it)

What's next for P7 Gaia

Deploy the project so it can be accessed off-localhost 🙌
Make it more user-friendly to upload new data into this project (e.g., new population datasets, updated surface friction)
Increase the accuracy of coverage
- Make the 5 km walking radius more realistic by using the walking surface friction dataset.
- Consolidate demand with capacity (e.g., if a Gaia mobile clinic services X people per day, how many are actually in need? Are there queues of people who were not served due to lack of medical resources?)
- Account for coverage during months-long flood seasons
Increase the accuracy of need identification by using demographic and more granular district-specific health outcome data.
Set up a scheduling algorithm to show which sites to service in which order, especially if some new sites would not be serviced every week.