Why IFCs are so bad at BIM translation

 

 

A reader writes:

Here's something which has always bothered me. How can we say that IFC [industry foundation classes] is a BIM [building information modeling] exchange format? When I create walls in one BIM app, export them to IFC and then import the IFC into another BIM app, they aren't native wall objects and don't operate as them. If it really is an exchange format -- besides mere object shapes -- shouldn't this be possible? What am I missing?

     - D.E.

 IFC is a kludge.

It was first designed by Autodesk to solve the problem they created with AutoCAD Release 13's new DWG format that allowed it to store any kind of data -- and the new ARX programming interface that allowed AutoCAD to create any kind of object. These actions in 1995 future-proofed the format, but also lead to unintended consequences.

The problem became how to display that "any kind of content" which AutoCAD did not understand, such as custom objects created by AutoCAD Architectural and Mechanical.

Autodesk came up with three solutions:

• Proxy objects that display custom entities in a dumb format that could be viewed but not edited
• Plug-ins that mimicked the functions of ADT and MDT, so that the proxy object could be edited
• IFC format to transfer the data stored in the custom objects between programs

The plug-ins became unwieldy as the versions multiplied. Autodesk spun off the IFC format to a committee to deal with. The proxy objects are still supported.

For the first many years, the IFC committee worked on exchanging data between programs, such as from ADT to a thermal analysis software, and then into another CAD program. But just data.

When Revit popularized the concept of BIM (2000 and following), IFC was seen as ideal as exporting the building data (information) it stored in its models.

With successive updates to IFC by buildingSmart, the format began to handle graphical data, such as walls and windows. IFC is up to version 4 now. IFC slid into becoming the BIM translation format by default.

So, you are right to be frustrated about the quality of translation, as it was never meant to do that. The problems you encounter are due to every BIM vendor defining their parameterized objects differently.

The good news is that the Open Design Alliance has begun attacking the problem of IFCs, writing an API [application programming interface] for that, along with the API for Revit files. The other good news is that other BIM vendors want this to happen, as well.

The reader responds:

Thanks for the info. I've been seeing US Government contracts written with Revit file format requirements. They state you can use any software you wish, but I don't know of any (yet) which can fulfill this requirement. Also engineers really love having all of the "I" in BIM available to them, so we're kind of stuck when you want to work with these firms.

https://www.opendesign.com/blog/2018/october/oda-begins-work-ifc-solution

 

 

Comments

[Rob Roef]

Dear Ralph,

First, I’d like to thank you for this article. It puts the finger on the sore spot and, once again, clearly indicates that the market is insufficiently informed about the level of cooperation through open BIM standards.

To begin, IFC is not an exchange format, but rather a collaboration format. IFC is not intended for round-tripping, but rather to inform partners in the (design and construction) process in the way that it should be done -- by everyone taking their own responsibility and exchanging meaningful information.

I believe that bypassing the shortcomings in IFC is not solved by developing direct links in an API. After all, there is so much more specialized software on the market than we can imagine. Focusing on collaboration and less on compatibility will increase the acceptance of IFC (and other open standards).

Best regards,

Rob Roef
OPEN BIM Program Manager
GRAPHISOFT SE