Skip to content

Representations

Introduction

An IfcProduct may have a representation. The IfcRepresentationItem conveys the geometry data and can take a variety of forms that each calls for specific technical handling. Indeed we have IfcBoundingBox, IfcExtrudedAreaSolid, IfcGeometricCurveSet, IfcFaceBasedSurfaceModel, ... to name a few.

Aqs of IFC4, Tessellation is also available. This introduces a simple Mesh geometry where every shape is approximated by a set of non overlaping triangles.

For administrative processes, It will be convenient - or necessary - to reduce the variety of representations used in the IFC that is submitted. Alternatively, applying IfcOpenshell tessellation might help.

It is worth noting that in IFC5, Mesh geometry will be at the core (base/default geometry)

An overview of the IFC geometry is provided in Building Information Modeling.

flowchart TB
    IfcObject --o IfcProduct
    IfcProduct --o IfcElement
    IfcProduct --o IfcSpatialElement
    subgraph spatialelement
        IfcSpatialElement --o IfcSpatialZone
        IfcSpatialElement --o IfcSpatialStructureElement
        IfcSpatialStructureElement --o spElem["IfcSite,<br/>IfcBuilding,<br/>IfcBuildingStorey,<br/>IfcSpace"]
    end 
    subgraph element
        IfcElement --o IfcBuildingElement
        IfcElement --o IfcDistributionElement
        IfcBuildingElement --o elem["IfcWall,<br/>IfcSlab,<br/>IfcColumn,<br/>IfcBeam,<br/>IfcDoor,<br/>IfcWindow,<br/>..."] 
    end 
    IfcProduct --o IfcProductRepresentation
    subgraph representation
        IfcProductRepresentation --o IfcProductDefinitionShape 
        IfcProductDefinitionShape --o IfcShapeRepresentation
        IfcShapeRepresentation --o IfcRepresentationItem
        IfcRepresentationItem --o IfcGeometricRepresentationItem
        IfcGeometricRepresentationItem --o item["IfcBoundingBox,<br/>IfcExtrudedAreaSolid,<br/>IfcGeometricCurveSet,<br/>IfcFaceBasedSurfaceModel,<br/>IfcMappedItem,<br/>...<br/>,<br/>Tessellation<br/>"] 
    end

Representation Geometric Context

The IfcGeometricRepresentationContext defines the context that applies to several shape representations of products within a project.

It defines the type of the context in which the shape representation is defined, and the numeric precision applicable to the geometric representation items defined in this context.

In addition it can be used to offset the project coordinate system from a global point of origin, using the WorldCoordinateSystem attribute. The main representation context may also provide the true north direction.

There is also an IfcGeometricRepresentationSubContext which is used to define semantically distinguished representation types for different information content, dependent on the representation view and the target scale.

It can be used to control the level of detail of the shape representation that is most applicable to this geometric representation context.

In addition the sub context is used to control the later appearance of the IfcShapeRepresentation within a plot view.

The IfcGeometricRepresentationSubContext has a TargetView attribute of type IfcGeometricProjectionEnum with the values:

  • ELEVATION_VIEW
  • GRAPH_VIEW
  • MODEL_VIEW (should be provided)
  • PLAN_VIEW
  • REFLECTED_PLAN_VIEW
  • SECTION_VIEW
  • SKETCH_VIEW
  • USERDEFINED
  • NOTDEFINED

More details are available at https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcGeometricProjectionEnum.htm

Example of using geometric representation contexts

Processing

In our workflow, the geometry is created in the AEC Tool and preserved along the tranformation so that it can be rendered in a standard Ifc Viewer. Up to a point, this appears as a non issue.

Ingress flow:

flowchart LR
    AECTool --> IFC
    AecGeo["Create Geometry"] --> AECTool 
    IFC --> Python 
    Python --> IfcJSON
    IfcJSON --> Python
    Python --> DB 
    style AecGeo fill:#148F77

Egress flow:

flowchart LR
    DB  --> Python
    Python --> IfcJSON
    IfcJSON --> Python
    Python --> IFC
    IFC --> IfcViewer
    ViewGeo["Visualize Geometry"]
    IfcViewer --> ViewGeo
    style ViewGeo fill:#148F77

That's fine, until we need to handle specific geometric aspects. Which is a requirement with most administrative processes. When we create an IfcSpatialZone, we will eventually need a represenation derived from IfcRelReferencedInSpatialStructure elements.

There we have several possibilities to explore:

  • Use IfcOpenShell Geometry in Python (Python wrapper above CGAL and OpenCascade); possibly also use the Voxelization capabilities
  • Handle the geometry during the import & transform
  • Use PostGIS Geometry in the DB; PostGIS uses GEOS which can also be accessed via Shapely
  • Use an external Tool when an Agent must perform adjustments

Transformation flow:

Execute a tessellation during the ingress flow

flowchart LR
    AECTool --> IFC
    AecGeo["Create Geometry"] --> AECTool 
    IFC --> Python 
    Python --> Tessellation
    Tessellation --> Python
    Python --> IfcJSON
    IfcJSON --> Python
    Python --> DB 
    style AecGeo fill:#148F77
    style Tessellation fill:#a14b45

Execute tessellation or other transformation on an as-needed basis

flowchart TB
    DbGeom["PostGIS Geometry"]
    DbGeom --> DB
    DB  -- Read IfcJSON --> Python
    Python -- Store IfcJSON --> DB
    IfcGeom["IfcOpenShell Geometry<br/>incl. tessellate"] 
    IfcGeom --> Python 
    Python -- Export --> IFC
    IFC -- Import in sub-bundle --> Python
    IFC <-- Update --> ExternalApp["External Application<br/>e.g. Blender with Bonsai"]
    IFC --> IfcViewer
    ViewGeo["Visualize Geometry"]
    IfcViewer --> ViewGeo
    style ViewGeo fill:#148F77
    style IfcGeom fill:#a14b45
    style DbGeom fill:#a14b45
    style ExternalApp fill:#a14b45

Impact on the data model

With PostGIS, we only need to add a column of type Geometry.

In the paper An IFC-based database schema for mapping BIM data into a 3D spatially enabled land administration database the authors have elected a model which maps key IFC entities and add a Geometry column to most of them.

In our Physical Data Model, we have elected to keep the number of tables quite small. We have one representation table to which we have added the Geometry column.

Further to that, the intent is to use the Geometry Column only for a limited number of object types, starting with IfcSpace and IfcSpatialZone.

In the IfcModels used as examples, we have observed a large variety of options used for representing an IfcSpace geometry. This variety will impact the mapping of the representation in the IfcJSON to the format used by PostGIS Geometry.

What we have in the data model is

erDiagram
object {
        int     bundleId "part of PK"
        uuid    objectId "part of PK"
        string  type
        string  name
        array   representationIds "array of str(uuid)"   
        json    elementJson "contains the object placement data"

    }
    object ||--o{ representation : has

    representation {
        int         bundleId "part of PK"
        uuid        representationId "part of PK"
        string      type
        json        elementJson "contains the shape representation data" 
        geometry    geom "geometry column for PostGIS"
    }

Technical References

Books

Borrmann, A., Berkhahn, V. (2018). Principles of Geometric Modeling. In: Borrmann, A., König, M., Koch, C., Beetz, J. (eds) Building Information Modeling. Springer, Cham.