IFC Syntax : Building Elements
A building element is a physical part of the construction : a wall, a slab, a door.
This skill covers the concrete element entities, their type objects and
PredefinedType enumerations, how an element is placed into the spatial structure,
and the opening / void / fill triad used for a door or window in a wall.
Applies to IFC2x3, IFC4, and IFC4.3. The abstract supertype was renamed across
versions : see Version Differences.
Quick Reference
The element supertype and the hard rename
Every concrete building element is, through inheritance, an IfcElement and an
IfcProduct (so it carries ObjectPlacement and Representation). The direct
abstract supertype changed name :
- IFC2x3 and IFC4 :
IfcBuildingElement (abstract).
- IFC4.3 : the entity was RENAMED to
IfcBuiltElement and made non-abstract.
ALWAYS write IfcBuildingElement for an IFC2x3 or IFC4 file and IfcBuiltElement
for an IFC4.3 file. NEVER use IfcBuildingElement in an IFC4.3 file : that name
returns HTTP 404 in the IFC4.3 schema and the file is invalid. This is a hard,
file-breaking rename. See ifc-core-entity-hierarchy.
The concrete element catalogue
Every entity below is a subtype of IfcBuiltElement (IFC4.3) /
IfcBuildingElement (IFC2x3, IFC4). Each occurrence entity (from IFC4 onward) has a
matching type entity and an OPTIONAL PredefinedType.
| Occurrence | Type object | PredefinedType enum | What it is |
|---|
IfcWall | IfcWallType | IfcWallTypeEnum | A vertical space-separating element |
IfcSlab | IfcSlabType | IfcSlabTypeEnum | A horizontal element (floor, roof, landing) |
IfcBeam | IfcBeamType | IfcBeamTypeEnum | A horizontal structural member |
IfcColumn | IfcColumnType | IfcColumnTypeEnum | A vertical structural member |
IfcMember | IfcMemberType | IfcMemberTypeEnum | A generic structural member (brace, mullion) |
IfcPlate | IfcPlateType | IfcPlateTypeEnum | A planar element (sheet, gusset, panel) |
IfcDoor | IfcDoorType | IfcDoorTypeEnum | A door (fills an opening) |
IfcWindow | IfcWindowType | IfcWindowTypeEnum | A window (fills an opening) |
IfcRoof | IfcRoofType | IfcRoofTypeEnum | A roof assembly |
IfcCovering | IfcCoveringType | IfcCoveringTypeEnum | A finish (ceiling, flooring, cladding) |
IfcStair | IfcStairType | IfcStairTypeEnum | A stair assembly |
IfcRailing | IfcRailingType | IfcRailingTypeEnum | A railing (handrail, balustrade) |
IfcFooting | IfcFootingType | IfcFootingTypeEnum | A foundation footing |
IfcBuildingElementProxy | IfcBuildingElementProxyType | IfcBuildingElementProxyTypeEnum | An element with no specific entity |
Full enum value lists are in references/methods.md.
A concrete element entity : IfcWall
Verified verbatim (IFC4.3) :
ENTITY IfcWall
SUPERTYPE OF (ONEOF
(IfcWallStandardCase))
SUBTYPE OF (IfcBuiltElement);
PredefinedType : OPTIONAL IfcWallTypeEnum;
WHERE
CorrectPredefinedType : NOT(EXISTS(PredefinedType)) OR
(PredefinedType <> IfcWallTypeEnum.USERDEFINED) OR
((PredefinedType = IfcWallTypeEnum.USERDEFINED) AND EXISTS (SELF\IfcObject.ObjectType));
CorrectTypeAssigned : (SIZEOF(IsTypedBy) = 0) OR
('IFC4X3_DEV.IFCWALLTYPE' IN TYPEOF(SELF\IfcObject.IsTypedBy[1].RelatingType));
END_ENTITY;
The shape is the SAME for IfcSlab, IfcBeam, IfcColumn, IfcMember, IfcPlate,
IfcRoof, IfcCovering, IfcStair, IfcRailing, IfcFooting : a single OPTIONAL
PredefinedType, a CorrectPredefinedType rule, a CorrectTypeAssigned rule. The
schema name in CorrectTypeAssigned is version-specific.
CorrectPredefinedType : if PredefinedType is USERDEFINED, the inherited
IfcObject.ObjectType MUST be set.CorrectTypeAssigned : if the occurrence is typed, the type MUST be the matching
*Type entity (an IfcWall is typed only by an IfcWallType).
IfcDoor and IfcWindow : the extra attributes
IfcDoor and IfcWindow carry size and operation attributes the others do not.
Verified verbatim (IFC4.3) :
ENTITY IfcDoor
SUBTYPE OF (IfcBuiltElement);
OverallHeight : OPTIONAL IfcPositiveLengthMeasure;
OverallWidth : OPTIONAL IfcPositiveLengthMeasure;
PredefinedType : OPTIONAL IfcDoorTypeEnum;
OperationType : OPTIONAL IfcDoorTypeOperationEnum;
UserDefinedOperationType : OPTIONAL IfcLabel;
WHERE
CorrectPredefinedType : ...
CorrectTypeAssigned : ...
END_ENTITY;
IfcWindow is the same shape with PartitioningType (IfcWindowTypePartitioningEnum)
and UserDefinedPartitioningType in place of the door's operation attributes. The
OverallHeight / OverallWidth attributes were present in IFC2x3 ; the
PredefinedType and operation attributes were added in IFC4. See Version Differences
and references/methods.md.
Placing an element : IfcRelContainedInSpatialStructure
An element is NOT geometrically inside its storey ; it is linked to a spatial level
by an objectified relationship. Verified verbatim (IFC4.3) :
ENTITY IfcRelContainedInSpatialStructure
SUBTYPE OF (IfcRelConnects);
RelatedElements : SET [1:?] OF IfcProduct;
RelatingStructure : IfcSpatialElement;
WHERE
WR31 : SIZEOF(QUERY(temp <* RelatedElements |
'IFC4X3_DEV.IFCSPATIALSTRUCTUREELEMENT' IN TYPEOF(temp))) = 0;
END_ENTITY;
RelatingStructure : the single spatial container (an IfcBuildingStorey,
IfcSpace, IfcSite, ...).RelatedElements : the elements placed in it.
ALWAYS place every physical element in exactly ONE spatial container through an
IfcRelContainedInSpatialStructure. NEVER leave an element with no containment link :
an uncontained element is an orphan and most viewers will not show it. See
ifc-core-spatial-structure.
The opening triad : void then fill
A door or window in a wall is THREE relationships, not one. A void is cut into the
wall, then the void is filled by the door.
IfcWall --[IfcRelVoidsElement]--> IfcOpeningElement --[IfcRelFillsElement]--> IfcDoor
Verified verbatim (IFC4.3) :
ENTITY IfcRelVoidsElement
SUBTYPE OF (IfcRelDecomposes);
RelatingBuildingElement : IfcElement;
RelatedOpeningElement : IfcFeatureElementSubtraction;
END_ENTITY;
ENTITY IfcRelFillsElement
SUBTYPE OF (IfcRelConnects);
RelatingOpeningElement : IfcOpeningElement;
RelatedBuildingElement : IfcElement;
END_ENTITY;
The "Relating" anchor REVERSES between the two : in IfcRelVoidsElement the wall is
RelatingBuildingElement ; in IfcRelFillsElement the opening is
RelatingOpeningElement. IfcOpeningElement (a subtype of
IfcFeatureElementSubtraction) is the void itself ; it carries an OPTIONAL
PredefinedType of IfcOpeningElementTypeEnum (OPENING, RECESS, USERDEFINED,
NOTDEFINED) and the inverse HasFillings.
Infrastructure elements (IFC4.3 only)
IFC4.3 added subtypes of IfcBuiltElement for infrastructure. They do NOT exist in
IFC2x3 or IFC4 :
IfcCourse : a layer of a built-up element (for example a course of bricks).IfcKerb : a kerb / curb edging.IfcPavement : a pavement surface layer.IfcRail : a running rail of a railway.IfcBearing : a structural bearing transferring load between elements.
ALWAYS restrict these entities to IFC4.3 files. NEVER write IfcKerb or IfcRail
into an IFC2x3 or IFC4 file.
Version Differences
| Item | IFC2x3 | IFC4 | IFC4.3 |
|---|
| Abstract supertype | IfcBuildingElement | IfcBuildingElement | IfcBuiltElement (renamed, non-abstract) |
Occurrence PredefinedType | absent | present | present |
IfcDoor.OperationType / PredefinedType | absent (operation on IfcDoorStyle) | present | present |
IfcWallStandardCase | present | present | present but DEPRECATED |
IfcWallElementedCase | absent | present | DELETED |
IfcSlabStandardCase, IfcSlabElementedCase, IfcBeamStandardCase, IfcColumnStandardCase, IfcMemberStandardCase, IfcPlateStandardCase | absent | present | DELETED |
Infrastructure elements (IfcKerb, IfcRail, ...) | absent | absent | present |
ALWAYS model a wall as a plain IfcWall with an IfcMaterialLayerSetUsage instead
of IfcWallStandardCase : the StandardCase entity is deprecated in IFC4.3 and its
siblings were deleted.
Decision Trees
Which element entity?
What is the physical element?
|
+-- A vertical space-separating element --> IfcWall
+-- A horizontal floor / roof slab / landing --> IfcSlab
+-- A horizontal structural member --> IfcBeam
+-- A vertical structural member --> IfcColumn
+-- A brace, mullion, post, generic linear member --> IfcMember
+-- A planar element : sheet, gusset, curtain panel --> IfcPlate
+-- A door --> IfcDoor (fills an IfcOpeningElement)
+-- A window --> IfcWindow (fills an IfcOpeningElement)
+-- A roof assembly --> IfcRoof
+-- A finish : ceiling, flooring, cladding --> IfcCovering
+-- A stair assembly --> IfcStair
+-- A railing : handrail, balustrade, fence --> IfcRailing
+-- A foundation footing --> IfcFooting
+-- Genuinely none of the above, semantics unknown --> IfcBuildingElementProxy
A concrete entity or IfcBuildingElementProxy?
Does a concrete IFC entity match the element's semantics?
|
+-- YES --> ALWAYS use the concrete entity (IfcWall, IfcBeam, ...).
|
+-- NO, it is a real construction element with no matching entity
--> IfcBuildingElementProxy, PredefinedType = ELEMENT or USERDEFINED.
NEVER use it as a spatial or void placeholder : use IfcVirtualElement.
Type object : create one or not?
Will many occurrences share the same definition (a "300mm cavity wall")?
|
+-- YES --> create one IfcWallType, attach occurrences via IfcRelDefinesByType.
| Shared property sets live on the type's HasPropertySets.
|
+-- NO, a one-off element --> a bare IfcWall occurrence is valid on its own.
If typed, the type MUST be the matching IfcWallType (CorrectTypeAssigned).
Door or window in a wall : how many relationships?
Placing a door into a wall?
|
+-- Step 1 : create the IfcOpeningElement (the void).
+-- Step 2 : IfcRelVoidsElement : RelatingBuildingElement = wall,
| RelatedOpeningElement = opening.
+-- Step 3 : IfcRelFillsElement : RelatingOpeningElement = opening,
RelatedBuildingElement = door.
The wall, the opening, and the door are each contained in the spatial structure
separately. NEVER skip the opening : a door is never voided into a wall directly.
Patterns
Pattern : Place every element in the spatial structure
ALWAYS link every physical element occurrence to exactly one spatial container with
an IfcRelContainedInSpatialStructure : RelatingStructure is the storey or space,
RelatedElements lists the elements.
ALWAYS reuse one relationship for many elements in the same storey : RelatedElements
is a SET [1:?].
NEVER leave an element uncontained : an orphan element fails validation and is
invisible in most viewers. See ifc-core-spatial-structure.
Pattern : Create an element with a shared type
ALWAYS model a definition shared by many occurrences as a *Type object (an
IfcWallType for walls), and link the occurrences with IfcRelDefinesByType
(RelatingType = the type, RelatedObjects = the occurrences).
ALWAYS type an occurrence only with its matching type entity : the
CorrectTypeAssigned rule rejects an IfcWall typed by an IfcSlabType.
See ifc-core-entity-hierarchy and ifc-impl-authoring-file.
Pattern : Set PredefinedType correctly
ALWAYS pick the PredefinedType value from the element's own enumeration : an
IfcWall uses IfcWallTypeEnum, an IfcBeam uses IfcBeamTypeEnum.
ALWAYS set the inherited ObjectType (IfcLabel) when PredefinedType is
USERDEFINED : the CorrectPredefinedType rule requires it.
ALWAYS use NOTDEFINED when the type is genuinely unknown ; NEVER leave
PredefinedType mismatched to the entity.
NEVER write a PredefinedType on an element occurrence in an IFC2x3 file : the
attribute did not exist on occurrences in IFC2x3.
Pattern : The door-in-wall void and fill triad
ALWAYS create the IfcOpeningElement first, then subtract it from the wall with
IfcRelVoidsElement (RelatingBuildingElement = wall,
RelatedOpeningElement = opening).
ALWAYS fill the opening with IfcRelFillsElement (RelatingOpeningElement = opening,
RelatedBuildingElement = door or window).
NEVER reverse the anchors : the wall is the Relating side of the void, the opening
is the Relating side of the fill. A reversed model is structurally parseable but
semantically wrong.
A worked STEP triad is in references/examples.md.
Pattern : Honour the version renames
ALWAYS write the abstract supertype as IfcBuildingElement for IFC2x3 and IFC4, and
IfcBuiltElement for IFC4.3.
ALWAYS model a layered wall as a plain IfcWall plus IfcMaterialLayerSetUsage :
IfcWallStandardCase is deprecated in IFC4.3 and IfcSlabStandardCase,
IfcBeamStandardCase, and the other *StandardCase / *ElementedCase entities were
DELETED in IFC4.3.
NEVER write an infrastructure entity (IfcKerb, IfcRail, IfcBearing, ...) into an
IFC2x3 or IFC4 file : they exist only from IFC4.3.
See ifc-core-entity-hierarchy for the full type / occurrence model.
Reference Links
references/methods.md : the verified EXPRESS definitions of every element entity,
the complete PredefinedType enum value lists, IfcOpeningElement, the three
relationship entities, and the per-version difference detail.references/examples.md : worked STEP scenarios : a wall with a type, spatial
containment, the full door-in-wall void/fill triad, a window, a beam with a
PredefinedType, and a proxy element.references/anti-patterns.md : the failure modes this skill prevents, each with
the rule it breaks and the reason it fails.
Official sources
Related skills
ifc-core-entity-hierarchy : the IfcProduct to IfcElement to IfcBuiltElement
chain, the type / occurrence model, the IfcBuildingElement rename.ifc-core-relationships : the objectified-relationship pattern and the full
IfcRel* reference table.ifc-core-spatial-structure : IfcRelContainedInSpatialStructure versus
IfcRelReferencedInSpatialStructure and the orphan-element rule.ifc-syntax-property-sets : attaching Pset_WallCommon and other property sets.ifc-impl-authoring-file : assembling a complete element into a valid file.
