The previous paper in this series named the ambition plainly: a real, 1:1 digital twin of Nairobi, and admitted the first render — the CBD, Overpass-fetched, roughly 1,026 buildings — was "the first, smallest, most visible piece" of it, honestly labeled as a beginning. This paper is about what it took to stop that beginning being the whole thing.
In plain terms: the old map showed about a thousand buildings in the city center. The new one shows every building in greater Nairobi — 1.27 million of them — and still loads fast, because it only sends your browser the part of the city you're actually looking at. This paper explains how, and what it deliberately doesn't claim.
Don't load the city — load what's visible. 8,536 tiles, 400m each; only the viewport streams.
What "the CBD extract" actually was
The v1 pipeline (scripts/fetch_nairobi_osm.py) queries the Overpass API — OpenStreetMap's live query interface — for a roughly 1.5km bounding box centered on the midpoint between KICC and Times Tower, pulls every tagged building and road inside it, simplifies the road geometry with a Douglas-Peucker reduction, and writes the result as a single JavaScript module the Three.js scene imports directly. It works well at that scale: 1,026 buildings, 443 road segments, loaded once, held entirely in memory. It does not work at city scale, for a reason that has nothing to do with OpenStreetMap specifically — no browser is loading a million-row JavaScript array on every page visit, regardless of source.
Scale changes kind, not just degree: at a thousand buildings the problem is drawing; at a million, the problem is deciding what not to send.
Choosing a data source for 1,600 square kilometers of city
Three free, commercially-usable building-footprint datasets cover Kenya:
- Google Open Buildings v3 — 1.8 billion ML-detected building outlines across Africa, South Asia, and Latin America, derived from 50cm satellite imagery, distributed as S2-tiled CSV with WKT geometry.
- Microsoft's
KenyaNigeriaBuildingFootprints— a second, independently-trained ML model's footprints for the same two countries. - OpenStreetMap — human-traced, and the only source of the three with attribute richness (names, building type, sometimes height) beyond a bare footprint.
Rather than picking one, we used Overture Maps — think of it as the three datasets above merged, de-duplicated, and republished quarterly as one file anyone can query. It's a Linux Foundation project backed by Amazon, Meta, Microsoft, and TomTom, distributed as cloud-native GeoParquet (a columnar file format queryable straight from cloud storage, no full download needed) on S3. The practical advantage is not just deduplication: Overture's own CLI resolves a STAC catalog to fetch only the files intersecting a requested bounding box, rather than requiring a client to reason about global tile partitioning directly. A bounding-box query for greater Nairobi (36.65–37.10°E, -1.45–-1.16°N) returned in minutes what would otherwise have meant hand-rolling S2-cell selection logic against a 178GB global dataset.
The extract: 1,277,511 building footprints, plus a separate 3,782-feature land-use layer (residential blocks, 232 schools, 74 hospitals, industrial zones, farmland) — the closest thing to open zoning data that exists for Nairobi, since no authoritative digital zoning dataset does.
Why "1:1" cannot mean "one file"
The CBD extract's whole-file-load approach doesn't scale by roughly three orders of magnitude, which is the actual gap between 1,026 buildings and 1.28 million. The fix is the same one every map you've ever used already applies to imagery: don't load the world, load what's visible.
The whole trick of "1:1 but fast" is refusing to confuse having the city with sending the city.
build_nairobi_tiles (a new Django management command) reads the raw Overture extract, computes each building's centroid, minimum-rotated-footprint dimensions, and rotation via Shapely, and buckets buildings into a 400-meter grid anchored on the same KICC/Times Tower midpoint the v1 scene uses — so both pipelines agree on what "center" means. Each grid cell's buildings are serialized as compact JSON and written as one row in a flat SQLite file, indexed by (tile_x, tile_y). The result: 8,536 tiles, 68.5MB total, averaging 150 buildings per tile in the dense core and far fewer at the metro's edges.
A new Django endpoint, /nairobi/tiles/<tx>/<ty>.json, serves one tile per request — a single indexed SQLite SELECT, cacheable for an hour since tiles only change when someone reruns the pipeline. The frontend (NairobiCityMap, a MapLibre GL island) computes which tiles intersect the current viewport on every moveend event, fetches only the ones not already loaded, and accumulates them into a single GeoJSON source rendered as a circle layer colored by height-estimate confidence (see the companion paper on that heuristic). A hard cap (400 tiles per request batch) falls back to "zoom in" messaging rather than allowing a fully-zoomed-out view to trigger thousands of simultaneous tile fetches.
A deliberate exclusion: this data does not live in the production database
nairobi_tiles.sqlite3 is not a Django model, has no migration, and is never written to Postgres — the database every other Flux service on the shared droplet also uses. This was a specific choice, not an oversight: 1.27 million rows of read-mostly, wholesale-regenerated geographic data is a poor fit for a relational database shared with transactional workloads (contact forms, waitlist signups, billboard rentals) on a capacity-constrained single server. A flat file, rsynced into place and read directly, keeps this dataset's footprint isolated and makes "delete it and regenerate" a genuinely safe operation, which "drop 1.27M rows from a shared production table" is not.
What this is not, yet
Three honest limitations, in order of how much they matter:
First, and most significant: building heights in this dataset are almost entirely estimated, not measured. Only 4,203 of 1,277,511 buildings (0.3%) carry a direct height or floor-count attribute from any of Overture's source datasets. The remaining 99.7% are estimated by a confidence-tiered heuristic described in a companion paper — a deliberate, provisional stand-in for real height data (Google's Open Buildings Temporal raster, validated to 2.5m accuracy specifically for Nairobi in peer-reviewed research) that requires Google Earth Engine access not yet provisioned.
Second, this is real-data scale, not hand-crafted visual polish. A project like cannoneyed's Isometric NYC — an explicit stylistic inspiration for this work — is fundamentally an art-generation pipeline: a fine-tuned image model, rented GPU inference, months of manual correction on water and vegetation rendering. What's described here is a different kind of achievement — a real-data pipeline at a scale that project's satellite-derived tiles didn't attempt to match building-by-building — not a claim to have matched its visual craft. Conflating the two would misrepresent both.
Third, informal settlements — Kibera, Mathare, Mukuru, and others — are included in this dataset, and a companion paper documents specifically how much of their coverage depends on which source you'd have used if you'd stuck with OpenStreetMap alone.
What this buys, concretely
Every real street name that surfaces on the billboard inventory map (/nairobi/billboard/map/) — Uhuru Highway, Kenyatta Avenue — is a byproduct of this same Overture road/building data being real rather than illustrative. The tiling architecture built here is reusable for anything else that needs to stream large geographic datasets to a browser without loading them whole: transit stops, water infrastructure, flood-risk zones, the kind of live institutional data the previous paper in this series argued is the actual point. The render is still not the twin. But it now covers the city the twin is supposed to be of, not a fraction of it.
Data & methods availability
Buildings and land-use are from Overture Maps release 2026-06-17.0 (CC-BY / ODbL), fetched with the overturemaps CLI for bbox 36.65–37.10°E, −1.45–−1.16°N. The tiling pipeline is build_nairobi_tiles in the Flux repository; the tile store it emits is a single SQLite file (8,536 rows, 68.5 MB) regenerated wholesale on each run, so every figure in this paper is reproducible from public data with one command. Counts reported were produced by that pipeline on 13 July 2026.
Companion papers
This is the first of three papers on the v2 pipeline: WP·who-is-missing-from-the-map decomposes the merged dataset by source and shows what OpenStreetMap alone would have missed; WP·estimating-what-we-dont-know documents the height-estimation heuristic and its confidence tiers. A first-person process account, dead ends included, is in Building Nairobi a Second Time.
