G’day all from down under. If I am modeling building assets to be used in an OpenBIM model, it would be logical for me to categorise them as the various IfcElements that they represent (e.g. my 3D door will be an IfcDoor). However, the IFC spec has shortcomings in describing some objects, such as landscaping (yes, I am aware that there is a current discussion about how to extend IFC to accommodate landscape), and sometimes lack the granularity that other classification systems provide.
I’m looking to hear more about how others in the industry organise their OpenBIM asset libraries? Do you:
Classify your BIM assets under their respective IfcElement
Classify your BIM asset using another system, such as Omniclass? (which do you use and why?)
Classify as both an IfcElement type and another system?
And I’m curious as to how people see the overlap between IfcElements and these existing classification systems. As the IFC entity vocabulary expands, will it make other systems like Omniclass obsolete? Will other players in the industry start using IFC types as a classification system?
In my experience, classification is often region, country or even project-specific. Many countries don’t have any national, imposed classification systems in use. IFC is luckily flexible and generic for that matter.
IMHO, the IFC classes are a form of classification and not a bad one at that. In fact, many IFC classes don’t add any real attributes or property sets, but simply make the IfcObjectDefinition tree deeper. I’m not too convinced about this approach and a more flexible tagging or classification seems (again IMHO) a better approach. I’d rather have the IFC class inheritance tree less deep, e.g. only up toll the “building element” level and define everything else via classification. You also see this in commercial BIM software. While there is a wall and a beam tool available, you need more flexibility to e.g. model a roof with a slab or a beam with a “generic object” or a wall using the beam tool, based on their geometrical behaviour.
In practice, I notice following implementation in the software systems I’m familiar with:
Several IFC viewers don’t show Classification References but only PropertySets.
Revit doesn’t know about classification as such, but has the built-in parameters Keynote and Assembly Code. I see there that people usually convene on having a few Shared Parameters with predefined but often project-specific naming to add some code or classification. The Revit classification manager creates additional Shared Parameters so is in line with this implementation. The current Revit IFC exporter allows you to identify a particular Parameter to be exported as IfcClassificationReference
ARCHICAD has a full classification implementation. It can be used to control mapping from objects to IFC classes and can (optionally) be configured to generate IfcClassicationReferences and values. It is very powerful as it also controls availability of Properties to elements from a particular classification.
SketchUp relies fully on its classification system to assign IFC classes to Components.
BricsCAD BIM relies on its internal AI to assign IFC classes to geometric elements. It is a form of automated classification.
Solibri reads IfcClassificationReferences from IFC-files and also has its own user-controllable and configurable classification system which allows you both manual and auto-generated classifications. An essential part of their model checking approach (often used as a filtering mechanism, to limit the checking of rules to elements which are classified with certain values). But Solibri doesn’t modify anything in the IFC file at all, so that custom system never arrives back into the IFC file.
My experience is that many, even experienced, BIM users don’t fully understand classification references in IFC and simply rely on custom PropertySets as this is visible in most IFC viewers. This is especially noticeable with Revit users. But with good configuration in the IFC Exporter you can have them properly stored in the IFC file so the lack of a classification system is not necessarily a problem.
Hi, and thanks to @stefkeB for his detailed answer. From an IFC development perspective I would summarize:
If you want to classify your component, then take:
the closes matching IFC class - e.g. IfcBeam
if not yet sufficient, take the predefinedType ans select the best fit, e.g. IfcBeam/JOIST
if not yet sufficient, set the predefinedType to USERDEFINED and add your own ObjectType
as an alternative, use your prevailing classification system (depending on country, region, etc.)
unfortunately, not all software systems support 3 and 4.
Regarding the question of whether or not IFC should have an own (shallow/deep) classification tree or should rely only on external classification systems - in my view, it is not an either/or answer. Both approaches have pros and cons. But I agree with @stefkeB that we should be overly careful not to create a too deep tree in the IfcObject specialization - particularly when moving to include infrastructure components.
Lot’s of great comments here. I believe buildingSMART Data Dictionary (bSDD) is a very powerful supplement to IFC when it comes to classifications. Done right, and with a tiny small support from some of the BIM authoring software out there, it would be possible for a user, in any project, to view the BIM data in their own familiar classification system, regardless of what the BIM actually contains.
It may even be possible to do this, without the support from the BIM authoring tools.
The idea is to allow the flexibility to organise your project data in your own way, and to allow many different views on the data, that matches the need of the user. For example, when I am looking at an IfcBeam, tagged with one classification item, I can also deduce which properties are valid in another classification system. bSDD has the power to map different classification systems, even though there may be no perfect one-to-one match between the systems. It also has the power to extend and enrich the IFC data, to allow a more semantically rich BIM, with localised properties.
It is great to see projects out there being more and more concerned about their data in their models, not just geometry.
As also @TLiebich said, many of the statements about not relying on the own IFC classes classification are based on the software architecture perspective. (i.e. points 3 and 4 of Thomas post list). It’s quite tiring to observe the number of discussions everywhere because of the lack of push from software users towards that. IMHO, the same with IfcClassificationReference. Why is so difficult to the most widely used IFC viewers (except Solibri and some other) to show Classification References tree?
I’m totally an upholder of Classification Systems use in models, because of their multiple benefits whatever the stage is. But we should use them under a standardized way, such IfcClassificationReference (w.o.e. using Assembly and Keynote codes?).
Sounds good - I consider this issue solved @TLiebich’s 4 steps covers it nicely, and it seems that it is community consensus that IfcClassificationReference is the way to go for step 4, even if implementations of it are spotty.
Nice discussion about the structure of IFC and relating classificationssystems. Even when the topic is solved, I even want to point out that IMHO it needs a standardized way to identify BuildingElements. I am just working at the swiss cost structure eBKP and we have good results with mapping by Ifc class and IfcPredefinedTypes. So in my opinion it needs a minimum of tree of ifcObject or at least of ifcBuildingElement to filter the elements with international software or MVDs.
As I understood the IfcClassificationReference is open and has no Vocabular, so it is useful as another layer keeping the classification of other standards like Omniclass. And related to the last question of @Moult it will need specific systems which coexists for different regions or tasks.
To add to the discussion, it also depends on the chosen classification system. E.g. some classification systems we encounter are closely related to Bill-Of-Materials and as such relate more to the materials and the way materials are applied in elements rather than on elements as a whole. This is often problematic in BIM software: you can classify an Element/Product/Object and a Space, but often not the Material and I know of no examples where you can actually classify e.g. layers in a wall. It may work with BuildingElementParts as they behave as other Elements.
I completely agree with the precise analysis by @stefkeB regarding the current IfcClassification and IfcClassificationReference support (or lack of, as pointed out by @TLiebich) from applications.
However, I would add usBIM.viewer+ to the list.
It is a free IFC viewer and editor that regarding the classification systems has the capability to take an already existing IFC file (2X3 or 4) and add/update/remove classification information based on common systems (Omniclass, Uniclass, etc.) or to add a custom schema, and to filter entities based on such informations.
adding to the software systems with classification implementation:
in vectorworks there is a notion of classes, which is practically the same as layers in autocad. the next control level are the design layers, being levels on which the elements are being placed (like the walls layer, the slabs layer, the furnishing layer a.s.o.). the topmost control are the storeys, the virtual containers that can have any number of design layers.
the classes define the look of the objects in 2d and in 3d, and their names come from classification systems. in the uk all vectorworks’ classes have the uniclass 2015 notation. listing the class name parts with the hyphen ‘-’ makes them hierarchical.
there is no need to translate anything to anything, just simply put the object in a class (for compound composites of wall/slab/roof components the classes’ assignment has been already prepared, both for the whole object and its parts separately).
there is no other software application on the market that can handle the classification and the ifc assignments that easily…
I didn’t know there’s an interesting discussion around classifications
Thank you all, especially @stefkeB who explained the issues very well
As we know each classification has developed based on an specific purpose, and the majority of them are just focused on the “construction” phase, some on Project Management side, some on Resource Management side
And I liked this part a lot:
This is often problematic in BIM software: you can classify an Element/Product/Object and a Space, but often not the Material and I know of no examples where you can actually classify e.g. layers in a wall. It may work with BuildingElementParts as they behave as other Elements.
I think this part even approves my approach in MaterialPass, (even ProductPass and FacilityPass):
These days I see some software have started to focus more on classification issues, especially multi-classifications which is good
I agree, classification systems are often connected to- or supplement national regulation and can also be project specific. Just to add more clarity I will share my perspective on this:
I see the BIM process information generation and management on two layers; On the first layer there is information creation, sharing, coordination, validation and this can all be based on the IFC data structure. This is the digital equivalent to a classic project development where the main goal is a succesfully streamed and on-time project finish.
But then there is a second layer. On this layer the appointing party doesn’t want only a finished project, but also needs additional information, upon which the finished project will be managable during it’s life cycle. This is where additional classification systems kick in. Any additional classification system usage (additional information) represents an organized data stucture, which can be further read with dedicated management tools.
Sometimes one might need one more translation/data structure layer like COBie between “as built Spec” and “Asset Management Spec”.
IFC can hold multiple classification assignments against any entity. The assignment includes the name, version and reference of the sources, as well as the code and description of the selected value.
Care is needed to not include arbitrary breakdown structures which aren’'t persistent and so aren’t as valuable.
