In the previous articles, I focused mainly on the advantages of the IFC scheme and its application. Today I present a short holiday article about what I don’t quite like about IFC.
There is no doubt that IFC is the best scheme for exchanging information about construction and facility management projects.
There is no shortage of criticism of IFC in the construction industry. Unfortunately, in most cases, they are unfair and mostly result from a bad configuration, inadequate software implementation, poor model management (if there is chaos in our model, it’s hard to expect that IFC is readable and useful).
Nevertheless, several disadvantages are worth mentioning.
1. For the beginning – IFC Specification Database
Although the official latest version is IFC4.1, the most popular and widely used version is still IFC2x3, the version I based on in previous articles.
This documentation contains all the information about the scheme, however, the first impressions of navigating the content page resembles surfing the Internet 20 years ago or checking the program in the Teletext.
Writing previous articles, I’m gradually getting used to the online documentation of the IFC scheme. It turns out to be functional and logical. The more experienced user you are, the better you navigate it, but… couldn’t it be more attractive from a visual point of view? Often the first impression stops new users from further exploring this documentation.
Looking through the diagrams gives you another headache. The diagrams are logical and professional, but for someone interested in learning more…
Diagrams, resources, domains, topologies…
The internet offers many tutorials regarding the use of IFC documentation. However, I think it would be so much better if you don’t need documentation explaining documentation.
2. IFC versions
Provided that the version numbering is as clear and explained as possible by buildingSmart, the names of subsequent versions are completely unclear.
As I mentioned above, the most popular version used is IFC2x3. Why 2×3 and not 2.3?
It all started quite normally. The first version (no. 1.0.0.0) was called IFC 1.0 – very simple and logical. Why is the next version (no. 1.1.0.0) called IFC1.5? Then things only get more interesting. The next version with number 2.0.0.0 (according to the convention given by buildingSmart) is called IFC 2.0 – phew. It’s logical. Yet the next one (no. 2.1.0.0) is called IFC2x … – Where did this x come from and what happened to the good period?
The final version of IFC2x3 I mentioned is actually IFC2x3 TC1…
Then we skip no. 3… there is no IFC3 but immediately IFC4. What happened to number three?
In case of IFC4 there is no X anymore, or transition to IFC 4.1, now we have IFC4add1 (I can understand that the extensions “add” and “TC” are taken from the numbering description – add from “addemdums”, TC from “corrigendums”) – however, this creates some confusion among users.
I think that a standard numbering as in all applications would be much more understandable and sensible: IFC 1.0, IFC 1.2.1 IFC2.0, and so on…
3. Shortcuts, shortcuts, shortcuts…
openBIM is based on open standards such as IFC. These standards include IDM, MVD, IFD, bsDD… You can get lost in the multitude of all these shortcuts. In this respect, however, BIM requires it as you can find out in the article 22 TERMS IN BIM YOU SHOULD KNOW.
4. IFC here, IFC there... IFC everywhere.
Why does every class require an Ifc prefix? IfcDoor, IfcBeam, IfcWall… Naming an object simply Door, or Wall will be much more precise and easier. Hence instead of IFCDOOR – DOOR, IFCWALL – WALL, IFCBEAM – BEAM. None of these elements have lost any of their importance, and the description is just more readable.
Summary
I consider the IFC as the best available scheme for the exchange of construction information and facility management. Each major construction project involves many stakeholders using different tools. Normally, each project participant can use the tools of their choice as long as they can exchange data with others. Therefore, BIM needs to use an open format such as IFC, to enable everyone, regardless of the native software used, to exchange information in a clear, readable, and accessible form.
Therefore, when the IFC scheme, its operation, and documentation are clear and transparent, it’s better for all those who use it in their daily work, exchange project information, or use the IFC model for facility management.
Omg yes, I’m a graduation game engineer who is doing research on BIM models and IFC models and I don’t understand anything from this world
Thanks for this article Majcher,
i would add the following question out of my daily experience:
i would ask the question why there is the approach used to create an enity for each object? An complete list of all objects isn‘t possible in my point of view, due to that new apparatuses in future or special apparatuses used in specialized buildings likely in wafer fabrics have to be appended in an new realese of the ifc scheme. In my daily experience the assigned ifc entities are ( in more technical areas such as hvac centrals) mostly wrong assigned in the way that there to globally — such as an flushing valve which holds the entity „Ifcvalve“ instead of the IfcValveFlushing. This may comes from software which canˋt Derivate or translate the native formats into the correct ifc entities. As an example the translation from Autodesk revit categories to ifc entities can be seen as example, similar effects may be seen in other softwares like those from the nemetcheck company.
An (contractor, owner) specific typification is more accurated and consistent and easy exmpandable. Due to that the types follows an scheme not an catalogue there is no list needed (tries and fails) which specifies all entries.
the approach of classification of all ifc enties in the hvac sector.
https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/ifchvacdomain/content.html