How does IFC work with existing classification systems such as Omniclass, Uniformat, etc?

Moult · December 30, 2018, 5:40am

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?

Would love to hear your thoughts.

stefan.markic · December 30, 2018, 10:40am

This is not a full answer to your question, but have you taken a look at the entity IfcRelAssociatesClassification and its member attributes?
http://www.buildingsmart-tech.org/ifc/IFC4/final/html/schema/ifckernel/lexical/ifcrelassociatesclassification.htm
Perhaps this leads you to your answers.

Moult · December 30, 2018, 10:28pm

Thanks, I hadn’t looked at the entity before, that looks like it’ll help implement an Ifc+foo classification

Still looking for discussion on the actual practice of classification and what people use.

stefkeB · January 2, 2019, 8:31am

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.

TLiebich · January 6, 2019, 8:08pm

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.

havard.bell · January 3, 2019, 7:23pm

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.

daviddelven · January 15, 2019, 3:28pm

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?).

Moult · January 6, 2019, 8:09pm

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.

rok · January 7, 2019, 3:36pm

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.

stefkeB · January 21, 2019, 8:37am

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.

michelangelo · March 14, 2019, 11:19am

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.