SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsifc-syntax-building-elements

ifc-syntax-building-elements

Testing & quality

View repository

Updated 10-15 22:18

About this skill

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.