LOD in Urban Digital Twin: When the level of detail becomes a Data Architecture decision
In Part 2, we agreed on a fundamental principle of Urban Digital Twin: data is only truly valuable when its semantic structure reaches a validated & consistent level to enter the production pipeline. In reality, a CityGML dataset might look ‘correctly formatted’ on the surface, but a wrong namespace, broken topology, CRS errors, or lack of semantic consistency can cause the entire downstream chain—from ETL, indexing/streaming to simulation—to collapse at the very starting point. Therefore, ‘syntactically correct’ has never been enough; it’s crucial for data to be ‘semantically correct’ and, even more importantly, ‘operationally correct’.
However, as soon as the inspection and validation step is considered complete, a big question almost immediately arises, naturally opening up Part 3: “How detailed does an urban model really need to be?” This is precisely when the concept of LOD (Level of Detail) becomes central to the entire Urban Digital Twin architecture.
In many discussions about 3D models, LOD is often simplistically understood as the ‘aesthetic level’ of the model. However, at the urban scale, the story has never been just about visualization. As the system expands from a few objects to millions of buildings, road segments, utility networks, and environmental layers, each decision to increase LOD is no longer a graphical decision but a data architecture decision. An overly simple city model may lack semantic density to support simulation or urban analysis. But conversely, a hyper-detailed model can easily become a burden, causing storage overhead to increase sharply, geometry complexity to exceed processing thresholds, query efficiency to decline, streaming to be heavy, and the update lifecycle to become expensive.
Therefore, mature Urban Digital Twin systems usually don’t ask ‘how to make the most detailed model’, but instead, ‘Which LOD is sufficient for the right problem?’ This difference is not just a matter of wording. It reflects a shift in mindset: the ultimate goal is not to build a model with the most polygons, but to build a semantically rich city model that allows the city to analyze, operate, and make effective decisions at scale, with reasonable operational costs.
Let’s watch the Urban Digital Twin video from the PLATEAU project – Japan:
When LOD Is No Longer Just ‘Geometric Detail’
In modern Urban Digital Twin, LOD is not merely about adding geometry to the model. In essence, it is a mechanism to control the level of abstraction of urban data. When CityGML is used as the authoritative semantic dataset for downstream processing layers, each LOD choice not only determines ‘how’ the model looks, but also ‘how’ the data is used: what semantic richness it has, how it can be queried, what can be analyzed, and how the total operational cost (from parsing, validation, indexing to streaming and updating) will increase according to which graph.
In other words, increasing LOD not only makes geometry more detailed; it also entails more complex topology, an increased number of surfaces, heavier data in parsing/indexing, higher streaming costs, and a significantly longer maintenance lifecycle. At building-scale, these costs might not be large enough to be an issue. But when expanding to city-scale or national-scale, they begin to directly influence core architectural decisions—especially how we design storage, spatially fragment data, cache strategies, and update mechanisms.
Therefore, a common approach in Urban Digital Twin programs is “scale first, refinement later”: prioritizing the creation of a semantic city model light enough to scale across the entire city first, and then gradually increasing the level of detail by area or by specific use case. This is not a ‘sacrifice of quality’ but a strategy to balance semantic density, scalability, and long-term maintainability—three factors that are difficult to optimize simultaneously if one goes straight for hyper-detail from the outset.
CityGML 3.0 Is the Latest Standard, But Reality Is Still a Migration Process
To keep Part 3 grounded in implementation reality, CityGML needs to be placed within the context of standard transitions. CityGML 3.0 is currently the latest standard version. However, CityGML 2.0 is still widely used in existing data and pipelines, as most historical ‘data assets’ and many production workflows have been designed, tested, and operated stably on the 2.0 system. Therefore, instead of a one-time replacement, many systems opt for a gradual migration strategy: continuing to utilize CityGML 2.0 data while gradually upgrading data models, processing tools, and integration layers to be compatible with CityGML 3.0 according to a roadmap. This approach helps reduce pipeline disruption risks, optimizes transition costs, and most importantly, preserves operational continuity.
From an LOD perspective, this point has direct implications: when designing the Urban Digital Twin architecture, you don’t just choose ‘which LOD is sufficient’, but also need to consider that data and the ecosystem might be in a ‘hybrid’ state between 2.0 and 3.0 for an extended period. Therefore, interpreting LOD should avoid mechanical identification with a single version, and concurrently, the reference framework must be clearly stated to prevent misunderstandings during implementation.
An Important Note: ‘LOD’ In CityGML, BIM, and Realtime Rendering Are Not Synonymous
Before delving deeper, it’s necessary to clarify a common misconception in Digital Twin projects. In CityGML, LOD primarily refers to the level of geometric and semantic representation of an urban model at a large scale, with a focus on urban analysis capabilities, modeling consistency, and system scalability. Meanwhile, in the BIM world, ‘LOD’ typically means ‘Level of Development’, reflecting the completeness of information for design, construction, and building operations. And in realtime rendering or game engines, LOD is a problem of mesh simplification and performance optimization.
Level of Development in BIM
LOD in realtime rendering or game engine
Three concepts share the same acronym but address three different problems. Therefore, to avoid misaligned discussions, a small but important principle is to always clarify upfront: in this article, LOD is used in the CityGML/urban-scale sense, meaning an abstraction mechanism serving urban data architecture.
LOD According to CityGML: Understanding It Correctly to Use It Correctly
First, it’s important to emphasize a point to make this article ‘standard’ and avoid misunderstandings: the LOD0–LOD4 framework is typically presented most clearly and commonly in CityGML 2.0; while CityGML 3.0 has an updated organization and interpretation of LOD according to a new conceptual model. Therefore, in this section, we will use the LOD framework of 2.0 as a ‘common language’ to explain architectural trade-offs (which are still intuitively correct), while understanding that when implementing with CityGML 3.0, LOD should be referenced according to the corresponding 3.0 standard in the pipeline migration.
With CityGML 2.0, LOD0 typically acts as the spatial base layer—terrain and 2D/2.5D representations at the basic level. Although the geometry is simple, this is a crucial foundation for many GIS and planning tasks, as it provides other data layers with a unified reference system for overlay and analysis.
When transitioning to LOD1, buildings are typically represented as simple blocks with height. The strength of LOD1 lies in its trade-off: the geometry is light enough to scale over a large area, yet still provides sufficient volumetric information to perform various urban analyses at a macro level. It is here that the spirit of ‘computability first, fidelity later’ is clearly seen: prioritizing stable computational capabilities at a city-scale rather than immediately pursuing geometric detail.
LOD2 is often a crucial transition because the model begins to represent building envelopes with more analytical significance—especially when roof morphology and thematic surfaces (such as RoofSurface, WallSurface) are clearly depicted. This allows many urban environmental problems to be based on more ‘semantically correct’ geometry, rather than just relying on approximated bounding boxes. Simultaneously, this is also where semantic structure clearly demonstrates its value: the system not only ‘sees’ a building block but also ‘understands’ the components of the envelope for effective querying and simulation.
When advancing to higher levels of detail (often described as LOD3 and LOD4 in the 2.0 framework), benefits may increase for use cases requiring higher fidelity, but data and operational costs also rise very rapidly. This is why, in real-world city-scale scenarios, ‘pushing’ the level of detail to a high degree is usually only justifiable when there’s a clear use case, a defined spatial scope, and the pipeline is ready to bear the additional costs. Otherwise, the system can easily fall into a state of geometric richness but poor operational capability: heavy data, difficult updates, and ultimately, difficulty in generating value at a large scale.
Why Urban Digital Twin Cannot Be Built With a BIM Building-Scale Mindset?
The biggest difference between Urban Digital Twin and BIM is not about which model is ‘more detailed,’ but rather the inherent nature of the data system each is trying to build. In a traditional BIM environment, the central object is usually a single building or a campus with a relatively finite scope; data is built with high accuracy to serve design, fabrication, construction, and facility operation, so semantic detail goes very deep into materials, structures, MEP, and technical attributes.
But when expanding from building-scale to city-scale, the problem changes fundamentally. A city is an overlay of traffic, utility networks, vegetation, terrain, underground infrastructure, and environmental systems, while also carrying operational data flows that change over time. At that scale, data is no longer a ‘static record’ but the continuously changing operational state of the urban area. Therefore, if a building-scale mindset is directly applied to a city-scale, the pipeline will quickly face geometry overload, storage explosion, query bottlenecks, update complexity, and uncontrollable operational costs.
More importantly, a city-scale system not only needs enough semantic richness for analysis but also needs to be light enough for spatial and temporal streaming, distributed data synchronization, long-term cyclical updates, and stable maintenance over many years. When viewed this way, LOD is no longer a ‘measure of geometric detail’ but a data organization strategy to balance semantic richness, scalability, computability, and operational sustainability.
Conclusion: LOD Is a Data Architecture Decision, Not a Decorative Option
Continuing directly from Part 2 to Part 3, we can see a clear logical thread: after data has been inspected and brought to a validated & consistent state, the next question is not ‘does the model look good,’ but rather ‘what level of abstraction is sufficient to create operational value.’ LOD, therefore, becomes a decision layer at the very heart of Urban Digital Twin architecture: every decision to increase or decrease LOD directly impacts geometry complexity, streaming performance, query efficiency, storage overhead, update lifecycle, and the scalability of the entire platform.
Therefore, the most important question is no longer ‘how to make the most detailed model,’ but rather ‘what level of semantic detail is sufficient to create actual operational value at the most reasonable cost’—in a context where CityGML 3.0 is the latest standard but CityGML 2.0 remains strongly present in data and pipelines, making migration a practical strategy rather than a one-time replacement. And in the end, a successful Urban Digital Twin is not the system with the most polygons, but the system that helps the city understand, simulate, and operate itself more effectively based on data, in a scalable and sustainable way.
Concluding Part 3, it’s clear that LOD is a data architecture decision, not just about the ‘beauty’ of the model; however, for LOD to truly create value in production, the geometry must be correctly aligned with the real-world reference system. Even a mismatched CRS, a misunderstanding of height/height reference, or an error during the ETL conversion process can result in a model that is ‘structurally correct’ but spatially inaccurate, turning subsequent analyses or simulations into risks. Stay tuned for Part 4, which will delve into this foundational layer: CityGML Coordinates, Height, and Data Transformation.
