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.
Don't load the city — load what's visible. 8,536 tiles, 400m each; only the viewport streams.
1. What the pipeline proves, and what the companion papers carry instead
This is an engineering paper, and the claim it makes is a narrow, specific kind.
What it argues from. A described pipeline (build_nairobi_tiles), the data it consumes (Overture Maps' buildings and land-use layers, with their own named upstream sources), and the architecture it produces (a tiled flat-file store served over a thin endpoint). Every count reported below — 1,277,511 buildings, 8,536 tiles, 68.5MB — is a direct output of a command that ran against public data and that anyone can rerun, which is the strongest kind of claim available to this paper and the one it leans on hardest.
What it does not argue from. It does not argue from building-height accuracy, which is a different dataset and a different paper's subject.1 It does not argue from settlement-level source composition, which is measured and sourced separately.2 And it does not argue, on its own evidence, that merging three building-footprint sources produces a correct picture of the city — only a more complete one than any single source, which §7 and §9 both qualify carefully against a 2024 peer-reviewed finding that these sources are not interchangeable with each other.3
What would refute it. Given in full in §10. The sharpest version: if a rerun of build_nairobi_tiles against the same Overture release produces a materially different building count or tile-store size than reported here, either the pipeline is not actually deterministic against its stated inputs, or this paper's own reported figures are wrong — and either finding would need fixing before anything downstream should trust this paper's numbers.
2. 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.
3. Choosing a data source for 1,600 square kilometers of city
Three free, commercially-usable building-footprint datasets cover Kenya, and each has a documented history worth being precise about rather than treating as interchangeable background infrastructure.
Google Open Buildings began as a continental model: a 2021 Google Research paper trained a U-Net-based detection pipeline on 100,000 satellite images and 1.75 million manually labeled building instances across Africa, producing an initial release of 516 million Africa-wide footprints from 50cm imagery.4 The dataset has since grown substantially past that original scope. The current v3 release Google documents covers five regions — Africa, South Asia, South-East Asia, Latin America and the Caribbean — totaling roughly 1.8 billion detected footprints across 58 million square kilometers, still at 50cm source resolution, licensed CC-BY-4.0.5 The 516M figure is the peer-reviewed paper's own reported result for the original Africa-only model; the 1.8B figure is the current dataset's own stated scope, which I have not seen independently re-verified in a peer-reviewed paper and am citing to the dataset catalog directly rather than attributing to the 2021 paper.
Microsoft's Building Footprints is the second ML-detected source, released as a pair of per-country extracts — KenyaNigeriaBuildingFootprints — containing 50.5 million buildings for the two countries combined, detected from Maxar satellite imagery collected 2020–2021, licensed under the Open Data Commons Open Database License.6 It is an independently trained model from a different vendor, which matters for exactly the reason independent measurements usually matter: where Google's and Microsoft's detections agree on a building, that agreement is some evidence the building is real; where they disagree, at least one model is wrong, and merging exposes the disagreement rather than hiding it inside a single vendor's confidence score.
OpenStreetMap is the third, and the only one of the three with attribute richness — names, building type, sometimes height — beyond a bare footprint, because it is produced by a person who looked at the place rather than a model that inferred it from a satellite. It is also the source with the most sharply uneven coverage: a 2023 peer-reviewed study of global OpenStreetMap building completeness finds organized humanitarian mapping campaigns, not steady institutional attention, account for the majority of edits in under-resourced regions — Sub-Saharan Africa's building completeness is 51.1% explained by organized humanitarian mapping specifically.2 A companion paper checks exactly this unevenness for two specific Nairobi settlements and finds it holds.
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.
4. 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.
5. 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.
6. What the merge actually buys, measured rather than assumed
Section 3 asserted that merging sources is more complete than relying on any one. That assertion deserves its own evidence rather than standing on intuition, and the evidence exists one layer down from this paper's own pipeline, in a companion paper that decomposes two specific Nairobi settlements by contributing source.
For Kibera, OpenStreetMap alone supplies 82% of the merged dataset's buildings — a volunteer-mapped settlement where the single-source and merged pictures are close to each other. For Mathare, OpenStreetMap alone supplies only 16%; the remaining 84% exists in the merged dataset specifically because Google's and Microsoft's ML models detected it independently of any volunteer campaign. A pipeline built on OpenStreetMap alone would have rendered Mathare at roughly a sixth of its actual building density relative to Kibera, not because Mathare has fewer buildings, but because it has had less volunteer-mapping attention — exactly the dynamic the 2023 OpenStreetMap-completeness study predicts and the companion paper measures directly for this specific pair of settlements.2
That is the concrete, checkable version of "the merge buys completeness," and it is a stronger claim than the abstract argument in §3 on its own. It is not, however, a claim that the merge buys accuracy in the sense of matching ground truth — only that it buys presence, which §7 takes up as the limit of what merging can be credited for.
7. What merging does not fix
The 2024 peer-reviewed comparison of African building-footprint products is worth engaging directly rather than only citing for the completeness argument in §3, because its central finding complicates this paper's own methodology rather than simply supporting it. Chamberlain, Darin, Adewole, Jochem, Lázár and Tatem compared Ecopia/Digitize Africa, Google (v2), Microsoft and OpenStreetMap building-footprint products across every African country and found, in their own words, that "the available building footprint data products are not interchangeable," with "clear differences in counts and total area of building footprints between the assessed data products, as well as considerable spatial heterogeneity in building footprint coverage and completeness."3
That finding does not contradict this paper's choice to merge three sources rather than pick one — merging is precisely the response to non-interchangeability, since it does not require choosing the one correct product. But it does mean the merged dataset this pipeline produces is not a ground truth either. It is a composite of three products the literature says disagree with each other in ways that vary by place, and Overture's own deduplication logic — which source wins when two disagree, how a near-duplicate footprint from two models gets resolved into one — is itself a set of editorial choices this paper's pipeline inherits without auditing. The companion paper's Kibera/Mathare comparison is a spot-check of this composite in exactly two places, not a general audit of how Overture's merge logic performs across the whole metro.
8. 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 that was, at the time this pipeline first shipped, blocked on infrastructure access not yet provisioned, later resolved and reported in a third paper with a genuinely surprising result about which of two "measured" height sources is actually more trustworthy.
Second, this is real-data scale, not hand-crafted visual polish. A project like Andy Coenen's Isometric NYC — an explicit stylistic inspiration for this work — pursues a different goal: an AI image-generation pipeline (Google's Nano Banana model) converting satellite imagery and 3D geometry into stylized isometric pixel art tile by tile, with the project's own account citing well over 200 hours of manual auditing and correction to get the generated tiles usable.7 What's described here is a different kind of achievement — a real-data pipeline at a scale that project's tile-by-tile generation approach did not 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.
9. Objections I take seriously
"A merged dataset from three non-interchangeable sources is not obviously better than the best single source — it might just average away the signal that any one source got right." This is the most serious objection to this paper's own methodology, and §7 raises it directly rather than wait for a reader to find it. The honest answer is that this paper does not have, and does not claim, a validated ranking of Overture's merge logic against each contributing source individually. What it has is the narrower, checkable result in §6: for two specific settlements, the merge recovers buildings that the single most obvious default choice (OpenStreetMap alone) would have missed almost entirely. That is evidence for completeness, not for correctness, and the two are not the same claim.
"The 1.8 billion figure for Google Open Buildings is doing more work in this paper than its sourcing supports." Partly fair. The peer-reviewed 2021 paper reports 516 million footprints for an Africa-only model; the 1.8 billion figure is the current dataset's own stated scope across five regions, documented by Google but not, as far as I can establish, independently re-verified in a peer-reviewed update to the original paper. §3 states this distinction explicitly rather than letting the larger, more impressive number borrow the first number's peer-reviewed status.
"Flux has a commercial interest in this conclusion." Flux sells the Nairobi digital twin this pipeline is part of, and a city-scale building dataset is a direct input to that product's value. The conflict is real and worth stating without softening. The mitigation available is the same discipline §1, §7 and this section apply throughout: every quantitative claim in this paper is either the pipeline's own reproducible output or a citation to a specific, checked source, and the paper states plainly, more than once, where its own methodology's limits are rather than only where its results are impressive. A reader does not have to trust Flux's motives to check whether build_nairobi_tiles actually produces 1,277,511 buildings from the stated Overture release — that is a reproducible claim regardless of who is making it.
"Excluding this data from the production database is a convenience decision dressed up as an architectural principle." There is something to this. The decision in §5 was made under real capacity constraints on a specific shared server, not derived from a general theory of when geographic data belongs in a relational database. I think the reasoning generalizes reasonably well — wholesale-regenerated, read-mostly geographic data is a known bad fit for OLTP databases — but I am not claiming this paper validated that generalization against any alternative architecture; it describes the choice made and the specific constraint that motivated it.
10. What would falsify this
Stated as commitments, in decreasing order of how much damage each would do to this paper's claims.
A rerun of build_nairobi_tiles against the stated Overture release (2026-06-17.0) for the stated bounding box produces a materially different building count, tile count, or tile-store size than reported in §3–§4. That would mean either this paper's reported figures are wrong or the pipeline is not deterministic against its own stated inputs — either way, the paper's central engineering claim would need correcting before anything built on it should be trusted.
A broader audit of Overture's merge/deduplication logic, across more of the metro than the two settlements the companion paper checked, finds the merged dataset is not meaningfully more complete than the best single source for most of the city. That would falsify this paper's central justification for merging over picking one source, and would need to be weighed against §6's narrower, settlement-specific result rather than simply overriding it.
An independent peer-reviewed update to Google Open Buildings' dataset documentation reports a current footprint count materially different from the 1.8 billion figure this paper cites to the dataset catalog. That would not touch this paper's own Nairobi-specific pipeline results, but it would require correcting §3's background claim about the dataset's current scope.
The tiling architecture in §4 is shown to fail at a load level this paper does not test — for instance, concurrent requests at a scale this single-server deployment has not been subjected to. That would falsify an implicit claim this paper makes by omission (that the architecture is production-ready as described) without touching the building-count or merge-completeness claims at all.
11. Limitations, and what this paper does not claim
The merged dataset's accuracy claim stops at completeness relative to a single obvious alternative — nothing stronger is asserted here. §7 and §9 both say so directly, and the 2024 Chamberlain et al. finding that these products are not interchangeable applies to Overture's own inputs as much as to the choice between them.
It does not claim building heights are measured; §8 states this is the dataset's most significant limitation and names the two companion papers that take up the estimation and later measurement separately.
It does not claim the architectural choice in §5 generalizes to every geographic dataset on every infrastructure; it describes one choice, made under one set of real constraints, that this paper believes is reasonable but has not tested against alternatives.
It does not claim visual or stylistic parity with other building-scale city-visualization projects; §8 states plainly what this pipeline is not attempting to match.
And it does not claim a validated audit of Overture's own internal merge/deduplication logic; the companion paper's two-settlement check is a spot-check, not a metro-wide audit, and §7 and §10 both say so.
12. 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: WP28 decomposes the merged dataset by source and shows what OpenStreetMap alone would have missed; WP29 documents the height-estimation heuristic and its confidence tiers; WP32 reports what happened when the real height data finally arrived. A first-person process account, dead ends included, is in Building Nairobi a Second Time.
Appendix A — Evidence table
| # | Claim used in this paper | Value | Source |
|---|---|---|---|
| 1 | Buildings in the v1 CBD-only render | 1,026 | Internal pipeline measurement |
| 2 | Buildings in the v2 metro-wide extract | 1,277,511 | Internal pipeline measurement |
| 3 | Land-use features in the v2 extract | 3,782 | Internal pipeline measurement |
| 4 | Tile-store size and tile count | 68.5 MB, 8,536 tiles | Internal pipeline measurement |
| 5 | Google Open Buildings — original Africa-only model, peer-reviewed count | 516,000,000 footprints | Sirko et al. 20214 |
| 6 | Google Open Buildings v3 — current stated scope, 5 regions | ~1,800,000,000 footprints | Google Open Buildings v3 dataset catalog5 |
| 7 | Microsoft Kenya+Nigeria Building Footprints — total buildings | 50,500,000 | Microsoft KenyaNigeriaBuildingFootprints6 |
| 8 | Sub-Saharan African OSM building-edit share from organised humanitarian mapping | 51.1% | Herfort et al. 20232 |
| 9 | Kibera buildings sourced from OpenStreetMap (companion measurement) | 82% (6,706 of 8,130) | WP28 |
| 10 | Mathare buildings sourced from OpenStreetMap (companion measurement) | 16% (794 of 5,061) | WP28 |
| 11 | African building-footprint data products found not interchangeable (counts/area) | — (qualitative finding) | Chamberlain et al. 20243 |
| 12 | Whether Overture's internal merge/deduplication logic performs consistently across the whole metro, not just two settlements | — | — |
| 13 | Concurrent-request load the tiling architecture in §4 can sustain in production | — | — |
| 14 | Accuracy (not completeness) of the merged dataset against an independent ground-truth building census for Nairobi | — | — |
Appendix B — Citation register
CITATION-NEEDED — Overture merge/deduplication performance metro-wide. Appendix A row 12. §7 and §10 both flag that the companion paper's two-settlement check is a spot-check, not a general audit.
CITATION-NEEDED — tile-serving architecture's load limits. Appendix A row 13. §5's architecture has not been load-tested against the concurrent-request volumes production traffic could in principle generate; §10 states this as a falsification condition rather than an assumed non-issue.
CITATION-NEEDED — merged-dataset accuracy against an independent ground-truth census. Appendix A row 14. This paper and its companions establish completeness relative to single-source alternatives and, separately, height-measurement accuracy against two different ground truths; no source establishes footprint-level positional or existence accuracy against an independent building census for Nairobi specifically.
WP29 documents the height-estimation heuristic; WP32 reports the later satellite-measured result and its own validation.↩
Benjamin Herfort, Sven Lautenbach, João Porto de Albuquerque, Jennings Anderson and Alexander Zipf, "A spatio-temporal analysis investigating completeness and inequalities of global urban building data in OpenStreetMap," Nature Communications 14, article 3985 (2023), doi:10.1038/s41467-023-39698-6.↩
Heather R. Chamberlain, Edith Darin, Wole Ademola Adewole, Warren C. Jochem, Attila N. Lázár and Andrew J. Tatem, "Building footprint data for countries in Africa: to what extent are existing data products comparable?," Computers, Environment and Urban Systems 110, article 102104 (2024), doi:10.1016/j.compenvurbsys.2024.102104. Finds, across four multi-country African building-footprint products (Ecopia/Digitize Africa, Google v2, Microsoft, OpenStreetMap), that they "are not interchangeable," with clear count and area differences and considerable spatial heterogeneity in coverage and completeness. Abstract verified against Crossref and Semantic Scholar's DOI-indexed record.↩
Wojciech Sirko, Sergii Kashubin, Marvin Ritter, Abigail Annkah, Yasser Salah Eddine Bouchareb, Yann Dauphin, Daniel Keysers, Maxim Neumann, Moustapha Cissé and John Quinn, "Continental-Scale Building Detection from High Resolution Satellite Imagery," arXiv:2107.12283 (2021), doi:10.48550/arXiv.2107.12283. Reports the original Africa-only model and its 516-million-footprint result; an arXiv preprint with no subsequent peer-reviewed journal publication found.↩
Google Research, "Open Buildings V3 Polygons," Google Earth Engine dataset catalog (accessed 2026). States a current scope of approximately 1.8 billion building detections across Africa, Latin America, the Caribbean, South Asia and South-East Asia (58 million km²), from 50cm satellite imagery, CC-BY-4.0. Dataset documentation, not a peer-reviewed update to [^4].↩
Microsoft,
KenyaNigeriaBuildingFootprints(GitHub, Bing Maps, 2021). 50.5 million building footprints for Kenya and Nigeria combined, detected from Maxar imagery collected 2020–2021, licensed ODbL.↩Andy Coenen ("cannoneyed"), Isometric NYC (2026), a tile-by-tile isometric pixel-art map of New York City generated with Google's Nano Banana image model from satellite imagery and 3D geometry, by the creator's own published account requiring well over 200 hours of manual auditing and correction.↩
