How to create a 3D city model: a practical workflow for planning projects

Creating a 3D city model is not mainly a modelling exercise. It is a process of turning a planning question, several data sources and a chosen level of detail into a model that people can actually use. A model can be geometrically impressive and still fail if it is too heavy, poorly documented or disconnected from the decisions the project team needs to make.

The most effective workflow begins with purpose. A city model for a skyline study has different requirements from a model used for property analysis, public participation, solar assessment or construction phasing. The geometry, attributes, update cycle and publishing method should all follow that purpose.

This guide explains how to create a 3D city model in ten practical steps, with attention to source data, coordinate systems, semantic information, performance, quality control and long-term maintenance.

1. Define the planning question

Start by writing down the decision that the model must support. Avoid broad goals such as “we need a digital twin” or “we want the city in 3D”. These statements do not define what the model must contain.

Better questions include:

• How will three development scenarios affect building height and public space?
• Which existing buildings fall within a proposed project boundary?
• Where could new housing be added without exceeding a height envelope?
• How does a new building affect shadow at selected dates and times?
• Which assets must remain operational during redevelopment?
• How can residents explore a proposal from street level?

For each question, identify the users, the required accuracy, the update frequency and the form of output. This prevents a city-wide data collection exercise when the project only needs a reliable district model.

2. Choose the geographic extent

The model boundary should be larger than the intervention area when surrounding context affects the decision. A tower study may require a wide skyline zone. A pedestrian design workshop may only need a few streets, but at a higher level of detail.

Use three nested extents when useful:

• project area: where design changes are made;
• impact area: where effects such as shadow, traffic or views are assessed;
• context area: a lighter model that helps users understand location and orientation.

This structure allows detailed data to be concentrated where it matters and reduces file size elsewhere.

3. Specify the required model content

A 3D city model can include more than buildings. Depending on the project, it may contain:

• terrain and elevation;
• existing and proposed buildings;
• roads, pavements and cycle routes;
• trees and vegetation;
• water and flood surfaces;
• parcels and project boundaries;
• underground infrastructure;
• policy, environmental and ownership layers;
• time or project-phase attributes.

Make a distinction between objects that must be selectable and objects that only provide visual context. A photorealistic mesh may be excellent background context, while semantic building objects are needed for queries and calculations.

4. Select authoritative and project-specific sources

List each data source before modelling begins. Record the organisation, date, coordinate system, spatial resolution, licence and expected update cycle.

Common inputs include:

• building footprints and height attributes;
• digital terrain and surface models;
• aerial imagery and orthophotos;
• point clouds or photogrammetric meshes;
• GIS layers from web services;
• CAD, SketchUp, glTF or BIM models;
• survey data and project drawings;
• manually created scenario objects.

Do not assume that the visually most detailed source is the most accurate. An image-based mesh may look realistic but have distorted edges. A simple building dataset may have cleaner footprints and attributes but less façade detail. The appropriate source depends on the task.

5. Align coordinate systems and vertical references

Coordinate problems are among the most common causes of failed model integration. Horizontal coordinates may use a national projected system, geographic longitude and latitude or a local engineering grid. Heights may refer to sea level, a national datum, terrain-relative height or an arbitrary project origin.

Before converting data:

• confirm the coordinate reference system of every source;
• check whether height values are absolute or relative;
• verify units, especially metres versus millimetres;
• test at several known control points;
• document every transformation.

A small horizontal offset can be obvious. A vertical mismatch may remain hidden until buildings float above the terrain or underground infrastructure appears at street level.

6. Choose a fit-for-purpose level of detail

Level of detail is not only about geometry. It also concerns the precision of attributes and the visual representation required by users.

A practical hierarchy is:

• simple massing: footprint and height for early scenarios;
• roof-form model: recognisable building shape for city-scale context;
• façade model: windows and architectural detail for visual assessment;
• BIM-derived model: selected building components and properties;
• photorealistic mesh: captured surface appearance of the existing city.

Use the lowest level that supports the decision. Excessive detail increases conversion time, storage and rendering load. It can also distract from the planning question.

7. Generate and enrich the geometry

There are several production methods:

Extrusion from footprints

Building footprints can be extruded using height or floor attributes. This is efficient for a large area and supports queries, but roofs and façades remain simplified.

Procedural generation

Rules can create roads, lots, building volumes and typologies from parameters. This is suitable for comparing scenarios, but generated output must still be reviewed by designers.

Photogrammetry and laser scanning

Images or point clouds can produce detailed meshes of the existing environment. These models provide recognition but may need optimisation and do not automatically contain semantic object information.

Manual or BIM-based modelling

Important buildings can be created in architectural software and simplified for the city model. Remove internal objects and detail that does not contribute to the urban-scale use case.

Once geometry exists, add only the attributes needed for the workflow, such as function, height, floor area, phase, status or scenario name.

8. Validate the model

Validation should cover geometry, attributes and usability.

Geometric checks

• Are buildings on the correct parcels and terrain?
• Are there duplicates, gaps or extreme heights?
• Do proposed objects align with roads and project boundaries?
• Are coordinate transformations consistent?

Attribute checks

• Are required fields populated?
• Are units and categories consistent?
• Can the source and update date be traced?
• Are scenario objects clearly distinguished from existing objects?

User checks

• Can the intended audience open and navigate the model?
• Do layers and legends make sense?
• Does performance remain acceptable on ordinary project hardware?
• Can a user tell which information is measured, calculated or illustrative?

9. Publish the model for its actual users

A desktop model used by one specialist is different from a browser-based planning environment used by a project team. Decide how users will access the model and what they may change.

Possible outputs include:

• GIS or city-model files for specialists;
• 3D tiles or web-streamed layers;
• static images and animations;
• interactive project links;
• embedded viewers;
• workshop or presentation versions;
• exports to CAD, BIM or visualisation software.

For browser delivery, optimisation is essential. Use tiled streaming, simplified geometry, appropriate textures and selective loading. Separate editable project objects from large background datasets.

10. Plan maintenance and governance

A city model becomes unreliable when users cannot tell whether it is current. Assign ownership for:

• source updates;
• quality checks;
• scenario naming and archiving;
• user permissions;
• privacy and sensitive layers;
• retention of project versions;
• technical hosting and backups.

Not every layer needs real-time updates. Define a realistic cycle. Base buildings may be refreshed periodically, while an active design scenario may change daily during a workshop.

A practical architecture for urban-planning projects

A robust model often combines several systems rather than forcing everything into one file:

1. GIS and source databases manage authoritative spatial information.
2. 3D tiles or meshes provide scalable visual context.
3. CAD or BIM tools create detailed project objects.
4. A 3D planning environment combines the context, scenarios and indicators.
5. Specialist analysis tools calculate traffic, water, noise, energy or climate effects.
6. Results return to the shared environment for comparison and communication.

3D Cityplanner is designed for the fourth role: bringing data, area design, scenarios and analysis results together at urban scale. It does not replace specialist GIS or BIM production software.

For examples of different model types, read 3D city model examples in Europe and 3D architecture model examples for urban design.

Common mistakes

Starting with software instead of the use case

A tool cannot determine the required accuracy, attributes or update process. Define these first.

Keeping all source detail

Internal BIM objects, high-resolution textures and dense meshes can make a city model unusable. Simplification is part of model design, not a loss of professionalism.

Mixing existing and proposed objects

Use clear categories, colours or scenario attributes. Users should never mistake an early proposal for an existing building.

Ignoring provenance

Record source, date and processing steps. A model without provenance is difficult to defend or update.

Publishing without testing ordinary devices

A model that only works on the modeller’s workstation is not a collaborative planning tool.

Conclusion

To create a useful 3D city model, begin with the planning decision and build only the geometry, attributes and services required to support it. Combine authoritative source data with project-specific models, validate coordinates and semantics, optimise for the intended delivery method and assign responsibility for maintenance.

The result does not need to be the most detailed model available. It needs to be understandable, traceable, performant and connected to the workflow of the people who will use it.

Frequently asked questions

Which data is essential for a 3D city model?

At minimum, most projects need terrain, existing buildings, project boundaries and a reliable coordinate system. Additional data depends on the planning question.

Can a 3D city model be created automatically?

Large parts can be generated from footprints, heights, point clouds or imagery. Automatic output still requires validation, classification and purposeful simplification.

Should BIM models be imported directly?

Usually they should be simplified first. Keep the external geometry and selected properties needed at urban scale, rather than every internal component.

What is the best level of detail?

The lowest level that reliably supports the decision. Early scenarios often need simple massing, while a visual-impact study may require more detailed form and context.

How often should the model be updated?

That depends on the layer. Define a documented cycle for each source and make the date visible to users.