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 28: | Line 28: | ||
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. |