Editing IFC - Industry Foundation Classes/IFC classes
From Wiki.OSArch
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
− | + | 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 <code>IfcRoot</code>, whereas ''non-rooted'' classes do not. This <code>IfcRoot</code> class is special because it provides the following four attributes: | |
− | |||
− | |||
− | All | ||
{| class="wikitable" | {| class="wikitable" | ||
Line 28: | Line 25: | ||
All ''rooted'' classes are semantically significant to end-users and created specifically for a project or library. Examples include <code>IfcProject</code>, <code>IfcBuilding</code>, and <code>IfcWall</code>. 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 <code>GlobalId</code> and given a <code>Name</code>. | All ''rooted'' classes are semantically significant to end-users and created specifically for a project or library. Examples include <code>IfcProject</code>, <code>IfcBuilding</code>, and <code>IfcWall</code>. 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 <code>GlobalId</code> and given a <code>Name</code>. | ||
− | In contrast, ''non-rooted'' classes do not have the ability to assign a <code>GlobalId</code>, <code>Name</code>, or otherwise, and are used to store non-project-specific data like XYZ coordinates, RGB colour values, vectors, and so on. One example is <code>IfcCartesianPoint</code>. 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 | + | In contrast, ''non-rooted'' classes do not have the ability to assign a <code>GlobalId</code>, <code>Name</code>, or otherwise, and are used to store non-project-specific data like XYZ coordinates, RGB colour values, vectors, and so on. One example is <code>IfcCartesianPoint</code>. 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. |
Classes are often described as what they inherit from. For example, ''rooted'' classes can be described as classes that inherit from <code>IfcRoot</code>, or subclasses of <code>IfcRoot</code>. If a class inherits from another class, or is a subclass of another class, it inherits the same abilities of that class, such as the ability to have certain attributes, properties, or relationships, assigned to it. Subclasses do not actually inherit the values of the attributes themselves, but only the ability to have that attribute. | Classes are often described as what they inherit from. For example, ''rooted'' classes can be described as classes that inherit from <code>IfcRoot</code>, or subclasses of <code>IfcRoot</code>. If a class inherits from another class, or is a subclass of another class, it inherits the same abilities of that class, such as the ability to have certain attributes, properties, or relationships, assigned to it. Subclasses do not actually inherit the values of the attributes themselves, but only the ability to have that attribute. | ||
Line 52: | Line 49: | ||
== Subclasses of <code>IfcObjectDefinition</code> == | == Subclasses of <code>IfcObjectDefinition</code> == | ||
− | Although there are many IFC subclasses, there are only a handful relevant to different BIM authors, and it is useful to provide a summary of them. Underneath these handful are many subclasses which go into more detail, but knowing these broad categorisations exist help with an understanding of IFC data. The following table is not exhaustive. | + | Although there are many IFC subclasses, there are only a handful relevant to different BIM authors, and it is useful to provide a summary of them. Underneath these handful are many subclasses which go into more detail, but knowing these these broad categorisations exist help with an understanding of IFC data. The following table is not exhaustive. |
{| class="wikitable" | {| class="wikitable" | ||
Line 162: | Line 159: | ||
* [https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/TC1/HTML/inheritance_index.htm Official IFC2x3 TC1 specification list of all classes] | * [https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/TC1/HTML/inheritance_index.htm Official IFC2x3 TC1 specification list of all classes] | ||
* [[Media:Ifc-2.3.0.1.ods|IFC2x3 TC1 classes in spreadsheet format]] | * [[Media:Ifc-2.3.0.1.ods|IFC2x3 TC1 classes in spreadsheet format]] | ||
− | |||
[[Category:Industry Foundation Classes (IFC)]] | [[Category:Industry Foundation Classes (IFC)]] |