Terrain planning produces more artifacts than almost any other civil discipline: surfaces, grading sheets, drainage reports, erosion control logs, earthwork balances, as-builts. Each artifact is usually authored separately, and each separation is a chance for two documents to disagree. GenAnywhere removes the disagreement by modeling the terrain as a small typed entity graph and rendering every artifact from that graph. This post walks the model: the root entities, the invariants that keep it honest, and the renderers that turn it into sheets, reports, and public narrative without anyone retyping an elevation.
The Five Root Entities
GenAnywhere's terrain domain has exactly five root entity types. A Surface is an elevation field: existing ground, proposed ground, or any intermediate design stage, each with its datum, contour interval, and version. A GradingZone is a bounded region of a Surface with a purpose: pad, cut slope, fill slope, bench, terrace, or undisturbed reserve. A DrainagePath is a directed route water follows across or through Surfaces: swale, ditch, cell chain, pipe run, or overland flow line. A ControlPractice is a physical erosion or sediment feature attached to a GradingZone or DrainagePath: silt fence, wattle, mat, basin, weir, outlet. An EarthworkLot is a accounted quantity of moved ground, linking a source GradingZone to a destination GradingZone or an offsite destination. Everything else in a terrain package is an attribute of these five or an event attached to them.
Why DrainagePath Must Be Directed and First-Class
It is tempting to store drainage as attributes of structures, and it fails for the same reason it fails in power systems: water has direction and continuity. A retention cell with no declared inflow path cannot explain its sediment; an outlet with no declared receiving path cannot explain its erosion. By making DrainagePath a directed root entity that must terminate at a declared outfall, GenAnywhere can traverse from any raindrop inlet to the receiving water and emit the whole journey as one narrative or one longitudinal profile. The traversal is also what makes public explanation possible, because "water from your side of the ridge reaches the creek through the three ponds and the stone weir" is a sentence, while a structure schedule is not.
Invariants That Keep the Ground Honest
The model enforces a short list of write-time invariants, each one earned from a real failure. Every GradingZone must reference exactly one Surface version and one purpose. Every proposed Surface must declare its existing-ground parent so the cut-fill difference is always computable. Every DrainagePath must terminate at a declared outfall and pass through at least one ControlPractice when it leaves a disturbed GradingZone. Every EarthworkLot must balance a source and a destination, with offsite destinations carrying permit references. Every ControlPractice carries an inspection cadence, and an inspection event cannot be filed against a practice that is not currently installed. These rules sound bureaucratic until you inherit a dataset where a sediment basin cleanout was logged against a removed silt fence; after that they read like load-bearing walls.
Renderers: One Graph, Many Audiences
No reader ever sees the graph directly; renderers mediate. The sheet renderer emits grading and drainage sheets with spot elevations, contour labels, and details. The report renderer emits the drainage study and the erosion control plan in regulator order. The public renderer emits plain-language narrative that pulls only what a neighbor can observe: where water enters, where it pauses, where it leaves, and what holds the soil meanwhile. The operations renderer emits the inspection chronology and the mass balance ledger. Because all four read the same entities, a revised weir crest propagates to sheets, report, narrative, and ledger in one pass, and the classic failure mode of the website contradicting the permit file becomes structurally impossible.
Imagery as Typed Scene Content
Visuals are typed content in this architecture, not decoration. Each asset carries a scene type from a controlled vocabulary: grading site aerial, contour agriculture, mine bench, reclamation slope, stormwater cell chain, marsh terrace, seasonal dormant site. Renderers request scene types, and the asset pipeline resolves them against validated files, checking aspect ratio, resolution, size, and GenAnywhere's two absolute prohibitions for published imagery: no embedded text and no people. A scene that fails validation never enters the graph, which is why a fifty-site portfolio publishes visually coherent terrain stories without a human choosing filenames.
Versioning Ground Across a Project's Life
Terrain outlives its design software. Surfaces are therefore versioned as a timeline: rough grade, interim stabilization, final grade, as-built, and any post-construction regrade. GradingZones migrate between versions while retaining their history, so a fill slope can be asked what it was at every stage and which inspections it passed. ControlPractices install and retire on their own timelines, and EarthworkLots accumulate into a balance that can be queried at any date. The payoff is quiet but total: when the model is small, typed, and invariant-guarded, the life of a shaped hillside becomes queryable instead of merely remembered, and the next engineer inherits a ground truth rather than a filing cabinet.
Top comments (0)