LOD is a widely used acronym, but it is not always understood in the same way globally. For more than a decade, the acronym has had a few related meanings, including “level of detail,” “level of development,” and variants such as “level of information,” “level of accuracy,” “Level of geometry” and “level of model development,” all with a different meaning. The variants of LOD have been adopted in many organizational or national guidelines and have been stated in countless BIM execution plans (BEPs) across construction projects. However, as the concepts are different and their implementation is not always without ambiguity, it remains difficult to state information requirements univocally and to have it delivered consistently.

Moreover, the publication of ISO 19650-1:2018 has led to a new concept “level of information need,” which is intended to provide an improved approach to defining how information requirements can be specified optimally across a project’s life cycle as well as potentially adding confusion to the industry’s existing practice.

This article introduces this series of related concepts and brings you up to date with the globally standardized approach that the level of information need brings in the context of building information modeling (BIM).

The Concept and History of LOD

A good overview of the history and evolution of LOD can be found in the article “Many Faces of LOD” by Marzia Bolpagni (MACE).[1] It traces some of the original sources that explain how a few related concepts have been defined internationally and provides a comparison between the systems.

Before the adoption of BIM, the main method of communicating within projects was the drawings and specifications. Drawings showed in an abstract way the layout, dimensions, sizes and overall topology of a project. Using annotation and a series of drawing conventions, drawings could convey a lot of information on a project. Of notable importance in this discussion is how the drawing scale impacts the detail that is conveyed: large-scale drawings show no detail but can present global positioning and the project outline on a construction site. Medium-scale drawings show the structure and main dimensions of construction objects, enriched with annotations such as dimensions and textual labels. At a fine scale, the construction objects are then further subdivided into their components and the juxtaposition and connectivity of components can be displayed. This practice, which existed long before CAD, is still very common today. However, more and more projects develop these types of documents using BIM authoring software, such as Archicad, Revit or Vectorworks, and assemble the project using parametric 3D objects that represent the real-world objects.

Since a digital representation can be zoomed in or out almost limitlessly, it is possible to embed far more detail and include the tiniest component in the model. Developers of product libraries, especially for manufactured content, can embed the smallest details in their BIM-ready digital objects for use by architects, engineers and contractors.

A first definition of LOD can be understood as level of detail, and it is still commonly applied in the context of Geographic Information Systems (GIS), as well as in game development, where a real-time display of countless digital objects can be obtained by gradually displaying objects with more or less detail, depending on their distance from the viewer. Objects at a distance can be displayed as simplified but are switched to high-detail variants when viewed up close.

However, in the context of BIM, we are not only talking about the geometric detail but also the alphanumeric information that is embedded within objects: classifications, quantities, names and numbers, and all kinds of technical characteristics pertaining to material, performance or maintenance.

This information need evolves throughout a project and some information is only needed or known at a particular project stage. Moreover, only after certain key decision points are attained can the information be relied upon, for example, to begin construction or to extract quantities. The reliability or certainty level is what is implied with the so-called level of development or level of model development.

For example, in an early draft of a project, objects can be represented using simplified geometry, like a box or cylinder, and with just a few attributes or properties, like a type or classification and some indication of the material they are composed of.

When developing the model toward the final design stages, the shape of the object geometry becomes more refined, even though in many cases they are still quite generic (the object is said to be a beam, column, chair or boiler). However, apart from its nominal sizes and a series of identification and performance requirements, the model is not yet specified as an actual product by a manufacturer.

The use of such models is mostly to communicate design intent, clarify the project to the authorities in the context of a building permit, and present the project as part of a typical tendering procedure for the contractors to estimate the project’s costs, and prepare for construction.

At the end of the construction phase, many choices have been finalized and thus the geometrical and alphanumerical information in models has become more reliable, since they now contain specified products, with accurate sizes and  positions of inlets or outlets according to the chosen design. This also leads in many cases to more detailed geometry and more complete alphanumeric information.

Standardizing “Level of D”

Since this process is very similar across countries and construction projects, it makes sense to standardize the approach to help people optimize their modeling methods. Rather than expressing this by using a traditional drawing scale, concepts such as “level of detail,” “model progression specification” and “level of development” have been established. We refer to the article by Bolpagni, which provides an in-depth overview and comparison of the different approaches.

One widely used specification for LOD can be found in the “Level of Development Specification,” which is published and updated yearly by BIMForum[2] and is based on specifications by the American Institute of Architects (AIA). This specification explains a common approach with references and examples in two guidance documents. The first volume introduces the concepts and contains an extensive series of illustrated explanations for a variety of construction objects, focusing on how objects or model elements can evolve throughout a project. The second volume presents a set of schedules focusing on properties and how you can specify requirements at the alphanumerical level across project stages.

For a better understanding, we repeat the most important concepts here from the BIMForum specification:

• The level of development is stated at an object level, not at the model, since different objects can be at different levels of development across a single model.
• The use of “development” rather than “detail” is used to indicate the degree to which you can rely on the information and not by how much detail there is.
• Five main levels have been defined initially using a numerical label in steps of 100, theoretically allowing for intermediate levels if needed. The labels as such are rather arbitrary but represent the gradual evolution that is typically seen in a project. The initial set of five levels from the AIA and their interpretation by BIMForum are summarized here:

–   LOD 100—symbol or generic representation, not geometric representation

–   LOD 200—generic system object or assembly, approximate/generic placeholders

–   LOD 300—specific system, object or assembly/can be measured and is located accurately

–   LOD 400—specific system, object or assembly, with detailing, fabrication and installation information/sufficient for fabrication

–   LOD 500—field verified representation/no higher progression

However, based on industry feedback, LOD 350 has been added to these five as an intermediate level that occurs between design and construction to better support trade coordination, including to better articulate the connection between elements.

In addition, LOD 500 is not covered further, as there would be no geometrical difference between it and LOD 400. Moreover, the usage of the “levels” for alphanumerical information in volume 2 has been replaced with a schedule of required properties against different project stages or milestones, which is a more straightforward method to adopt and interpret.

Let’s clarify this with a few examples.

A steel column would be just a plain box at LOD 100 and a simplified I- or H-profile at LOD 200. At LOD 300, however, you would have the exact profile and shape of the object. From LOD 350 on, you’d also get connection plates, bolts and anchors—and eventually, at LOD 400, even welds, washers and nuts would be added to the geometry.

For a window or door, LOD 100 would only show them indicated in the mass model. At LOD 200, you would have a single object, mainly indicating its size and depth, but nothing else. At LOD 300, the distinction between glazing panel and mullions and components would be included geometrically. At LOD 350—and especially at LOD 400—you would have the exact profiles, support systems and even sealants, flashings and membranes. This last level is often not required in the model unless the model element is used as input for the generation of fabrication information.

It is important to note the relationship between the levels and the different project stages. By including descriptions such as “fabrication-level detail,” the intention of the different levels is spelled out very clearly. This is also noticeable in a variety of other related guidelines, where the levels already imply certain usages or purposes and are often intended for specific project phases.

From the examples above, we can also understand that there is not always a need to have all elements at the same level: the LOD 300 window may be sufficient throughout the project, whereas the structural model elements could require LOD 350 or even up to LOD 400. And in contrast, some of the furniture or mechanical, electrical and plumbing (MEP) elements may never need to be delivered above LOD 200 or 300.

LOD in BIM Authoring Software

When we look at modeling software, they all have a very generic approach to creating objects: you can either make them very detailed or completely abstract as you see fit. Using the various viewing tools and a configuration of filters and display settings, you can develop a model that can be represented with different detail as needed. We illustrate this with two common software systems: Autodesk Revit and Graphisoft Archicad.

Autodesk Revit is widely used across projects of all sizes. But while the software comes with a default set of content (families), most offices develop their own or use commercially available libraries instead. As part of the settings of any graphical view, you can indicate the detail level that is applied: coarse, medium or fine. Depending on the content you insert, this may impact their representation, as you can make the visibility of (sub)components dependent on this detail level. These three (fixed) levels don’t align directly to the LOD levels from BIMForum, however, so you must adopt a certain logic if you want to apply such levels, for example, using “coarse” for LOD 100 and 200, “medium” for LOD 300 and 350, and “fine” for LOD 400. However, this is not a general rule and the practical implementation may vary considerably. Perhaps you prefer “fine” to align with LOD 300 to 400 instead and use other means to distinguish between generic and specific content, for example, by swapping families with others. Sometimes people turn the LOD into a custom parameter, using it in the family definition to control the visibilities of certain components to reflect the LOD, but that isn’t a general rule either. At a view level, it is set independently from the view scale.

A different approach can be found in Graphisoft Archicad. Archicad library objects are scripted using the Geometric Description Language (GDL), and it is up to the object developer to take aspects such as Scale or Model View Options (MVO) into account. Even then, there is no straightforward alignment between drawing scale and LOD, so this is also left to the user for interpretation. The MVO-mechanism, however, is more streamlined, as it brings global control over visibilities and detail level, with “schematic, simplified, full” used for most objects, and even “low 1, low2, medium, full 1 and full 2” used for some others. The MVO is set per view, allowing multiple objects to adapt without further action by the user.

A huge difference from the Revit approach is that an object in Archicad remains very compact, as a single script can cater to a whole variety of scales or detail levels, turning the object scale sensitive. With geometry-based families in Revit, you must embed all the different detail levels into the family, increasing their file size and that of the project into which they are inserted. This may also impact the software performance, especially with larger model files.

Both approaches discussed here give control and allow objects to be presented differently based on a global detail setting, which makes it easier to prepare for LOD requirements.

Alternative approaches can be adopted in most software, including having view-dependent blocks or symbols or applying layers to switch between detail levels, but even then, you often must include different instances of geometry for each detail level.

In contrast, if we look at specification and requirement management software, such as Plannerly[3] or BIMQ,[4] they have been strategically adopting a more generic, open approach toward LOD and its related specifications. Rather than fixing the levels, these platforms allow you to set up and label different levels as you see fit, possibly according to a regional standard. They do provide templates or preconfigured setups with the BIMForum LOD specification used as a starting point, due to its wide adoption.

After the requirements are stated, it remains the responsibility of the modelers to ensure that they follow the specification when creating their models in dedicated authoring software, by setting up suitable templates, view filters and display settings. It may require the adaption of library objects if they are not already set up for the required detail and attributes.

A Series of Considerations Related to Level of Development

Since its first publication nearly a decade ago, the BIMForum specification has seen wide adoption, not only in the U.S. but also internationally. The clarification of the images has proven attractive to many BIM practitioners worldwide.

However, its adoption in the industry has also raised some concerns and is still a cause of discussion in projects today. The seemingly simple concept of having just five LODs proves to be a tough nut to crack in day-to-day practice.

Are Five Levels Sufficient?

When looking at the three Detail levels in Revit (coarse, medium and fine), you would think that five would be more than enough. When you compare this with Drawing Scale, however, there are much more than just five scales that are relevant in a project and that cannot be covered with these levels. There is not a “right” amount and any fixed scale will eventually present limitations.

Are the Levels Not Simply Project Phases?

While this is not the intention of the BIMForum LOD Specifications, many other guidelines have made that relationship rather explicit, with the levels being defined per project phase and increasing in each phase, for example, 100 for brief, 200 for preliminary design, 300 for final design, 350 for technical design and coordination, and 400 for construction.

One could argue that the “labels” become a series of milestones, indicating the appropriate amount and reliability of information at each of those milestones.

How to Assess LOD?

While the specification of the information requirement is intended to inform the creation of the information (e.g., with how much detail should a column or beam be modeled?), it is not trivial to evaluate the level upon delivery.

A slightly cumbersome suggestion can be found in the second volume of the BIMForum specification, where two LOD properties are suggested: target LOD and current LOD. The target represents the intended LOD, but the current LOD is not easy to derive, let alone verify. Reading a geometrical representation for an element and figuring out its LOD is not a resolved problem. Rule-based methods and even machine learning models have been attempted and have shown some progress, but the formulation of LOD levels is not sufficiently absolute.

For example, imagine a plain rectangular wall or column without openings or special reinforcement in a homogeneous material. It would be represented as a box at almost every level, apart from maybe LOD 400 or possibly 350.

What About the Level of Information?

Earlier versions of the LOD Specification suggested defining LOD profiles, indicating which properties are required at each level. We have encountered many projects and guidelines that have stated that LOD = LOG + LOI. That seems simple—but is it? This approach was eventually abandoned in favor of more explicit property requirements that state the per-project milestone.

When you state LOD 300 for an element, you still need to check the requirement schedule to confirm the project milestone, as this should indicate what property is required for each of the identified element classes.

Simplified fragment of a property requirement table

Toward Level of information Need

In 2018, the ISO/TC 59/SC 13 committee, which is responsible for the global international standardization work on building information modeling for construction works, published the first two parts of the ISO 19650 series. Based on previous work developed in the UK in the BS/PAS 1192 series, these process-related standards aim to harmonize information management across a project’s life cycle. Rather than being an in-depth technical standard on technology or formats related to BIM, they define the process itself by introducing a new series of concepts and principles (ISO 19650-1), describing the information delivery process from project assessment toward handover (ISO 19650-2) and the consequential use of asset information in the operational phase (ISO 19650-3), which was published a few years later.

Within ISO 19650-1, the concept of “level of information need” was introduced, which is a “framework which defines the extent and granularity of information.” It is noted that one of its purposes is to prevent the delivery of too much information.

As part of ISO 19650-2, the level of information need is related to the so-called “information container” as the carrier of packages of information to be delivered. In most cases, such information containers are our digital documents (3D models, 2D CAD drawings, schedules ...) that must be delivered at different project milestones. Part of the BIM Execution Plan (BEP) is the requirement to develop a so-called Master Information Delivery Plan (MIDP), which federates all the different schedules of information deliverables from different task teams.

In contrast with the previous concepts, the level of information need has no commonly accepted acronym. Nonetheless, the obvious acronym has already been applied in many schedules, especially when trying to fit the title into the table header.

Further standardization of the concept has been elaborated in CEN/TC 442, at the European standardization committee, with Bolpagni as the task group leader, and has resulted in the publication of EN 17412-1:2020. Two additional parts of the series are in preparation. Due to the close collaboration with the ISO/TC 59/SC 13 committee, there has since been an agreement to bring this standard to ISO level as it was seen as being globally relevant for standardization. This is currently an ongoing process and, if approved, will be published as the ISO 7817 series.

Concepts and Principles

Rather than embedding purpose and milestones into the definitions, the level of information need framework states them as prerequisites: What should be clear before you can state the actual requirements? And this is mostly a purpose-driven approach: you need to state why you need information (= purpose), by who and for whom (= actor), and when it is required (= milestone). And finally, to identify the required object, you must identify it in a relevant breakdown structure, like a dedicated code or classification system, such as OmniClass or Uniclass.

It is important that the prerequisites be understood as input, rather than as part of the definition. There is no “fabrication-level” geometry, but when fabrication is identified as a purpose, suitable geometric information will be chosen. It’s a rather subtle nuance, but it provides a more expressive way to state requirements. Without stating purpose or milestone, it makes no sense to define the requirement in the first place. In the same way, the “level” does not define the phase, but when a phase or milestone is stated, a suitable level can be specified.

Stating Level of Information Need

To state the level of information need, we distinguish between geometrical information, alphanumerical information and documentation. In the context of this article, we mainly look at the first two, as they have a close equivalent in LOD.

How to Express Requirements for Geometrical Information?

This is split across five aspects: detail, dimensionality, location, appearance and parametric behavior. Detail relates to the complexity of the representation of the object. Dimensionality can be 3D, but 0D (point), 1D (line) and 2D (surface) may also be stated. For location, we distinguish between absolute or global and relative, against another point of reference. Appearance deals with visual and surface qualities, independent of detail, and finally, parametric behavior may be a requirement or not, which has an impact on the type of geometry and possibly file format that would be used to deliver the geometrical information. In this article, we focus on detail, as it relates most closely to LOD.

Rather than defining a set of fixed levels, detail is seen as a continuum. It relates to the complexity of the geometrical representation and can vary from simplified to detailed. In Part 2 of the standard, a set of statements is suggested to describe the geometrical requirements:

• Do you require just a simple placeholder geometry?
• Is the outer shell or envelope of the object sufficient or is it also necessary to include interior components and openings?
• Are connections to other objects required (as is the case with LOD 350)?
• Are smaller features such as chamfers or bevels required?

If we return to the example of the steel column, we can state it as follows:

• During preliminary design, the structural engineer only requires the analytical model for the structure to be entered into a calculation software. A 1D dimensionality suffices (axis of the column), positioned relatively to the story. There are no requirements on appearance or parametric behavior. The detail is simplified and really is only a placeholder since the profile has still to be defined during the analysis.
• When finalizing the design, the architect requests from the structural engineer a more detailed geometry for the steel column once the structural calculations have been performed. The purpose at that point is coordination and documentation. This requires the outer shell of the element, with dimensionality 3D and positioned relative to the building story and other elements nearby. The appearance of the beam should reflect the material (steel), but no parametric behavior is required. The detail of the steel column should include the actual profile (ideally from a catalog) and eventual cutoffs at the column’s end sides.
• During construction, the contractor has even further requirements, such as the connection plate and bolts, but also any possible openings or breakthroughs, resulting from the coordination between the structure and MEP.

While this example still allows a mapping to the previous LOD levels, we have a more expressive way to specify the geometry.

Expressing Alphanumerical Information Requirements

Whereas the expression of geometrical information requirements is still being refined, alphanumerical information requirements (required properties) are more established, especially due to other related work at the ISO/CEN level.

The notion of requiring “levels” has been replaced with identifying the required properties at the required milestone. In many projects, owners and other information receivers use spreadsheets to list all the required properties, which are then used to set up the models with the necessary data fields to capture them. All current BIM software is perfectly capable of adding user-defined properties or records to objects.

Computer-interpretable or Human-readable?

While many projects apply schedules in spreadsheets to express information requirements, they are considered only human readable. When you want to automate and check information requirements, you must translate the requirements into a series of model checking rules for software such as Solibri or BIMcollab ZOOM. Work is ongoing for Part 3 of the EN 17412/ISO 7817 series to establish a computer-interpretable exchange format that will allow the level of information need specification to be used for automatic verification of information deliverables.

In this context, we also want to explicitly refer to buildingSMART. As the global organization for the standardization of construction information, their Industry Foundation Classes (IFC) have been implemented in every BIM software. While it still requires a translation step, the export of model information from your authoring software into IFC is well supported.

Moreover, since buildingSMART also provides a large series of standardized classes/entities, information requirements can align or map to the IFC scheme, making it a software-independent process. And when looking at the required alphanumerical information, more and more requirements take the predefined properties and property sets as defined by buildingSMART into consideration, making it easier to standardize and align between projects, parties and organizations.

Since the publication of EN 17412, buildingSMART has launched a project for a standardized Information Delivery Specification (IDS).[5] The working group has publicly released the first versions of the specification and is working with software vendors to check implementation to facilitate user adoption.

In contrast to “level of information need,” IDS is an XML-based exchange format aimed only at expressing alphanumerical information requirements: Which properties are needed in a model? There has been a deliberate decision to not consider geometrical information. Moreover, IDS assumes that the IFC scheme is being used since the filters and criteria are expressed using IFC entities (classes) and properties.

This approach does not replace “level of information need” but could be seen as a complementary specification. After the statement of your information requirements, the alphanumerical part could be used to state them in a computer-interpretable way, allowing IFC models to be automatically checked against the requirements: Does your IFC file contain the required properties as stated in the IDS?

Conclusion

In this article, we provided an overview of a few related concepts when expressing detail, geometrical and alphanumerical information in projects where BIM is applied and pointed to a few ways that current authoring software provides support to control it in models.

We also referred to current international standards, where these concepts have been redefined as “level of information need” and some of the work that is occurring in the standardization committees and with buildingSMART.

Disclaimer: The author is involved in the standardization committee developing the EN 17412 series and upcoming ISO 7817 standards on level of information need.