Skip to content

Introduction

Foreword

Because d4SU is not yet a production environment for specific identified administrative processes, the presented features are actually illustrations of capabilities rather that a set of product features.

Features specific to the platform rely on Python tools such as IfcOpenShell-python, pandas DataFrames and Series.

However, other features rely explicitely on standard SQL and other constructs that are programming language agnostic. The code is in Python but could as well be in Typescript, Rust, Java, C#, ...

Unless explicitly specified only IFC2X3, IFC4X* are supported. IFC5 is still under development and addressed in IFC5.

Key Functional Features

As stated in the Architecture there are 9 groups of features targeted by d4SU

  • Check: validate a Model against one or more requirements
  • Convert: convert a Model from one format/schema to another
  • Geometry: provide capabilities that change the type of a represention or complement the exisiting representation with a new one
  • Filter: select coherent a subset of objects, relationhips, properties and representation in a Model
  • Store : store the data of an IfcJSON into the database or add IfcSpatial Zones and their relationships
  • Export: export a subset of object, properties or combination in a csv or json format
  • Extract: extract a subset of objects, relationships, properties and representations and provide a corresponding IfcJson Model and optionally its corresponding IFC (Step file)
  • Host: host 'third-party' domain functions (related to LCA, BAMB, EPC, ...)
  • Workflow: chain of operations leveraging the other features.

Code structure

The code is availble on GitHub under /src with a specific structure

directory use
/web API layer exposed via Swagger
/service Service layer
/model Model layer; provides the models (shared with all layers) and the tables definitions
/data Data layer; takes care of all that pertains to CRUD on postgreSQL or to read/write of files through PyArrow
/ifcpatch a local copy of IfcPatch (with small adjustments)
/local_module Modules from other sources such as IfcOpenShell (with small adjustments)
/long_bg_task Base for Celery (with celery.py and task.py)
/long_bg_task/Task_modules Long running background tasks (executed by a Celery Worker). By 'long running', it is meant 'with a runtime measured in hundreds of milliseconds or in seconds'

Access

Home page

A simple page is provided at the root (/) with a base menu that gives access to:

  • the Swagger and Redoc for all APIs
  • the Proxy WebSocket Client
  • the That Open viewer
  • the IFC5 viewer from IFC5-developement

Home Page

Swagger

A Swagger is provided at /docs with the documentation of API's and a 'Try it out' capability for all API's.

Swagger

Proxy WebSocket Client

API are either served synchronously, such as all CRUD API's or asynchronously, such as import, convert, extract,... API's.

Fore those API's the request is done synchronously and the response is in two steps:

  • a synchronous response with a status and proctoken that will serve for pairing the asynchronous response with the request
  • an asynchronous response with the result of the request which will be provided via a WebSocket.

The Proxy WebSocket Client pages allows to see all asynchronous responses.

Proxy WebSocket Client

Worflows

The following schema shows key expected workflows

block-beta
    columns 5
    blockArrowId1<["</br>1. Import a model</br>from a BIM/IFC file</br>&nbsp;"]>(right)
    blockArrowId2<["2. Filter the model and</br> keep only essential</br> elements for the </br>use case at hand"]>(right)
    space:3
    space:1
    blockArrowId3<["&nbsp;</br>3. Store the ifcJSON in</br>the Database</br>&nbsp;"]>(right)
    blockArrowId4<["4. Extract the data</br>for target</br> Spatial Unit(s) /</br>Spatial Zone(s)"]>(right)
    blockArrowId5<["&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"]>(down)
    space:2
    blockArrowId12<["</br>9. Store an ifcJSON<br/> for the bespoke model</br>&nbsp;"]>(right)
    blockArrowId10<["&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"]>(right)
    blockArrowId6<["5. Enrich / Complement</br>the data for the</br>use case at hand"]>(y)
    blockArrowId7<["6. Create a semantically</br> rich 3D representation</br>that can be explored</br> with an IFC Viewer"]>(right)
    blockArrowId8<["</br>7. Import a bespoke</br>non BIM/IFC model</br>&nbsp;"]>(right)
    blockArrowId9<["</br>8. Store the model</br>into the database</br>&nbsp;"]>(up)
    space:2

This diagram provide a high level story board of what we want to show/validate

  1. Import a BIM/IFC from an external source, convert the schema if appropriate, validate the IFC against an IDS and transform the valid IFC into an ifcJSON
  2. Filter the ifcJSON while retaining only the elements that are relevant for the use case(s) at hand. In some cases, the Administrative Authority may have detailed what is expected in the BIM/IFC. This is the case for the Digital Building Permit of Dubai where detailed templates and instructions are provided for Archicad, Bentley OpenBuilding and Revit so that the exported BIM/IFC is fully adequate for the use of the Administrative Authority. However, this might be difficult to generalize and we start with the assumption that a single BIM/IFC will potentially be used across distinct Administrative Authorities and need to be filtered depending on the use case(s) at hand.
  3. Store the ifcJSON into the database (PostgreSQL)
  4. Extract the data from the database for a target 'Spatial Unit' (a Building, a Storey, an Apartment, Common part(s),...), while leveraging the power of SQL, possibly complemented by other capabilities when needed.
  5. Enrich/Complement the data for the use case at hand. This means, create new groups (such as Zones, Spatial Zones or simply Groups) an create/update PropertySets. This is where external applications will highly interact with d4SU platform.
  6. Read data from the database and rebuild an ifcJSON with the relevant data and convert it to an IFC file so that standard IFC viewer can be used to navigate through the data (not just a 3D shape)
  7. Import a bespoke non BIM/IFC model (typically from a legacy system). The import will transform the legacy model into 'objects', 'representations', 'relationships' and 'propertySets'. We assume that it cannot be expected that every input will be BIM/IFC from day one or that the past can be ignored. Therefore, other models must be accounted for.
  8. Store the bespoke model into the database
  9. Create and Store an ifcJSON for the bespoke model. From there it will behave as a standard BIM model, although not suited for use by the AEC insdustry to 'construct' the represented building or part thereof. We will give an example of how simple it is to build an IFC from a model using IfcOpenShell. But practically, creating a meaningful IFC for a bespoke model will always require a development to accomodate the specifics of the model.

From API to Database

flowchart LR
    Ifc
    Custom["Custom Model"]
    ifcJSON
    Other["CityJSON, LDB, glTF,..."]
    DB[("Database")]
    API <--> IfcOpenShell
    API <--> SQL
    API <--> ifcJSON
    API <--> Graph
    Graph <--> DB
    Custom -- convert --> Ifc
    Custom -- is stored --> DB
    SQL <--> DB
    IfcOpenShell --> Ifc
    Ifc <-- convert --> ifcJSON
    Ifc --> Other
    Other --> Ifc
    ifcJSON <-- store | retrieve --> DB
    style API fill:#148F77
    style DB fill:#148F77

Technically speaking, FastAPI and Celery provide the glue to bring together the capabilities provided by the BIM/IFC ecosystem in order to cover the needs of d4SU.

On the left we have the API and on the right we have the Database. Between them, different representations are activated to leverage the capabilities of IfcOpenShell (including IfcPatch, IfcConvert), IfcJSON (two-way conversion between IFC(STEP Model & file) and IfcJSON (a JSON Model & file)), SQL and possibly CYPHER. Also, different conversion tools can be enacted to produce other representations: e.g.:

  • COLLADA or glTF for Google Earth, Cesium, ... (IfcConvert)
  • CityJSON for GIS applications (IfcConvert, IfcCityJson)
  • LBD (Linked Building Data) with IFCtoLBD

Complex sequences of transformations can be executed, with the help of IfcPatch to:

  • Extract elements of the model, for instance all standards elements [Wall, Slabs, Beams, Columns, Windows, Doors, Spaces, Stairs]
  • Split in Storeys / Levels
  • Migrate a version, e.g from Ifc 2x3 to Ifc 4
  • Purge Data
  • Tesselate elements (simplify geometry rendering)

Link to other Capabilities (examples)

As more functionalities are made available, they could be leveraged by the platform. E.g., IfcLCA for Life Cycle Analysis or bim2sim for Heating, Ventilation Air-conditioning (HVAC), Building Performance Simulation (BPS) or Computational Fluid Dynamics (CFD)

Ifc Files

Ifc files used for tests and explorations come from reference sources such as:

The following files have been extensively used:

Duplex_A_20110907_optimized.ifc

The file Duplex_A_20110907_optimized.ifc provides a model with many features. The model contains as usual a project with a building and several storeys. Also, as usual, there are walls, slabs, beams, doors, windows, stairs, spaces and furnishing elements. Spaces are delimited by 'IfcRelSpaceBoundary' '1stLevel' relationships that provide space delimiters such as 'walls', 'slabs', 'doors', 'windows'. Also, there are many 'IfcRelConnectsElements' that documents the connections between walls and have some side effects that must be handled.

View of Duplex_A_20110907_optimized.ifc with OpenIFCViewer

Duplex_A_20110907_optimized.ifc with OpenIFCViewer

View of Duplex_A_20110907_optimized.ifc with That Open

Duplex_A_20110907_optimized.ifc with ThatOpen

View of Duplex_A_20110907_optimized.ifc with BIMCollab zoom

Duplex_A_20110907_optimized.ifc with ThatOpen

View of Duplex_A_20110907_optimized.ifc with Solibri Anywhere

Duplex_A_20110907_optimized.ifc with Solibri Anywhere

IFC Schependomlaan.ifc

IFC Schependomlaan.ifc is a typically rich (hence complex) IFC file. Among its many features it contains a SpaceBoundary2ndLevelView. Spaces are delimited by 'IfcRelSpaceBoundary' '2ndLevel' relationships that are suited for energy analysis. There are however some anomalies in the file. There are 10 apartments in the building, some have doors (an not windows) in the space boundary and some have windows (and not doors) in the space boundary.

Duplex_A_20110907_optimized.ifc with ThatOpen

Residential Building from Nordic Sustainable Construction BIM4LCA Files

BIM4LCA - Residential Building is a recent set of IFC files with different variants published 09/2024. According to the publishing site, "In all design phases of the project, the disciplines carried out the design work solely by modelling. As a result, several model versions were produced. All the models are available to download... They are free for anyone to use under the Creative Commons license (CC BY-SA 4.0)". Spaces are delimited by 'IfcRelSpaceBoundary' '2ndLevel' relationships that are - expectedly - suited for energy analysis.

Residential Building Architecture - Solibri Anywhere

The following is provided as reference of how Solibri renders the ifc file before any transformation we cab apply later on.

ARK_NordicLCA_Housing_Concrete_BuildingPermit_Revit.ifc with Solibri

ARK_NordicLCA_Housing_Concrete_BuildingPermit_Revit.ifc with Solibri

Residential Building Architecture - BimColab

ARK_NordicLCA_Housing_Concrete_BuildingPermit_Revit.ifc with BIMcollab

Residential Building HVAC

HVAC_NordicLCA_Housing_Concrete_BuildingPermit.ifc with BIMcollab

Residential Building Electricity

ELE_NordicLCA_Housing_Concrete_BuildingPermit.ifc with BIMcollab

Office Building from Nordic Sustainable Construction BIM4LCA Files

Office Building Architecture

ARK_NordicLCA_Office_Concrete_BuildingPermit_Revit.ifc with BIMcollab

Office Building HVAC

HVAC_NordicLCA_Office_Concrete_BuildingPermit.ifc with BIMcollab

Office Building Electricity

ELE_NordicLCA_Office_Concrete_BuildingPermit.ifc with BIMcollab

AC20-FZK-Haus

This is a reference / demo model for IFC which we use for processing Ifc Objects with a type and an IfcRelDefinesByType (such as IfcWall with an IfcWallType, IfcSlab with and IfcSlabType, IfcWindow with an IfcWindowType, ...) as outlined in Object Types. These typed object are less extensively present in the other IFC files produced by a conversion (from Architcad, Revit or other).

AC20-FZK-Haus.ifc with BIMcollab