Skip to content

IFC Entities

Introduction

IFC is a standardized, digital description of the built asset industry. It is an open, international standard (ISO 16739-1:2024) and promotes vendor-neutral, or agnostic, and usable capabilities across a wide range of hardware devices, software platforms, and interfaces for many different use cases.

The current versions of IFC are IFC2X3, IFC4, IFC4X3 ADD2. There is also IFC5 which is under developement. From a technical perspective IFC5 with not rely anymore on the STEP file format and will adopt a JSON format and borrow concepts from USD (Universal Scene Description). Some functional / data changes are also in the make with some data content moving for relationships to objecs.

So we will follow on with IFC5, but up to now what is presented here is valid for IFC<5.

Entities (up to IFC4X3 ADD2, or IFC<5)

There are several hundreds of entities in IFC and many detailed diagrams are available. The diagram here below presents a limited but helpful overview of significant IFC entities and relationships. The diagram is extracted from the paper Indoor navigation supported by the Industry Foundation Classes (IFC): A survey.

IFC Entities and Relationships diagram

It exemplifies the hiearchical relationship IfcRelAggregates of:

  • IfcProject
  • IfcSite (one or many)
  • IfcBuilding (one or many). An IfcBuilding can be an aggregate of several 'building (parts)' with a type
    • COMPLEX = building complex
    • ELEMENT = building
    • PARTIAL = building section
  • IfcBuildingStorey (one or many level(s)). An IFCBuildingStorey can also be an aggregate of several storey part(s):
    • COMPLEX: building storey complex
    • ELEMENT: building storey
    • PARTIAL: partial building storey
  • IfcSpace (one or many room(s) or parking(s) and combinations or parts thereof). Accordingly, the IfcSpace can also be a aggregate of several space part(s):
    • COMPLEX = space group
    • ELEMENT = space
    • PARTIAL = partial space

And also the hierarchical relationship IfcRelContainedInSpatialStructure, with elements typically contained in an IfcBuildingStorey such as:

  • IfcWall
  • IfcSlab
  • IfcColumn
  • IfcBeam
  • IfcWindow
  • IfcDoor

Or elements typically contained in an IfcSpace such as:

  • IfcFurnishingElement
  • IfcTransportElement
  • IfcDistributionElement
  • IfcCovering

It also exemplifies the IfcRelDefinedByProperties that links a propertySet with one or more element to which the propertySet applies.

An last but not least it examplifies the IfcRelSpaceBoundary which relates the IfcSpace with its boundary (e.g., IfcWall).

Not shown on that diagram, but quite important is the IfcRelReferencedInSpatialStructure which is used to assign elements in addition to those levels of the project spatial structure, in which they are referenced, but not primarily contained. This is illustated in the diagram below with a curtain wall contained in the spatial structure of the ground floor but also referenced in the spatial structures of the other floors.

IfcRelReferencedInSpatialStructure

Further information to be found in the official IFC documentation

There are significantly more entities and relationship than those illustrated here. A reference documentation is available at . From it, it is apparent that IFC covers most (not to say all) elements relevant to the technical documentation of 'Spatial Units'.

From the documentation, it is also apparent that IFC is NOT just for Buildings but encompases Roads, Marine Facilities, Railway, ...

See e.g., hereunder:

IFC and CityGML

Hereunder an informative diagram extracted from a very interesting paper on Automatic conversion of IFC datasets to geometrically and semantically correct CityGML LOD3 buildings (../data-model/references.md#ifc-to-citygml)

UML diagram for the IFC classes most relevant for CityGML LOD3 models

A Condensed Model for IFC or other Models of Technical Data for 'Spatial Units'

erDiagram
    object
    representation
    relationship
    relatingEntity
    relatedEntity
    propertySet
    space ["space >: object"]
    objectType
    relationshipType
    objectType ||--o{ object : typeOf
    relationshipType ||--o{ relationship : typeOf 
    object ||--o{ representation : has
    object ||..o| space : ""
    relationship ||--|| relatingEntity : characterize
    relationship ||--|{ relatedEntity : apply_to
    relatingEntity ||--|| object : is
    relatingEntity ||--|| propertySet  : is
    relatingEntity ||--|| space : is
    relatedEntity ||--|| object : is

The proposed condensed model preserves all the information contained in the IFC file/model and organizes the storage in 4 main 'groups':

  • Objects
  • Representations (aka geometries)
  • Property Sets
  • Relationships

An object is everything that does not fall into one of the other three 'groups'.

A representation may exist for an object in the IfcProduct category such as Wall, Slab, Column, Beam, Window, Door, ... and contain the information necessary to provide a 3D rendering of the object. In the object group of the proposed condensed model, not all items are IfcProducts and have a representation. E.g., a an IfcProject does not have and does not need a representation.

An IfcRelationship has one Relating Entity and one or more Related Entity(ies). For instance the decomposition of a Building in Storeys is documented by an instance of a relationship of type IfcRelAggregates with the IfcBuilding as the Relating Entity and the IfcBuildingStoreys as the Related Entities. There are tens of types of relationships that follow the same pattern of 'relating' and 'related' element. This is both flexible and general.