Field noteOct 28, 20265 min read1 source

Load full Manhattan building footprints from compressed data | mrdoob/slop-newyork@062c4a9

In one minute

Slop New York has added a compressed building-geodata asset and code that uses surveyed building polygons when constructing its Manhattan scene. For teams building AI-assisted or procedural spatial applications, the change is a useful implementation signal: real-world geometry can constrain generated content without replacing the procedural system that fills the rest of a scene.

What changed: Slop New York now switches from procedural infill to surveyed Manhattan data, including full building footprints, the NYC tree inventory and real MTA subway entrances.

What happened

A commit to mrdoob's Slop New York repository, 062c4a998ad279a8d5c3e528b32571eef83677e2, adds a compressed binary asset named js/building-geodata.bin.gz. GitHub identifies the binary as 430 KB. The page also shows a new preload entry in index.html: the browser is instructed to fetch that asset with as="fetch" and crossorigin, alongside existing module preloads for the application's JavaScript files. That makes the geometry asset an explicit part of the page's loading plan rather than something discovered only after another script begins work.

The commit changes js/building-geodata.js, a module whose generated diff is not rendered in the supplied source, and updates js/buildings.js. The visible application code constructs a surveyedBuildings collection from REAL_BUILDINGS. Each retained item carries its building polygons and bounds, with a small expansion around its bounding rectangle. The code excludes surveyed buildings that contain locations reserved for authored landmark models, and it also excludes geometry overlapping landmark colliders. The revised comment says the authored landmark models remain while the survey supplies surrounding buildings. This is therefore not a wholesale substitution of every existing scene element with survey data.

The update does not simply place every surveyed object and abandon the older city-building routine. It introduces reserveCells, a map that indexes surveyed building reserves into grid cells sized 128 by 128. For a city block, reservesForBlock looks up candidate reserves through the grid, tests rectangle overlap, removes duplicates, sorts the resulting indexes, and returns the matching reserves. The map avoids testing every surveyed reserve against every block. The stated reason for retaining the resulting order is to keep the remaining procedural lots deterministic.

Those reserves are then combined with landmark reserves before procedural lots are produced for each block. The visible loop continues to skip blocks marked as parks or medians and continues to use different minimum lot values depending on block framing. What changes is the set of spaces unavailable to that procedural placement routine: surveyed geometry marks locations the infill must leave alone. The commit also replaces a direct per-block filter over all surveyed reserves with the grid-backed lookup. The source shows no new public API, price, account tier, hosted service, or access change. It is a repository-level implementation update. The public source is the commit page.

What the archive adds

This is a new fact on a known story. The earlier Field Note, mrdoob releases Slop New York, an open-source procedural Manhattan simulation built with Three.js WebGPU, described the project as a procedural browser simulation using OpenStreetMap and NYC Open Data. The new commit gives a more specific implementation direction: compressed surveyed building geometry is now used to reserve and populate parts of the procedural city.

Trend signal

No listed New Runtime pattern directly fits this repository-level rendering technique. It is adjacent to a broader design question about where generated systems should yield to structured external data, but the supplied material does not establish an agent, model, protocol, or operational change covered by the current pattern set.

Why it matters

Procedural environments tend to face an uncomfortable choice between a small, coherent synthetic world and a faithful but heavy data replica. This commit illustrates a third approach. A compact geometry asset supplies constraints in locations where building placement matters, while the procedural pipeline remains responsible for what is not explicitly represented.

That separation is useful beyond city visualization. Teams making simulations, maps, training environments, or AI-generated interactive scenes can preserve repeatability while incrementally increasing fidelity. Instead of asking a generator to infer every important boundary, they can encode selected boundaries as data and leave lower-priority areas to procedural rules. The result can be easier to update than a fully authored world and more geographically disciplined than unconstrained generation.

The code also exposes the practical work behind the approach: authored exceptions, collision checks, spatial indexing, deterministic ordering, and asset preloading. These are implementation decisions that determine whether a hybrid scene remains stable as its data grows. Data-driven realism is not a one-line model capability; it is a set of explicit boundaries between source data, rendering assets, and generation rules. The 128-by-128 index is particularly telling: once data becomes a constraint on generation, retrieval of relevant constraints becomes part of the runtime design.

Limits and uncertainty

The supplied commit shows the addition of the compressed asset and the visible integration logic, but it does not document the provenance, coverage, licensing, coordinate system, or accuracy of REAL_BUILDINGS. The generated changes in building-geodata.js are not rendered in the provided view, so their exact decoding path and schema cannot be independently described here.

The source also does not establish how many buildings the asset contains, what share of the scene uses its polygons, or whether building heights come from the same dataset. It does not provide a benchmark, frame-rate effect, memory cost, startup-time measurement, or visual comparison with the prior implementation. The preload signals an intent to fetch the asset early, but it does not prove a user-perceived loading improvement. Finally, the visible code demonstrates a reserve-and-infill strategy, not a general-purpose recipe for other mapping stacks or engines. It shows a code change, not measured user-facing results.

Skill to build now

Take one procedural scene and define a small “surveyed reserve” interface for it this week: polygons or bounds, a spatial index, an overlap test, and deterministic subtraction from generated placement areas. Start with a compressed asset and one high-value region rather than replacing the full generator. Then add a repeatable test that verifies generated objects never overlap a reserved polygon. This turns external geometry into an enforceable constraint instead of a visual reference that can drift from generation behavior.

Reader takeaway

Slop New York is becoming a hybrid scene rather than a purely procedural one. The key engineering move is not importing all city data; it is using compact surveyed geometry to carve out precise, repeatable exceptions in a still-procedural world. That is a reusable architecture for spatial software where realism and controlled generation must coexist.

Evidence / sources

  1. 1github.com/mrdoob/slop-newyork/commit/062c4a998ad279a8d5c3e528b32571eef83677e2
All Field Notes

Next reads

Read next

Open the graph
  1. 01archiveField NotesOpen the latest editorial analysis.
  2. 02source ledgerSource LedgerInspect the public source evidence graph.
Who read this page?Machine requests, hidden until opened

Loading the privacy-safe route aggregate...

Open the JSON contract