In most cases, when the geometry in IFC is defined parametrically (BREP), it becomes impossible to visualize or retrieve geometric properties, such as volume or area of project entities, with only an IFC file, because to work with and visualize the geometry in this case, a geometry kernel (Fig. 6.1-5) is required, which is initially missing.
Geometry kernel is a software component that provides basic algorithms for creating, editing and analyzing geometric objects in CAD (CAD), BIM and other engineering applications. It is responsible for building 2D and 3D -geometry, as well as for operations on it, such as: Boolean operations, smoothing, intersections, transformations and visualization.
Every CAD program and any program working with parametric or IFC formats has its own or purchased geometric kernel. And if with primitive elements in IFC -BREP format there can be no problems and in programs with different geometrical kernels these elements can be displayed similarly, but besides problems with different engines of geometrical kernels, there are enough elements which have their own peculiarities for correct displaying. This problem is discussed in detail in the international study ” A reference study of IFC software support” published 2019 (T. K. K. A. O. F. B. C. E. L. H. H. H. E. L. P. N. S. H. T. J. v. L. H. H. G. D. H. T. K. C. L. A. W. J. S. Francesca Noardo, “Reference study of IFC software support: the GeoBIM benchmark 2019 – Part I,” 8 Jan. 2021).
The same standardized datasets produce inconsistent results, with few common patterns found, and serious problems are found in supporting the standard [IFC], probably due to the very high complexity of the standard data model. The standards themselves are partly to blame here, as they often leave some details undefined, with high degrees of freedom and various possible interpretations. They allow high complexity in the organization and storage of objects, which is not conducive to effective universal understanding, unique implementations, and consistent data modeling (T. K. K. A. O. F. B. C. E. L. H. H. H. E. L. P. N. S. H. T. J. v. L. H. H. G. D. H. T. K. C. L. A. W. J. S. Francesca Noardo, “Reference study of IFC software support: the GeoBIM benchmark 2019 – Part I,” 8 Jan. 2021).
– Reference study of IFC software support, 2021
Correct understanding of “certain provisions” is available to paid members of special organizations that are engaged in IFC development. As a consequence, whoever wants to get access to important knowledge about certain features of IFC will try to cooperate with large CAD- vendors, or to reach a qualitative consideration of the features by his own research
You stumble upon a question about importing and exporting data via the IFC format and ask your fellow vendors: “Why is it so in the IFC file the information about parametric transfer of premises? The open specification does not say anything about it”. Answer from “more knowledgeable” European vendors: “Yes, it is not said, but it is allowed“.
– From the interview of CAD developer, 2021 (И. Rogachev, “Let’s Talk BIM: Maxim Nechiporenko | Renga | IFC | Domestic BIM,” April 13, 2021)
IFC describes the geometry through parametric primitives, but does not contain a built-in kernel – its role is performed by the CAD program, which compiles the geometry through the geometry kernel. The geometry kernel performs mathematical calculations and defines intersections, and IFC only provides data for its interpretation. If the IFC contains incorrect faces, different programs with different geometry kernels can either ignore them or produce errors, depending on the kernel.
As a result, to work with the IFC format it is necessary to answer the main question, to which it is difficult to find an unambiguous answer – what tool, with what geometric kernel should be used to get the quality of data that the project originally had in the CAD program from which the IFC was obtained?
Data quality issues and the complexity of the IFC format do not allow direct use of project data for process automation, analysis and data processing, which often leads developers to the inevitable need to use closed CAD -solutions with “quality” access to data (А. Boiko, “Lobbykriege um Daten im Bauwesen | Techno-Feudalismus und die Geschichte von BIMs,” 2024), which was written about by the vendor himself, who registered IFC in 1994 (ADSK, “Integrated Design-Through-Manufacturing: Benefits and Rationale,”).
All peculiarities of display and generation of IFC parameters in geometry kernel can be realized only by large teams of developers who have experience in working with geometry kernels. Therefore, the current practice of IFC format peculiarities and complexity is beneficial primarily to CAD- vendors and has much in common with the strategy of large software vendors “adopt, extend, destroy”, when the growing complexity of the standard actually creates barriers for small market players (А. Boiko, “The post-BIM world. Transition to data and processes and whether the construction industry needs semantics, formats and interoperability,” December 20, 2024).
The strategy of large vendors in such a strategy may be to adapt open standards, add proprietary extensions and features to create user dependency on their products to then drive out competitors.
The IFC format, intended to be a universal bridge between different CAD- (BIM-) systems, in reality serves as an indicator of compatibility problems between the geometric cores of different CAD platforms, similar to the STEP format from which it originally emerged.
As a result, today a full and high-quality implementation of the IFC ontology is within the reach of large CAD vendors, who can invest significant resources to support all entities and their mapping to their own internal geometry core, which does not exist for IFC as a standard. Large vendors also have the ability to negotiate among themselves technical details of features that may not be available to even the most active participant in IFC format development organizations.
For small independent teams and open-source projects, striving to support the development of interoperable formats, the lack of an in-house geometry kernel becomes a serious problem. Without it, it is virtually impossible to take into account all the various subtleties and nuances associated with cross-platform data exchange.
With the development of the IFC parametric format and the open BIM concept, discussions have intensified in the construction industry about the role of ontology and semantics in data and process management.
