LOD – Level of Data, Level of Development, Level of Detail or just Level of Disorder?
Level of Detail – LOD for short – is a hot topic. As Building Information Modeling (BIM) becomes more prevalent across the AECOO industry, the use of LOD terminology can lead to confusion. A lack of clarity and specificity within LOD as to what is to be provided by whom and when creates challenges. We must define the data requirements of projects based on their purpose, goal, and downstream uses.
Understanding LOD and its limitations
Where did LOD come from? A concept borrowed from the gaming industry, the LOD of a modeled object was initially defined by its proximity to the viewer. The goal? To reduce mesh complexity and limit the amount of information to be processed. While borrowing the concept of LOD was reasonable in the early days of BIM, as the industry, technology, and complexity of projects have evolved, the way we use LOD also needs to change.
At first glance, LOD looks like a fairly simple framework. The complexity arises when we try to apply it. As LOD refers only to geometry representation to create drawings, it neglects the information associated with the geometry. More complex or detailed geometry does not equal a more developed or valuable model. The value-add comes when we associate structured data with geometry.
If you’re just beginning with LOD, start by identifying the required information to be derived from or associated with the geometry. Ask yourself:
- What is the information we want from placing geometry: size, location, level/orientation, clearances, and appearance?
- What data do we need to be associated with that geometry: classification name and number, type mark or mark, etc.?
- What is the information going to be used for? Different uses require different aspects to be precise. Estimating, for example, requires an accurate count whereas, for virtual coordination – important for Maintenance and Operations – location, size, and clearances are vital. Some uses require all outputs; others only some.
- Another variable is when during the process of design and construction is this information required? Some are required to drive design processes and others facility management.
This evolution has been identified in ISO 19650 as the ‘Level of Information Need’.
What is the Level of Information Need?
Introduced in ISO 19650-1, the level of information need, expands the scope of information collected from geometry to alphanumerical information and documents. The alphanumerical information is considered as important as geometry as it forms one of the most important outputs of a project.
The level of information need for each information deliverable is determined according to its purpose. This includes determining the quality, quantity, and granularityof information. This can vary from deliverable to deliverable and from design, construction, and handover needs.
While assessing level of information need is more prevalent in the UK than Canada, as the ISO 19650 framework becomes more widely adopted, so too will it be necessary to redefine the geometry and data requirements based on need, not on what a 2D drawing output will look like.
Revisiting LOD to improve data-driven processes
As the industry moves towards data-driven processes, it is crucial to revisit LOD and define data and geometry requirements based on downstream uses, rather than drawing output.
Assigning a blanket LOD to a model may easily result in the over-provision of information that is not strictly needed or, more seriously, the under-provision of information that is vital.
The more efficient and effective process, as identified in ISO 19650, is to define the requirements based on purpose, goals, and uses, identifying what aspect of the geometry needs to be accurate, that is, what information is required to be derived from that geometry, what downstream uses will rely on it and when, during the process, will it be required?
In addition, what data attributes are required to be associated with the geometry, and, again, when during the process is this information to be available within the data set to drive downstream uses?
In our experience, LOD terminology can lead to confusion and a lack of clarity as to what is expected from each party involved in the project. For example, the BIM Forum requires LOD300 geometry to obtain an accurate count, location, or elevation. However, these three attributes do not require complex geometry to drive downstream uses.
As the industry’s thinking changes from geometry-driven to data-driven, the value of a project will be determined by how structured the data coming from the models is, in a way that it can be automatically read and processed by a computer.
Fundamentally, the evolution of LOD appears to be driven by drawing output, not planned data uses. We need to ensure that we are providing the right information at the right time to achieve the goal of meeting the needs of facility management.
LOD is on everyone’s minds. I’d encourage you to dip into recent articles on LinkedIn or get in touch with us. We would love to discuss different ways of defining data and geometry and share our evolving approach to managing this complex issue.