Difference between revisions of "IFC classes"
(Created page with "All data in IFC belongs to an IFC class. IFC classes can be divided into two categories: ''rooted'' and ''non-rooted'' classes. ''Rooted'' classes inherit attributes from an I...")
Revision as of 02:40, 20 March 2020
All data in IFC belongs to an IFC class. IFC classes can be divided into two categories: rooted and non-rooted classes. Rooted classes inherit attributes from an IFC class called
IfcRoot, whereas non-rooted classes do not. This
IfcRoot class is special because it provides the following four attributes:
||Yes||A unique identifier of the object, generated by a computer. This is usually created automatically by the BIM authoring tool.|
||This special attribute can store names, dates, organisations, software vendor, and contact details of people who are responsible for this object. This is usually created automatically by the BIM authoring tool.|
||This can contain a short text that names the object.|
||A sentence or so to describe the object.|
All rooted classes are semantically significant to end-users and created specifically for a project or library. Examples include
IfcWall. They are usually annotated in documentation, or named specifically in schedules. These objects are generally useful to end-users, and for this reason can be tracked with a
GlobalId and given a
In contrast, non-rooted classes do not have the ability to assign a
Name, or otherwise, and are used to store non-project-specific data like XYZ coordinates, RGB colour values, vectors, and so on. One example is
IfcCartesianPoint. They are needed from a technical perspective, and are usually automatically generated by the BIM authoring tool, and can usually be safely ignored by end-users. It is important, however, to know that they exist as power users may encounter them when trying to optimise OpenBIM data.