Urban Design Visualisation — a Domain Workflow
Domain: urban design and landscape architecture. Case: the redesign of a town square — Hestetorvet and Algade, Roskilde. Stack: QGIS → Blender → Twinmotion → Affinity.
In most Domain Projects the Geospatial Workflow exists to answer a question: where are the party zones, which rooftops suit solar panels. Urban design is different. Here the Geospatial Workflow rarely produces the answer — the answer is the designer’s proposal for the square. What the workflow must produce is a faithful, legible spatial context in which that proposal can be drawn, rendered and judged.
This makes urban design visualisation a useful counterweight to the case studies elsewhere in the book, for two reasons. First, the weight of the workflow sits at Designing Spatial Results Communication (Vantage Point 4), not at the Analytical Schema. Second, it is an almost pure Prescriptive (Teleological) workflow (see 1.2 The workflow): the deliverable — an A0 poster — is fixed before any data is touched, and every earlier Vantage Point is reverse-engineered from it.
| Vantage Point | What it settles in this domain |
|---|---|
| 1. Scoping the Workflow | What the context is for: a stage for the proposal, not a portrait of the existing city |
| 2. Establishing the Data Framework | Which parts of the city are represented, at which Level of Detail, from which data |
| 3. Authoring the Analytical Schema | How heights, roofs, ground surfaces and shadows are derived from official data |
| 4. Designing Spatial Results Communication | How the reader’s attention is directed to the proposal — the centre of gravity of this workflow |
| 5. Executing the Analytical Schema | The Stack: QGIS, Blender + BlenderGIS, Twinmotion, Affinity, and the hand-over formats between them |
1. Scoping the Workflow
Spatial Intent. Present a proposal for the square in its urban context, so that a jury and the public judge the proposal — not the existing city around it.
The second half of that sentence is not decoration. It is the constraint that shapes every later Vantage Point, and it was learned the hard way (see Workflow Stewardship below).
Workflow type. Prescriptive. We run the preliminary pass in reverse:
- Communication — an A0 poster: site plan 1:500, concept diagrams, a line section, perspective renders.
- Analytical Schema — those drawings require building heights, roof forms, ground surfaces, terrain and shadows.
- Data Framework — those derivations require building footprints, two elevation models, edge lines for streets and pavements, and a site visit.
Universe of Discourse. The square and its edges; the buildings that frame it and the wider block structure; the terrain (the Roskilde square slopes); the ground surfaces — roads, cycle paths, pavements, plazas, planting; existing trees; sunlight and shadow; people and how they use the space; and the elements of the proposal itself — planting, water, paving, furniture, pavilions.
Operational context. Student groups over one semester; one site visit; free official data from Dataforsyningen; free or educational software; a large-format printer. A deliberately tight time budget: the context model should take one working session, not one week. Time spent modelling window frames on existing buildings is time not spent on the proposal.
A note on persuasion. A visualisation of a proposal is advocacy. It shows a future that does not exist, populated by people doing what the designer hopes they will do. That is legitimate — but it puts a Duty of Disclosure on the workflow: the reader should be able to tell what is recorded (the existing city), what is derived (heights, shadows), and what is proposed.
2. Establishing the Data Framework
Formalising the Domain of Discourse
| Cognised Existence | Spatial Character | Thematic specification | Resolution | Typing | Relationship constraints |
|---|---|---|---|---|---|
| Study area | discrete | The area within which the existing city is represented — 200–300 m around the square. Bigger is not better. | — | Polygon | Contains every other context Realisation |
| Context building | discrete | Inherited from GeoDanmark Bygning (see Buildings) — including its contested edges, which we accept rather than re-open | GeoDanmark’s MMU (25 m², 10 m² inside an area polygon); vertical: LOD1 or LOD2 (below) | Polygon footprint, extruded to a solid. height, eave, roof_rise: ratio. ground (DVR90 elevation): interval. roof_type: nominal. lod: ordinal | Footprints do not overlap; every building stands on the terrain |
| Terrain | continuous | Bare ground surface (see Elevation) | 0.4 m cell | Field | Buildings and surfaces sit on it |
| Ground surface | discrete | The paved and unpaved surfaces of the public realm: road, cycle path, footpath / pavement, plaza, parking, green, water, building, other | Precise in and around the square; rough elsewhere | Polygon; surface: nominal | Planar partition: no gaps, no overlaps, complete coverage of the study area |
| Existing tree | discrete | A tree standing in the study area today | Individual tree | Point | — |
| Proposal element | discrete | Planting, water, paving zone, furniture, new tree, pavilion — authored, not observed | Design-led | Polygon / Point | Lies within the study area; may replace ground surfaces |
Three of these commitments deserve comment.
Level of Detail is a resolution commitment. “Detail follows distance” sounds like a rendering tip, but it is a decision about resolution, and so it belongs here. Borrowing the CityGML convention, LOD1 is a flat-topped block extruded to the building’s height; LOD2 adds the roof form. We commit to LOD2 only for the four to eight buildings that frame the square and appear in the perspectives, and LOD1 for everything else. A Cognised Existence with deliberately uneven resolution must say so in its own data — hence the ordinal lod field. Without it, the finished poster silently implies a uniform accuracy the model does not have.
The ground surface is a partition. Its topological constraint — no gaps, no overlaps, full coverage — is what makes a site plan readable as a continuous ground. It is also exactly what the existing data does not offer (see the audit below).
Proposal elements are a different kind of thing. Every other Cognised Existence here is observed: it belongs to the World of Observation. The proposal belongs to the World of Proposition. It is formalised with the same five commitments, but it is never audited against existing data or confronted with the Sensoric Manifold, because there is nothing yet to confront. This is why it is recorded separately (below).
Auditing existing data
| Cognised Existence | Candidate data | Audit outcome |
|---|---|---|
| Context building (footprint) | GeoDanmark Bygning | Accept |
| Context building (height, eave) | Not in the footprint data | Transform from Danmarks Højdemodel: surface (DSM) minus terrain (DTM) |
| Context building (roof form) | Not in any register | Collect — orthophoto, oblique photos (skråfoto), site visit |
| Terrain | DHM Terræn (DTM), 0.4 m | Accept |
| Ground surface | GeoDanmark offers only road edges (Vejkant) and centre lines (Vejmidte) — lines, not areas | Transform (partition the edge lines into polygons) and Collect (draw the boundaries the data lacks: plaza edges, kerbs, planting beds) |
| Existing tree | GeoDanmark, where present | Accept, completed from orthophoto and site visit |
| Orthophoto | Dataforsyningen WMS/WMTS | Working reference only — used to check and digitise, never shown in the final deliverables |
| Photogrammetric city model | RealityScan meshes, Google Photorealistic 3D Tiles | Reject |
The rejection of photogrammetry is worth spelling out, because it is usually argued on aesthetic grounds alone. The aesthetic argument belongs at Vantage Point 4. There is also an ontological argument, and it belongs here: a photogrammetric mesh does not Realise Context building at all. It realises one undifferentiated visible surface, in which a facade, a parked car, a sign and a tree are the same continuous skin. It cannot be split into buildings, cannot carry a height or lod attribute, and cannot be edited when the proposal changes a building edge. It answers a different question — what does this place look like? — from the one the Domain of Discourse asks. See also Photogrammetry.
Confronting the Sensoric Manifold — the site visit
The site visit is not an excursion. It has both of this Activity’s functions:
- Validation — do the derived heights survive contact with the street? A very large
roof_riseusually means a lower wing or annex inside one footprint, which no elevation model will tell you. Does the square slope the way the terrain model says? - Collection — roof forms (gable, hipped, mansard, flat with parapet), and the boundaries the existing data lacks: where the plaza ends and the pavement begins, the kerb of a planting bed, the steps.
Recording the Domain of Discourse
- One master GeoPackage for the context (
context.gpkg), in ETRS89 / UTM 32N (EPSG:25832) with heights in DVR90. The CRS is fit for purpose: metric, and native to all Danish source data, so nothing is reprojected. - A separate GeoPackage for the proposal (
design.gpkg). Observed and proposed Cognised Existences have different epistemic status and are kept physically apart, so the proposal can change without touching the record of the existing city. - Shapefile, GeoTIFF and FBX are transport formats, not Recording. They carry data between programs at the Execution stage; the master data always stays in GeoPackage.
3. Authoring the Analytical Schema
The analytical core of this workflow is small. Most of its Operators derive representations rather than answer a question — which is typical of communication-led domains, and a reason not to skip this Vantage Point: the derivations still contain judgements.
flowchart LR SA[Study area] --> CL{{Clip}} FP[Building footprints] --> CL DSM[DSM] --> CL DTM[DTM] --> CL EL[Edge lines] --> CL CL --> ND{{"DSM − DTM<br/>(local)"}} ND --> NDSM[nDSM] CL --> IB{{"Inward buffer −0.5 m"}} IB --> ZS{{"Zonal statistics<br/>outlier filter, p95 / p10"}} NDSM --> ZS ZS --> H[height, eave] H --> RR{{"roof_rise = height − eave<br/>reclassify at 1.0 m"}} RR --> RT[roof_type] CL --> ZG{{"Zonal statistics on DTM"}} ZG --> G[ground] CL --> PL{{"Node + snap<br/>polygonize"}} PL --> SF[Ground surface polygons] H --> EX{{"Extrude:<br/>LOD1 to height,<br/>LOD2 to eave + roof"}} RT --> EX G --> EX EX --> M3[3D context model] M3 --> SH{{"Shadow casting<br/>sun position: place, date, time"}} SH --> SR[Shadow raster] CL --> CT{{"Contour, hillshade"}} CT --> TR[Terrain graphics]
The parameter choices are Epistemic Choices and belong in the Design Rationale:
- 95th percentile, not maximum, for building height — chimneys, antennas and overhanging trees would otherwise set the height of whole buildings. The 10th percentile of the same pixels estimates the eave.
- Inward buffer of 0.5 m — keeps street and wall-edge pixels out of the zonal statistic.
- Flat-roof threshold of 1.0 m — a building whose
roof_riseis below this is typedflat. - Centre lines are not partition boundaries. Vejmidte is used only as a classification hint; if it enters the partition, every road is cut lengthwise in two.
Two Intermediate Realisations matter in practice: the nDSM (height above ground), which is the quickest visual check on the heights, and the dangles (loose line ends) of the partition, which show exactly where the planar-partition constraint is still violated.
Tasks used at this Vantage Point:
4. Designing Spatial Results Communication
What kind of deliverable. On MacEachren’s cartography cube the poster sits firmly in one corner: a public audience, presenting knowns (the proposal is a set of claims, not an exploration), and no interaction. That justifies a static, printed artefact, read from one to two metres away.
| Deliverable | What it must show | Made with |
|---|---|---|
| Site plan 1:500 | The proposal in plan, on a quiet ground | QGIS, finished in Affinity |
| Concept diagrams (3–4) | One idea each: zones, flows, connections | QGIS, finished in Affinity |
| Line drawing or section perspective | Existing vs. proposed, from the same camera | Blender |
| Perspective renders (2–3) + one season variant | The proposal as experienced at eye height | Twinmotion |
| A0 poster | All of the above, in one hierarchy | Affinity |
How the deliverable represents the data. The governing principle here is not specific to urban design. Every map must decide where the reader looks first; the general rule is set out in Visual hierarchy and figure-ground. In this domain the figure is the proposal and the ground is the existing city, and the principle translates into three representational rules:
- The context is one neutral material. Matte white in renders; white with a thin black outline in plans. No facade textures, no photo meshes.
- Colour belongs to the proposal. Planting, water, paving, furniture and people carry the colour. Nothing in the context competes with them.
- Atmosphere over accuracy. Haze, soft shadows and light do more for the context than modelled detail — haze literally pushes the white city back and brings the proposal forward.
Professional competition material uses the same grammar. MASU Planning’s proposal for Hestetorvet and Algade shows white or grey context, with realistic trees, people and paving only where the design happens.
Test: if someone looks at the render and talks about the existing buildings first, the context is too loud.
Backward Glances. Several representational choices must be checked against what was actually recorded and computed:
- Camera placement depends on the
lodfield. A perspective that puts an LOD1 block in the foreground exposes a resolution the Data Framework never committed to. Either move the camera or go back and raise that building to LOD2. - Shadows are either a convention or a claim. A drop shadow on a site plan is a graphic convention that implies nothing about the sun. A shadow render cast from the 3D model at a stated place, date and time is a claim about the proposal’s microclimate — so it should be labelled with that date and time.
- Existing vs. proposed must share a camera. Otherwise the comparison measures the change of viewpoint, not the change of design.
- The orthophoto is turned off in every final drawing. It was a working reference (Data Framework), not a Realisation of anything in the Domain of Discourse.
- People in the renders are a claim about use. Place them doing what the design invites — sitting, playing, crossing, meeting — in small groups, and be ready to defend each one.
5. Executing the Analytical Schema
The Analytical Schema is translated into a chain of Recipes across four programs. Data flows one way. Each program is used for what it does best, and the hand-over format between them is fixed in advance.
| Stack | Role in this workflow |
|---|---|
| QGIS | Instrument of record (the master GeoPackage) and of analysis (heights, partition, contours); 2D plans and diagrams |
| Blender + BlenderGIS | Extrusion to LOD1/LOD2; line drawings; sun-correct shadow render |
| Twinmotion | Perspective renders, seasons, atmosphere |
| Affinity | Finishing plans and diagrams; A0 poster layout and print PDF |
| Step | Task | Recipe | Input | Output | Hand-over format |
|---|---|---|---|---|---|
| 1 | Building heights | Building heights from DHM (Recipe - QGIS) | GeoDanmark, DHM | Clipped data; buildings with height, eave, roof_type, ground | Shapefile + GeoTIFF |
| 2 | Surface partitioning | Surface partitioning (Recipe - QGIS) | Vejkant, buildings | Classified ground surfaces | (stays in GeoPackage) |
| 3 | — | Site plan and concept diagrams (Recipe - QGIS) | Surfaces, buildings, design layers | Site plan 1:500, concept diagrams | PDF / SVG |
| 4 | Context massing | Context massing (Recipe - Blender) | Shapefile with heights, terrain GeoTIFF | White LOD1 context, LOD2 roofs | FBX |
| 5 | — | Line drawings and shadow plans (Recipe - Blender) | Context + design model | Line perspective/section; top-down shadow render | PNG / SVG / world file |
| 6 | — | White-context rendering (Recipe - Twinmotion) | context.fbx, design.fbx | Perspective renders, season variants | JPG / PNG / video |
| 7 | — | A0 poster layout (Recipe - Affinity) | Everything above | A0 poster | Print PDF (PDF/X-4) |
Recipes differ in how reproducible they are. Steps 1 and 2 are scripted QGIS Processing tools: given the same inputs and parameters, they give the same result, and can be handed to another practitioner or an agent. LOD2 roof modelling in step 4 is not — every roof is a human decision point checked against photographs. That asymmetry is fine, but it must be recorded: the lod field says which buildings were hand-modelled, and the Design Rationale says from which sources.
Project folder. Every group uses the same structure, and no file is renamed once another program links to it:
plaza_project/
01_data/ downloaded raw data (never edit)
02_qgis/ QGIS project + GeoPackages (master data)
03_exchange/ shp, tif, fbx, obj between programs
04_blender/ .blend files
05_twinmotion/ .tm files
06_output/ renders, plans, diagrams, poster
Workflow Stewardship
A Backward Glance across iterations. The previous run of this workshop built its context from RealityScan meshes of oblique aerial photos and Google Photorealistic 3D Tiles. The renders were impressive and the juries talked about the existing buildings. That observation, made at Vantage Point 4, cascaded back to Scoping — the Spatial Intent was rewritten to say whose judgement the context must serve — and from there to the Data Framework, where photogrammetry was rejected and LOD1/LOD2 massing adopted. This is the Backward Glance working as intended: the fix was not a better render setting, but a re-stated intent.
Design Rationale entries owed by every group:
- Study area extent, and why
- Which buildings are LOD2, and the sources used for each roof
- Height-derivation parameters, if changed from the defaults — and any heights corrected by hand
- Ground surfaces classified by judgement rather than by hint
- Sun position (date, time) of every shadow render
- What in each render is proposed rather than recorded
Before hand-in:
- Context is one neutral material in every render and plan
- LOD2 roofs only on the buildings that frame the square; no LOD1 block in a foreground
- All colour and detail is in the proposal
- Site plan at 1:500 with north arrow and scale bar; orthophoto turned off
- Ground surfaces classified in and around the square (no red outlines left)
- Building heights checked (
h_check) - 3–4 concept diagrams, one point each
- At least one line drawing, existing vs. proposed from the same camera
- 2–3 perspective renders + one season variant
- A0 poster from the course template, images at 150 ppi, PDF/X-4 checked and test-printed at A3
- Someone outside the group looks at a render and talks about the design first
Related
- 1.2 The workflow — the five Vantage Points and Workflow Stewardship
- Visual hierarchy and figure-ground — the general map design principle behind the context rules
- The use of 3D geospatial data in urban planning, Urban design
- 2.5D geometries, 3D geometries, Digital Twin
- Data: Buildings, Elevation, Orthoimagery, Transport networks