If you’re here, you’ve probably already read the first part of the article about IFC and what an ideal file should contain.
You can find it here.
I invite you to continue the discussion on this topic.
I’m happy to share further thoughts on this issue
If you’re interested in the topic of IFC 4.3, don’t forget to check out other articles dedicated to this subject on our blog.
- All you need to know about IFC 4.3 for infrastructure
- IFC 4.3 in road projects – case study
- Relations I used to create IFC 4.3 for infrastructure
- Spatial Breakdown Structure in IFC 4.3
- IFC 4.3 on construction site
- Webinar about IFC 4.3
- Ticket to openBIM
- Export to IFC 4.3
- The Key Changes in IFC Schema Shaping OpenBIM for Infrastructure
- Transferring from Civil 3D to Quadri and Exporting to IFC 4.3
- Five Effective Tools for BIM Data Quality Assurance
- Properties in IFC
- Super IFC, part 1
ifcPropertySets
We can certainly consider one of the main reasons we use the IFC format is the ability to add a significant amount of information to individual objects. That’s why I’ve often heard arguments for using IFC 2×3 in infrastructure projects, even though that standard isn’t perfectly tailored to the discipline.
This capability mainly arises from what are known as property sets. These sets allow for detailed descriptions of data. Although each IFC class provides default property sets, they often prove inadequate and don’t meet users’ expectations.
In practice, custom properties are often preferred. I extensively discussed this issue in the article (link), but I’d like to emphasize one crucial thing. For properties to be correctly saved, it’s necessary to precisely match data types for property values. This is crucial for the effective interpretation of data from IFC files and their further processing.
For example, when we want to save an exact number, it’s best to use the “Real” data type; for measure numbers, “Integer” is preferred, and for texts, “String.” Properly matching data types facilitates later data analysis, such as when we want to sum all the numbers, etc.
We also shouldn’t forget about QuantitySets. In a nutshell, they work very similarly to Property Sets but allow for adding values, quantities, areas, etc.
ifcColourRGB
Colors in IFC serve a important role in identifying various elements of buildings or infrastructure, making it easier to recognize individual parts of the model and adding a visual dimension.
They can be used to categorize different types of data within the model, such as by labeling different types of building materials with distinct colors.
Moreover, colors can also be utilized to differentiate the level of advancement of various objects (e.g., MMI status).
In the IFC model, color is represented by the ifcColourRGB object, which defines RGB values ranging from 0 to 1. However, RGB colors are commonly presented using values from 0 to 255. Consequently, RGB colors stored in the IFC format and in BIM programs are converted accordingly.
ifcMaterial
Material is very important in every structural component, forming the basis of its existence. In BIM models, material data is an integral part and is among the most frequently included information in construction projects.
Within the IFC standard, there exists a dedicated definition known as ifcMaterial, designed for inputting material information. While standard PropertySets can also serve this purpose, ifcMaterial offers a structured approach to representing material properties in the model.
Materials can be added to elements directly as ifcMaterial, represented as a single layer (ifcMaterialLayer), or as a set of multiple layers (ifcMaterialLayerSet). For instance, a building wall might comprise various layers of differing thicknesses, each made of diverse materials.
Moreover, IfcMaterial can include presentation details such as line styles, hatch patterns, or surface colors. Additionally, materials can possess their unique properties. Thus, material information stands as a crucial element that merits inclusion in every IFC model.
ifcClassification
Imagine you’re part of a team working on an international BIM project. Your goal is to effectively manage the information model, which encompasses various types of objects. You not only want to describe these objects according to the standard classes available in the IFC schema but also customize them to local classification standards such as CoClass, UniClass, or NVDB (Norwegian Building Data Classification).
Additionally, to facilitate work in an international team, you plan to add translations for each object in the user’s native language.
In this situation, IFC classification becomes an invaluable tool for incorporating this information into our objects. While there is the possibility of manually entering data, both in terms of adapting to local standards and assigning the appropriate translations, we can utilize the classification connection mechanism with bsDD (BuildingSMART Data Dictionary). It’s worth noting that although bsDD is not necessary for using IFC classification, it provides an excellent way to comply with external classification standards.
In general, IFC Classification allows us to more efficiently manage our data by enabling the addition of external information.
Type
In the architectural, engineering, and construction (AEC) industry, it’s essential to understand the difference between “type” and “occurrence.” For example, when creating drawings of windows, in most cases, we define a window type rather than a specific instance. Each window installed on-site is treated as an “occurrence” of that type. This difference is also significant in the context of cost estimation. Instead of assessing each individual window, we estimate costs based on the window type.
Similarly, in object management, we distinguish between product types (such as a specific model from a manufacturer) and specific “instances,” possessing unique identifiers such as barcodes or serial numbers.
Therefore, a significant element in data exchange formats (IFC) is types (ifcTypeObject). Although not all programs support this mechanism, it’s worth appreciating its benefits. With proper implementation, it can contribute to reducing file size by referencing one geometry multiple times. Additionally, it allows for adding information or properties to a type once, instead of placing them on multiple objects.
Summary
Summarizing, I would like to emphasize that the above text is a subjective assessment based on my experience.
The entire text is based on my observations, and I believe that the mentioned elements constitute the absolute minimum that should be understandable to users of IFC files.
Of course, there is the possibility of expanding the list with additional points, but I believe that those listed are the foundation that should characterize a good IFC file.
Thank you for reading the article, and I encourage you to continue reading further texts on this topic.
