Skip to content

About d4SU

Climate change and energy challenges require drastic improvements in all aspects relating to the life cycle of Buildings and Infrastructures. To cope with the challenges, and meet the climate objectives for 2050, numerous initiatives have promoted the evaluation of buildings and infrastructures along indicators such as the Life Cycle Assessment (LCA), the Energy Performance Certificate of Buildings (EPC), the Reuse Potential Indicator (RPI) and the consistent aggregation of data in the Building LogBook or Passport, ... with a proliferation of distinct techniques and tools that each collect data which is already available in the AEC data and can be provided in the standard exchange format of the industry, namely Industry Foundation Classes (IFC).

As I worked on some of these subjects (Building LogBook, Urban Permit, EPC, ...), the gap between the AEC industry and administrative processes was striking. Despite the existence of an extensive litterature on the use of IFC for the support of the administrative processes, adoption of IFC as a priviledge source of technical data for Buildings and Infrastructure remained scarce. One of the possible cause could that IFC is available as a file that must be processed by specific programs and is not directly legible (this will change with IFC5).

There has been several attempts to store the IFC in a database while preserving the complex structure of the data. This is all fine but does not bridge the gap between the AEC and the administrative monitoring processes. There could therefore be a place for a platform that can process IFC and make the information available in a standard database (PostgreSQL) using a simple physical data model that can be accessed with SQL. This would potentially create a basis for a Single Source of Truth for technical data for Buildings and Infrastructures, with a seamless integration with other aspects as well.

This is precisely what d4SU is aiming at. IFC2X3 and IFC4 files are processed, transformed in the ifcJSON format and stored in a relatively simple physical model. From there an IFC4 file can always be generated where needed to support rich 3D Visualization.

The platform is based on scalable tools that could support a production deployment, but the application remains currently at an exploratory level.

Although there remains significant work to be done, there are already positive results:

  • the platform can leverage available python libraries such as IfcOpenShell, that underpins numerous capabilities, starting with the transformation of IFC into ifcJSON
  • the ifcJSON format is very close to IFC and easy to use with PostgreSQL JSON handling
  • while SQL can be taxed as 'verbose', it is nevertherless very efficient, combining simplicity and performance.

D4SU started in 2024, when IFC5 was taking shape, but was not yet a standard with appropriate implementations and tooling.

So, there will remain the challenge of integrating IFC5, from now on and as it reaches maturity.