Agreement for definition of opening geometry either as IfcOpeningElement or as part of a CSG tree
Based on IFC2x3
Initiator Official buildinSMART IFC2x3 CV2.0 certification programme
Effects Coordination View 2.0
Date 2013 01
Openings having a particular semantic meaning, such as window or door openings, of elements like walls, slabs etc. should be defined using an IfcOpeningElement instance (associated via an IfcRelVoidsElement relationship). In this case, the opening element must define the opening geometry, which is subtracted from the element geometry. Then the element geometry (of the wall, slab, etc.) must be defined without those openings.
If the element geometry however is already defined with openings, for instance using CSG or Brep representation type, including the opening geometry, no IfcOpeningElement shall be used to assign the opening in addition.
The opening geometry of an element with openings (or other subtraction, such as recesses, etc.) shall be defined only once, either by the IfcOpeningElement instance, or by the element geometry (using Brep or CSG representation type). It is illegal to define the same opening geometry twice (by the element geometry and an associated IfcOpeningElement).
In the case of an IfcWall or IfcSlab having a Brep representation type with openings already resolved, no IfcDoor or IfcWindow can be associated to the opening. Such IfcDoor or IfcWindow objects need to be defined as "free standing door/window" without the IfcRelFillsElement relationship.
In case of aggregated elements, such as an aggregated wall having IfcBuildingElementPart's, the agreement also applies to the parts, i.e. if the aggregated IfcWall has an IfcOpeningElement associated, then the opening volume shall not already be cut-out from the body of the parts.