I understand that LODs (level of detail / development / design / whatever) are rather loosely defined, but it does serve a useful primary purpose - that at different stages of the design, BIM elements have varying levels of “resolution”. This information is useful, because right now, given a vanilla BIM model in practically any format (not just IFC), it is impossible for anyone to know how accurate that model is and what they can trust. It also doesn’t help that programs like Revit don’t understand the concept of NULL attribute value = don’t export, and tend to put a bunch of properties in there that may or may not be audited. This is bad - because architects don’t know what is resolved and what isn’t, QSes may not know how much error could be in the costing, shop drawers might not know what is ready and what isn’t, etc.
Does IFC have any concept following the premise of an LOD? i.e. that an element can be very resolved, or just schematic?
I absolutely agree that it’s a problem that you cant see the difference between a sketch and a finished designed element. But is this not solved with using classifications? I think that by using classifications you easily can adopt to your local standard(s). You also can make your viewer software display the classification in a way that fits your need.
Is there any way you think using classification doe’s not fill your need?
I think that’s why MVD (IFC data filter) and validation according to particular MVD is very important, to get ONLY required data for some particular purpose.
Hmm, I think MVD and LOD are two different things: MVD is whether or not the model is suitable for a usecase, LOD is how reliable the current state of data is in the model.
Currently there is not a complete classification to solve the issues related to LoD (which has lot of definitions)
But it seem that some classifications like CoClass have started to focus on it
Another issue is that “all classifications don’t support granular assets” this is why I introduced a concept that maybe IFC, IFD, and other groups focus on this “important” issue
MVD is not alternative to LOD.
For example using ReferenceView you can provide very different levels of details for geometry representations, from boxes to photo-quality with textures.
I do not think we have now LOD inside IFC, but you can use external specification.
IFC has one restriction here - only one Body representation. Some time ago I raised the question should not we allow more then one representation for Body to keep different LODs (or aspects) in one model.
@igor.sokolov sorry for the 2-years late response. I guess I was referring to contractual LOD which is slightly different to what you’re referring to. I guess you’re referring to things like high-res vs low-res. I guess this could be satisfied using different representation contexts - it’s not at all “official”, though.
@Hans_Lammerts as far as I understand it LoD1-4 refer to Level of Detail of as-built information. LOD100-500 refers to Level of Development, a concept more useful during design stages (pre-design/schematic/construction/etc.) so you can not really compare them. Note the small and big o notation (LOD/LoD), that’s usually how they are separated.
Who ever made this up? I think such a big difference in meaning (Development versus Detail!) with such a little suptile difference in its notation will not hold.
FWIW (another acronym), as part of EN 17412 there is no further talk about “level of development” or “level of detail”, but the notion of “level of information need”, a term which was defined in ISO 19650 (so that answers “who made this up?”). It has no acronym and is a more refined way to describe information needs on geometrical information, alphanumerical information and documentation.
The buildingSMART IDS project provides a standardised way to define the requirements for alphanumerical information (required properties) aligned with the IFC schema.
The EU standardisation group CEN/TC 442 is now continuing the work on “level of information need” after the publication of EN 17412-1:2020 in Parts 2 (guidance and application) and 3 (exchange format). The work is also being adopted for publication as ISO standard (ongoing).
From my point of view, the information requirements for geometry may stipulate (among some other aspects) the detail that is required. I have not seen any equivalent classes nor properties in the IFC schema that cater specifically for this. From our experience, most information requirements considering geometry fall back on the (simplified) “levels” as defined by AIA/BIMforum or using comparable approaches such as the Luxembourg GID or the Danish levels. The approach in EN 17412 is more refined, making the distinction between detail, dimensionality, location, appearance and parametric behaviour. Listing a series of geometry classes from IFC which are acceptable is possible via MVD, but that doesn’t specify anything about these aspects.
However, also from our experience, requirements considering alphanumerical information are often stated in a less formal way, using spreadsheets and tables of required properties stated in either plain language or using a common classification system. Clients, owners typically don’t state this using the IFC schema.
Where I do see the relation is a provided mapping to IFC classes and properties, as in the IDS project, as a way to not only express what you need, but also to state this in a way that you can check the deliveries as you make the required properties explicit.
Conclusion
IFC and LOwhatever are two quite different things…
