These six are rule-based procedural approaches — the same family as
our own pipeline — spanning street-network generation, block
subdivision, and real-world planning-tool validation of subdivision
rules.
The foundational paper in this space. Generates a street
network from an extended L-system driven by input image maps
(population density, land/water boundaries, terrain), then
subdivides the resulting blocks into building lots and extrudes
simple building geometry. First to establish that the street
network — not the buildings — is the key structural driver of a
believable city layout; nearly every later paper on this list
either extends or reacts to this pipeline.
Replaces Parish & Müller's L-system with a
tensor-field-guided street graph the designer can edit
interactively, either by reshaping the underlying field or
editing the graph directly, mixing hand-authored and procedural
control at whatever granularity the designer wants. Closest
prior art to our own Roads
doc's "sketch a rough polyline, the editor fits a
curvature-bounded spline live" approach — the live-editing feel
is the same goal, tensor fields vs. our arc-spline fit is the
differing mechanism.
A GIS-oriented (not graphics-oriented) automated subdivision
tool aimed at real planners evaluating zoning-regulation impact
before adoption, not at rendering. Takes arbitrary
parcel-shaped vector input and produces lot + street layouts
respecting real subdivision ordinances (frontage, setback,
minimum lot area). Useful as a cross-check for our
road-facing frontage split
against what real-world planning software actually validates
against.
Applied to a real Turkish zoning case (Konya), this paper
compares three binary-search subdivision strategies — split by
edge length, by parcel area, or both together — against a
target lot-size distribution mandated by zoning code. Directly
relevant to how
Planning
picks frontage width and folds remainders; their edge-vs-area
comparison is a concrete alternative to the remainder-folding
heuristic we're using.
Argues that generating streets and parcels as two separate
passes (street network first, then subdivide the resulting
blocks) produces worse results than co-generating them: it
recursively splits parcels and grows the connecting street
graph together at each hierarchy level, using graph search to
guarantee every parcel gets street access, then optimizes the
combined geometry.
Planning
adopts that close-by-construction stance for open-network
junctions (wedge parcels + frontage trims) rather than emitting
overlapping road-facing fans and patching the gap afterward.
A three-stage CGA-rule (CityEngine-style) pipeline — parcel
subdivision/clustering, building extrusion, then texture
mapping — applied to two real Guangzhou redevelopment projects,
generating multiple design proposals per site for planners to
compare. The parcel-clustering step (grouping adjacent parcels
before subdividing, rather than subdividing block-by-block) is a
technique our block-based subdivision path doesn't currently
do; worth revisiting if isolated small-block artifacts show up
in testing.
Real-world minimum lot dimensions and area requirements from San Francisco's planning code, providing concrete constraints for parcel subdivision validation and cross-reference against our own frontage/area split heuristics.
Municipal subdivision standards covering lot divisions, frontage requirements, and street connectivity, grounding our procedural rules against real-world planning compliance criteria.