From Thousands to Seamless: How Virtual Tilesets Tame Country-Scale 3D Buildings

A plain-English look at the architecture behind country-scale 3D building maps: why one giant tileset never finishes, how a global grid breaks the job into thousands of pieces, and how a single virtual tileset stitches them back into one seamless layer.

ELEMNT Engineering· ~15 min read

Picture the job. You have roughly 41 million building footprints for an entire country, and you want every one of them standing up in 3D, in a web browser, sitting on accurate terrain, smooth enough to fly around. The obvious way to build that, one giant 3D tileset generated in a single pass, does not just struggle. It never finishes.

The fix is not a bigger machine. It is a different shape: partition the country into thousands of small, independent pieces, then glue them back together with one lightweight file. Here is how that works, no prior 3D background required.

The job: a whole country, in 3D, in a browser

The dataset is national in scope: about 41 million building footprints, blended from open building datasets (Google Open Buildings, Microsoft Building Footprints) and authoritative national survey data. These are LOD1 buildings, which means each one is a 2D footprint extruded to its height, not a photogrammetry mesh or a point cloud. Extruded footprints are the most reliable way to render a whole country's worth of buildings: light, consistent, and easy to keep current.

The requirements were the hard part:

• Render the footprints as OGC 3D Tiles on a real Digital Elevation Model, so buildings sit on the ground instead of floating.
• Manage the data fully: create, edit, or delete the geometry or properties of any single building.
• Stay fast for both visualization and processing, even at national scale.

The trap: one monolithic tileset

The first instinct is "full generate": point a tiler at all 41 million features and build one tileset. It breaks in four ways at once.

• Scalability. Processing 41 million features in a single pass simply fails. The job is too big to hold.
• Performance. A single monolithic build is so slow it effectively never completes.
• Maintainability. To correct one building, you re-run the entire country. "Full generate" has no smaller unit than "everything."
• Cost. One enormous batch is prohibitively expensive in compute and memory.

The common thread is the unit of work. When the smallest thing you can build is "all the buildings in the country," that unit is too big to schedule, too slow to finish, too rigid to edit, and too costly to run. The fix is architectural, not a bigger box.

The math: partition before you process

Borrow a discrete global grid. This project used Google's S2, and two properties are why.

First, S2 is one consistent grid for the entire globe. Every cell has an ID, and that ID is a place, anywhere on Earth. Second, that grid lets you slice 41 million features into geographic chunks you can process independently.

The choice that makes it work is the grid level. This project used S2 level 9. At level 9, each cell covers a few hundred square kilometres (about 324 km² on average, per the published S2 cell statistics).¹ That granularity is the sweet spot: cells big enough to be worth processing as a batch, small enough to actually finish.

The numbers fall out cleanly:

• About 1,535 level-9 cells blanket the country.
• The densest metro cell holds roughly 950,000 features. Most cells hold far fewer.

Tag every footprint with the S2 cell it falls in, and "process the country" quietly becomes "process 1,535 small, independent jobs." That single change is what makes everything after it possible

Generate per cell

Now turn 2D footprints into 3D, one cell at a time. Mago3DTiler, an open-source Java OGC 3D Tiles generator from Gaia3D, handles the 2D-to-3D extrusion: feed it the GeoJSON footprints with a height attribute, hand it a GeoTIFF DEM, and it extrudes each footprint and clamps it to the ground so buildings rest on real terrain.² Run it once per S2 cell.

The output of each run is one tileset.json per cell, a self-contained OGC 3D Tiles set ready to render. Process the whole grid and you have roughly 1,535 tileset.json files.

Which raises the obvious question: how does a browser show 1,535 separate tilesets as one map?

The glue: the virtual tileset

This is the keystone of the whole design.

A virtual tileset is a single root tileset.json that holds no building geometry of its own. Instead it links to all the child tilesets, one per S2 cell, using a mechanism the OGC 3D Tiles standard already provides: the root-and-children hierarchy and external tilesets.³ The client loads one URL. The renderer walks the root, sees the children, and streams only the cells that are actually in view (visible-only rendering). To the user it is one seamless 3D layer. Underneath, it is still 1,535 independently managed units.

You do not hand-write that root. Cesium 3D Tiles Tools, an open-source command-line toolkit from CesiumGS, has a mergeJson command that builds a parent tileset.json referencing each child as an external tileset, by relative path, without copying any tile data.⁴ Point it at the per-cell tilesets and it emits the virtual root.

The payoff is localized updates. Edit one building and you regenerate only that one cell's 3D Tiles, then recompute the lightweight root. You never rebuild the country to change a single doorway. The property that made the monolith impossible, that everything is one indivisible block, is exactly what partition-and-virtualize dissolves.

The proof: the numbers

Here is the shape of it in practice, running on a shared Kubernetes cluster.

• Generating the 3D Tiles for the densest metro cell (~950K features) takes on the order of 15 minutes on a worker with 3 CPU cores and 20 GB RAM. Most cells are far smaller and finish far faster.
• Building the virtual root (validate, mergeJson, save) takes about 19 seconds on a service using 0.4 of a CPU core and 70 MB RAM. The glue is cheap because it moves references, not geometry.
• At render time the client never pays for the whole country. Visible-only rendering streams the handful of cells in the current view and ignores the rest.

(Figures above are an illustrative country-scale workload, not a customer-reported benchmark. [illustrative scenario, pre-GA model])

Strip away the internals and the contrast is simple:

Where ELEMNT fits

This is the cloud-native instinct applied to 3D.

The same idea is what makes ELEMNT fast and cheap in 2D. A PMTiles basemap is one indexed file served straight from object storage, and to update it you swap the file rather than rebuild a tile server's cache. The 3D version of that instinct is the one above: partition the world with a global grid, store each piece as open-format OGC 3D Tiles on object storage, and let a thin virtual root stitch them together at the edge. Either way the rule holds: never rebuild the world to change one thing, and never make the client pay for data it cannot see.

It is also the instinct behind the data versioning on ELEMNT's roadmap (Git-style branch, diff, and merge for spatial data, targeted for Q4 2026): change should be localized, attributable, and cheap. A partitioned 3D dataset is a natural fit, because the cell is already the unit of change.

And it stays open. S2 is a public grid. OGC 3D Tiles is an open standard. Mago3DTiler and Cesium 3D Tiles Tools are open-source. The output is portable files on storage you control, not rows locked inside one vendor's renderer. Bring your datastore, self-host the tiles, keep your exit.

The honest caveat

The pattern is not free magic, and it is worth being precise about its edges.

• The partition key has to match your data. Choose the S2 level for your density. Too coarse and a single cell is still a monster. Too fine and you drown in tiny tilesets and HTTP requests. Level 9 fit this dataset; yours may want a different level.
• Dense cells still cost real compute. That 15-minute metro cell is genuine work. Partitioning did not make it free, it made it schedulable instead of impossible.
• A virtual tileset is a serving and management pattern, not an editing database. It tells a renderer where the pieces are. The geometry, the heights, and the attributes live in your data store and your tiler, upstream of the glue.

The takeaway

"From thousands to seamless" is the whole story in four words. Thousands of independent tilesets, partitioned by a global grid so each one is small enough to build, update, and pay for on its own. One virtual root that links them into a single layer a browser can fly through. The trick was never a faster machine. It was refusing to treat a country as one indivisible block.

¹ S2 level-9 average cell area (324.29 km², range 195.59 to 408.12 km²) is from the published S2 Cell Statistics. The ~1,535-cell, ~41M-footprint, and ~950K-densest-cell figures describe an illustrative country-scale workload.

² Mago3DTiler (Gaia3D) is an open-source (MPL-2.0) Java OGC 3D Tiles generator with 2D-to-3D extrusion from GeoJSON, Shapefile, and GeoPackage, and DEM-based ground clamping.

³ The root-children hierarchy and external tilesets are part of the OGC 3D Tiles specification.

⁴ Cesium 3D Tiles Tools mergeJson creates a parent tileset that references inputs as external tilesets by relative path, without copying tile data.

Processing figures are an illustrative, pre-GA architecture model, not a customer benchmark. ELEMNT is pre-launch (GA July 15, 2026). Tooling facts are from the linked open-source projects and specifications.

What is ELEMNT?

ELEMNT is the cloud-native geospatial data platform — open formats (PMTiles, COG, Zarr, GeoParquet) served straight from object storage, OGC API-compliant, with transparent pay-per-use pricing and no vendor lock-in. From a single project to a billion tiles. Earth Traffic is one demo of what it can do.