What Is a 3D City Model? Data Structures, Workflows, and Practical Limits

I think of a 3D city model as an intermediate data product between a map and a design model. It is spatial, layered, and inspectable. It can represent terrain, buildings, roads, water, vegetation, parcels, and infrastructure at a level of detail that matches a specific question.
That last part matters. “3D” describes the geometry, not the quality of the data. A model can look detailed while using old imagery, estimated heights, or simplified ground surfaces. When I evaluate one, I ask where the data came from, how it is organized, and what decisions it is allowed to support.
The core data model
At minimum, I expect four components: geometry, location, attributes, and source metadata. Geometry tells me the shape and position of an object. Location places it in a coordinate system. Attributes can describe a building height, road class, land use, or surface type. Metadata records the source date, resolution, processing method, and confidence.
There is a fifth component I find useful: version history. Urban data changes constantly. A road opens, a building is demolished, and a parcel boundary is redrawn. If I cannot tell which version produced a view, I cannot explain why two analyses disagree. Even a simple timestamp and source list make the model easier to maintain.
Without the last two components, the scene is mostly a visual reference. That can still be valuable, but it should not be confused with a coordinated engineering model.
A practical model is usually layered. I might keep terrain, buildings, movement, water, vegetation, utilities, and proposed options separate. This makes it easier to toggle a layer, compare versions, or identify which source created a misleading result.

A repeatable map-to-model workflow
I use a five-step loop.

1. Define the decision I write the question in one sentence, such as: “Can this parcel connect to the transit stop without crossing the service route?” The question determines the model boundary and the minimum useful layers.
2. Build the context I collect terrain, building massing, roads, paths, water, and other constraints. For a quick first pass, I can draw a boundary on a map in Shapezo and let its AI generate a starting model for the selected area. This is useful as a spatial scaffold while options are still changing.
3. Inspect consistent views I save plan, street-level, and oblique views. I use the same camera positions for each option, because a favorable angle can make a weak option look better than it is.
4. Validate assumptions I compare visible geometry with current aerial imagery, survey information, planning data, and discipline sources when available. I flag estimated heights, missing utilities, uncertain boundaries, and terrain that is too smooth for the question.
5. Record the result I save the input list, source dates, boundary, camera positions, and open questions. The record does not need to be elaborate. It needs to let another person understand how the scene was made and why a conclusion was reached. For a development team, this record also makes handoffs calmer. The person preparing a feasibility study may not be the person checking access or drainage later. A clear layer list and confidence note reduce the amount of reverse engineering required before the next task can begin. I would rather spend a few minutes documenting the inputs than spend a meeting guessing which surface or imagery someone used.

Where AI-generated geometry fits
Shapezo changes the order of the first step. Instead of building every object manually before seeing the context, I select a geographic area and receive a generated model to inspect. That makes early exploration faster, but it does not remove validation. The output can suggest relationships and reveal questions; it should not be treated as measured survey data, code compliance, or construction intent.
The practical boundary
A 3D city model is best at contextual analysis, option framing, and communication across disciplines. It becomes risky when someone quietly upgrades it into a precise claim. I keep the boundary explicit: use the model to understand the place, then use verified data and discipline tools when the decision becomes consequential.