Connecting Properties to IfcBuildingElementPart

hi,

while I was working on extracting data from the IFC, it came to my attention that there is not really a logical connection between the IfcBuildingElement and IfcBuildingElementPart or maybe I lack the knowlegde in this department :slight_smile:
What do I mean by that?
An IfcBuildingElement as a structure can be composed out of multiple layers and has a Pset appendet to it. This Pset controls the attributes at the entity level of the building element and has no connection to the building element part. In a simple example, a wall (Masonry + Insulation) as a whole can be LoadBearing, but has no definition which of the layers from that composition is LoadBearing. It is human-readable, since a human can identify that layer either by name, color or even texture, but not machine-readable.

Wouldn’t it be more transparent if the attributes of the Pset could be connected to the IfcBuildingElementPart? Or even better, that the Pset are composed out of the level of IfcBuildingElementPart. This way the IFC structure would understand which layer is responsible for which criteria at the Pset Level of the entity, whether it is LoadBearing, Accoustical, FireRating, etc…
Therefore, if one Part of the Element is LoadBearing, it automatically gets transported to the whole entity. In the IfcBoolean world, this would mean that the TRUE statement always wins over the FALSE. In the numerical value, it simply gets transported to a higher instance.

Does this concept sound plausible to you?

To make matters even less convenient: while an IfcWall can be composed of IfcBuildingElementPart entities, it cannot be composed of say an IfcCovering.INSULATION and an IfcWall.STANDARD.

This also implies that the property sets available for covering and wall entities are not available for the building element parts.

And that may be one of the reasons why many contractors request such elements to be separated into independent entities, each with its own properties. But then the designer loses the notion of the wall as a whole, which still has functions as being room separating, load bearing or providing an acoustic barrier etc…

Add to that the fact that a large part of the users of Revit really prefer to avoid using parts so they model the components as separate Revit elements instead (but then lack the wall as a whole). In contrast, many users of Archicad or Vectorworks are more keen to keep the walls as a whole composite element, since their software has the option to generate the IfcBuildingElementPart upon export.

So you may have inconsistent IFC files due to different software habits.

And finally, many of the values you refer to may actually be a derivative of the IfcMaterial that is assigned to the parts or to the LayerSet assigned to the wall. And materials have their own property sets (although not many viewers even show you this and Revit users cannot even export materials with properties although the software has them natively).

So I believe it could be helpful if parts would be allowed to be real Entities in their own right (IfcWall, IfcCovering), with full support for property sets and be composed of materials, with their own property sets.

Your suggestion to have a type of inheritance or cascade of properties to the higher level is tricky, though, as it would imply a lot of duplication (upon export? by the user? by the viewer?) which leads to ambiguities or even contradictory information. I’m not convinced that this would lead to clean models.

1 Like

As an Archicad user, I admit that it is really easy to use composite materials to define a whole structure. It gets pretty good also in IFC. Sadly I cannot say how this works in Revit.

Appending the entity one level lower respectively, to the IfcBuildingElement part, would open the way to connect the PropertySets of the two worlds (IfcBuildingElement + IfcBuildingElementPart)
I have an example here of an IfcWall with a composite structure:

The user defines the entities in his BIM authoring tool for each layer and the composite as a whole. A concrete Layer is always going to be either a IfcSlab, IfcWall, IfcColumn, whereas an insulation an IfcCovering INSULATION. A well-structured database in the BIM authoring tool is necessary. The definition of the entities for the IfcBuildingElementPart should be a global function and not object defined.
Upon export, the Software appends entities and its corresponding PSets (according to IFC) to the Layers and Composites.

In the background, a mapping system should transfer the properties from the IfcBuildingElement to the IfcBuildingElementPart. Here is an example:

In this system there is only one way of override rule, meaning that the upper level overrides the lower level, as long it is not custom defined. The lower level will never override the upper level.
There are different scenarios how this system could work:

  • A Pset Value from the BuildingElement as LoadBearing can be transported only if such a Pset is available one level below.
  • PSet Values that are present at all lower levels (BuildingElementPart) will be distributed to all of them in the lower level, as an example the AccousticRating.
  • A Pset Value at the lower level could override the mapping from the upper level, such as in the case of the “Status”. In this case the mapping from the upper level will be disconnected.
  • If PSet Values are not part of the transfer, they can be left out blank or as ND. This will then be mapped at the lower level.
  • If the layer at the lower level does not possess an entity or is IfcBuildingElementProxy, no parameters will be transferred if not corresponding.

This also works for a horizontal element such as a IfcSlab that might have an IfcCovering FLOORING inside it. Properties from the upper level (IfcSlab) will be transferred to the lower level of the IfcCovering and IfcSlab.
Yes, there is always going to be a margin of error (user, software, mapping,…). But simply because we are not capable of defining certain parameters, does not mean that it is correct. That is why we have tools to check and correct them, in order to deliver reliable data.

1 Like