Type
Geospatial decision support
Location Impact Explorer
Case study · Static demonstrator
Open data, pointed at decisions.
The Location Impact Explorer is a geospatial decision-support demonstrator for clean-cooking programmes: a build-time pipeline turns open population rasters into H3 hexagons over Senegal, Mali and Cambodia, tiered on UN DEGURBA-aligned thresholds; the browser computes map, dashboard and registry from that bundle. All of it synthetic, and labelled as such on every screen.
3 countries · 300 synthetic records
Labelled synthetic data
The brief
Rasters in, siting evidence out.
Clean-cooking programmes choose where stove installations go, and those choices are usually made against population numbers buried in scientific rasters (GHSL, Kontur, WorldPop) built for researchers. The gap between the data existing and the data deciding is where budgets misfire.
The Explorer’s premise: give programme officers population numbers they can act on. A build-time Python pipeline cuts the rasters into H3 Res-8 hexagons of roughly 0.74 km², tiers each cell on UN DEGURBA-aligned thresholds, and ships the result as a static bundle. The browser computes everything from that bundle on load: map, dashboard, statistics and registry, with no server anywhere in the path.
Every record on screen is generated: 100 synthetic households per country, 300 across Senegal, Mali and Cambodia. Every surface carries a “Synthetic demonstration data” badge.
“The data is synthetic. The method is real.”
3
Countries · Senegal, Mali, Cambodia
300
Synthetic household records · 100 per country
0.74 km²
Per hexagon · H3 Res-8
0
Build steps on the product itself
100%
Of on-screen figures computed on load
The product
Screen by screen.
Deep navy, amber accents and a badge pinned to the corner: the Explorer looks like an operations console because it is built like one. Every layer traces back to a named open dataset. A tour of what a user actually sees.
01 / The decision map
One country, one grid.
The Senegal view layers 100 GPS-located records over admin regions, with markercluster keeping dense areas legible and a legend separating Urban, Peri-Urban and Rural. Region, town and classification filters narrow the view; layer toggles switch admin regions, districts and population density; neighbouring-country switches keep context without clutter.
02 / Operations dashboard
The programme at a glance.
Active stoves, revenue, CO₂ saved and customer counts lead into a classification donut, regional deployment bars and a fleet-status breakdown. The dashboard's own subtitle says how it works: every figure is computed from the loaded demonstration dataset, so the charts cannot disagree with the map. Nothing is pre-aggregated or hardcoded.
03 / The coverage band
Three countries, the same method.
Senegal is the pilot country; Mali and Cambodia run the same three-source classification cascade, scoped to the admin areas of each country (regions, cercles or provinces). Each map opens directly, with no signup or setup, and the shared badge sits above all three. What varies between cards is the data alone.
04 / Population metrics
Numbers behind the map.
Tracked locations, households, people covered, average household size and urban share lead a statistics page where every figure comes straight from the pilot dataset. The settlement split — Urban, Peri-Urban, Rural — comes straight from the classification cascade, and coverage growth plots cumulative locations per quarter from recorded dates.
05 / The same files, any screen
A map that survives a phone.
The demonstrator is plain HTML, CSS and JavaScript, so responsiveness is a layout job: the sidebar collapses, map controls stay reachable and the synthetic-data badge stays visible. A phone loads exactly the static files a laptop loads; there is no second build to drift out of step.
06 / The registry
Households as records.
A registry table lists each synthetic household (name, town, GPS coordinates, settlement context, stove model, dates, usage hours and CO₂ saved) with search, JSON export and import, showing how a real programme's records would read. Every row is generated, and the badge in the sidebar says so before the first row loads.
Under the surface
A method you can check.
What sits beneath every figure: one cell size for every comparison, sources you can name, and thresholds the user can read.
Hexagonal analysis cells
Population is analysed per H3 Res-8 hexagon of roughly 0.74 km², so “where” has a fixed unit and every comparison across regions and countries is like with like.
Priority-ordered sources
GHSL SMOD leads the classification, Kontur Population covers its gaps and WorldPop cross-checks the result. Sources are tried in order, never averaged, so every figure has one traceable origin.
Labelled synthetic data
A “Synthetic demonstration data” badge renders on every surface: landing, map, dashboard, statistics and registry. No screenshot of the product can pass for operational data.
One source for every number
Every count, chart and percentage is derived in the browser from the static dataset. Change the data and every figure follows; there is no second place for numbers to live.
Zero build step
The product is vanilla HTML, CSS and JavaScript with CDN-pinned Leaflet, Chart.js and Font Awesome. No bundler, no framework, nothing to rebuild: deploying means copying files.
DEGURBA alignment
The three-tier classification follows the UN DEGURBA methodology’s logic, with thresholds stated in the product: above 1,000 people per hexagon is Urban, 300 to 1,000 Peri-Urban, below 300 Rural.
The engineering
Rasters to records, at build time.
A build-time Python pipeline does the heavy lifting so the deployed product can stay static: sources resolved in priority order, cells classified on stated thresholds, households generated, bundle shipped. Nothing at runtime needs more than a browser.
01
Rasters in
GHSL SMOD · Kontur · WorldPop
Three open population sources feed the pipeline: the JRC’s SMOD settlement layer leads, Kontur Population fills coverage gaps, and WorldPop provides an independent cross-check of the classified result.
02
Hexagonal discretisation
H3 · Res-8 · ~0.74 km² cells
Continuous rasters are cut into a hexagonal grid so every settlement shares the same cell shape and area, and a decision about one region can be weighed against another without unit drift.
03
Classification cascade
DEGURBA-aligned thresholds
Each hexagon is tiered by population: above 1,000 people is Urban, 300 to 1,000 is Peri-Urban, below 300 is Rural. The thresholds ship inside the product, so the user reads them where the classification happens.▲ Thresholds stated in the interface
04
Synthetic households
100 records × 3 countries
A generator produces household records (name, town, coordinates, stove model, dates) so every interface has plausible rows to render. Nothing comes from a real programme; the badge reflects what this stage produces.
05
Static bundle
Data as files · no API
The pipeline’s output ships as static files beside the HTML. There is no server, no database and no endpoint to secure: the demonstrator runs the same from a CDN as from a laptop.
06
Computed on load
Leaflet 1.9 · Chart.js 4 · browser
The browser is the pipeline’s last stage: KPIs, charts, map layers and the registry are all derived from the bundle, so the shipped files and the rendered page cannot drift apart.
pipeline/classify.py (the classification cascade)
# pipeline/classify.py - UN DEGURBA-aligned tiers, applied per H3 Res-8 hexagon
def classify(pop):
if pop > 1000:
return "Urban" # dense settlement
if pop >= 300:
return "Peri-Urban" # the transitional band
return "Rural" # sparse
# population sources are tried in priority order:
# 1. GHSL SMOD (primary) 2. Kontur (fallback) 3. WorldPop (validation)Open inputs, open tools
Every input is an open dataset and every library is open-source and CDN-pinned. No licensed data sits anywhere in the chain, so the whole method can be inspected end to end.
Synthetic, on purpose
Generated households mean there is no personal data to protect. The demonstrator ships no real records, and the badge travels with the data.
Static by design
No server component exists in the product: files in, page out. What can be served from anywhere can also be read with view-source, which is the point.
The stack
Open-source, end to end.
A geospatial stack: open rasters in, a static bundle out, and a browser does the rest.
Leaflet 1.9
Mapping
Interactive map engine, CDN-pinned, with markercluster for dense points.
Chart.js 4
Charts
Dashboard figures drawn from the dataset itself, with no pre-aggregation step.
H3 · Res-8
Grid system
Hexagonal analysis cells of roughly 0.74 km², identical across countries.
GHSL SMOD
Primary source
The JRC settlement layer that leads the classification cascade.
Kontur Population
Fallback source
Open population tiles used where SMOD has no coverage.
WorldPop
Validation
Independent raster used to cross-check classified hexagons.
Python
Build-time pipeline
Data preparation and synthetic-household generation, run before deployment.
Vanilla JS
Runtime
No framework, no bundler: HTML, CSS and JavaScript as static files.
Why it holds up
Built to be examined.
Labelled
The badge never leaves the screen; nothing on it can be mistaken for operational data.
Open
Open datasets in, open-source libraries out: GHSL, Kontur, WorldPop, Leaflet, Chart.js and H3, all inspectable.
Reproducible
The Python pipeline regenerates the data bundle from the source rasters, so the demonstrator can be rebuilt from source at any time.
Stated limits
The scope is a demonstration. There is no live telemetry, no field operations and no real household data behind the figures.
A data demonstrator
Put your data on the map.
The Location Impact Explorer shows what open population data becomes when it is treated as an engineering problem: a fixed unit of analysis, a documented cascade and interfaces that say what they are. If your programme sits on data that deserves the same treatment, that conversation starts here.
Like what you see
Book a Production Consultation→Have data that needs a tool?
The Location Impact Explorer turns public rasters into a siting tool with an operations dashboard. If your programme needs the same engineering applied to its data, let's talk it through.
Fixed prices · Set against a written spec