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. 188.8.131.52) was called IFC 1.0 – very simple and logical. Why is the next version (no. 184.108.40.206) called IFC1.5? Then things only get more interesting. The next version with number 220.127.116.11 (according to the convention given by buildingSmart) is called IFC 2.0 – phew. It’s logical. Yet the next one (no. 18.104.22.168) 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.
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.