Difference between revisions of "IFC classes"

From Wiki.OSArch
Line 27: Line 27:
 
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.
 
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.
  
== Common rooted IFC classes ==
+
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.
  
Although there are many IFC classes, 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. These are all ''rooted'' elements.
+
== Subclasses of <code>IfcRoot</code> ==
 +
 
 +
''Rooted'' classes may be further broken down into three types of classes.
 +
 
 +
{| class="wikitable"
 +
! IFC Class
 +
! Description
 +
|-
 +
| <code>IfcObjectDefinition</code>
 +
| These subclasses describe "objects" or "things" that relate to the AEC industry. This includes walls, people, and tasks. You may think of them as the "nouns" in IFC.
 +
|-
 +
| <code>IfcPropertyDefinition</code>
 +
| These subclasses describe properties of "objects" and "things". They themselves are not an object, but instead a property or quantity like fire rating, energy usage, or volume.
 +
|-
 +
| <code>IfcRelationship</code>
 +
| These subclasses describe relationships between "objects" themselves, between properties, or between objects and properties. The relationships can be objects that contain other objects, connect to objects, have system inputs or outputs, or are assigned a property or quantity.
 +
|}
 +
 
 +
== 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 these broad categorisations exist help with an understanding of IFC data. The following table is not exhaustive.
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 46: Line 66:
 
| <code>IfcElementType</code>
 
| <code>IfcElementType</code>
 
| These describe construction types. A construction type may be assigned to an <code>IfcElement</code>, just like a particular <code>IfcWall</code> might have a particular construction type of 2 layers of plasterboard on a metal frame. Example subclasses of <code>IfcElementType</code> include <code>IfcWallType</code>, <code>IfcDoorType</code>, and <code>IfcWindowType</code>.
 
| These describe construction types. A construction type may be assigned to an <code>IfcElement</code>, just like a particular <code>IfcWall</code> might have a particular construction type of 2 layers of plasterboard on a metal frame. Example subclasses of <code>IfcElementType</code> include <code>IfcWallType</code>, <code>IfcDoorType</code>, and <code>IfcWindowType</code>.
|-
 
| <code>IfcPropertySet</code>, <code>IfcQuantitySet</code>
 
| These classes help store properties and calculated quantities (lengths, areas, volumes, weights, etc) of other classes, such as <code>IfcElement</code>. For instance, it may store a fire rating or length associated with an <code>IfcWall</code>. Some properties names and values are standardised within IFC, but end-users can also create their own properties. See [[IFC attributes and properties]] for more information.
 
 
|-
 
|-
 
| <code>IfcStructuralActivity</code>, <code>IfcStructuralItem</code>
 
| <code>IfcStructuralActivity</code>, <code>IfcStructuralItem</code>
Line 56: Line 73:
 
| These are useful for scheduling information, describing responsibility, tasks, resources, and timelines for construction sequencing or project planning. Example subclasses include <code>IfcTask</code>, <code>IfcConstructionMaterialResource</code>, and <code>IfcWorkSchedule</code>.
 
| These are useful for scheduling information, describing responsibility, tasks, resources, and timelines for construction sequencing or project planning. Example subclasses include <code>IfcTask</code>, <code>IfcConstructionMaterialResource</code>, and <code>IfcWorkSchedule</code>.
 
|}
 
|}
 +
 +
== Subclasses of <code>IfcPropertyDefinition</code> ==
 +
 +
The following non-exhaustive table describes common subclasses used to describe properties, which can later be assigned to objects.
 +
 +
{| class="wikitable"
 +
! IFC Class
 +
! Description
 +
|-
 +
| <code>IfcPropertySet</code>
 +
| These classes help store properties of other classes, such as <code>IfcElement</code>. For instance, it may store a fire rating associated with an <code>IfcWall</code>. Some properties names and values are standardised within IFC, but end-users can also create their own properties. See [[IFC attributes and properties]] for more information.
 +
|-
 +
| <code>IfcQuantitySet</code>
 +
| This is similar to <code>IfcPropertySet</code> but focuses on calculated quantities (lengths, areas, volumes, weights, etc). Some quantity names and values are standardised within IFC, but end-users can also create their own quantities. See [[IFC attributes and properties]] for more information.
 +
|-
 +
| <code>IfcPropertyTemplateDefinition</code>
 +
| If you don't want to actually to store the value of a proprety but instead want to describe a template of what properties exist, which are required, and what data is valid for the purposes of exchange requirements or company standards, then this template subclass allows you to do so.
 +
|-
 +
| <code>IfcPreDefinedPropertySet</code>
 +
| For some reason, some properties to do with door and window linings are given a special status in the IFC schema and have their own category. This will likely disappear in the future and merge into <code>IfcPropertySet</code>.
 +
|}
 +
 +
== Subclasses of <code>IfcRelationsip</code> ==
 +
 +
TODO
 +
 +
== A summary of non-rooted elements ==
 +
 +
TODO
  
 
== List of IFC classes ==
 
== List of IFC classes ==

Revision as of 04:00, 23 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:

Attribute Required Description
GlobalId Yes A unique identifier of the object, generated by a computer. This is usually created automatically by the BIM authoring tool.
OwnerHistory 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.
Name This can contain a short text that names the object.
Description 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 IfcProject, IfcBuilding, and 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 Name.

In contrast, non-rooted classes do not have the ability to assign a GlobalId, 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.

Classes are often described as what they inherit from. For example, rooted classes can be described as classes that inherit from IfcRoot, or subclasses of IfcRoot. 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.

Subclasses of IfcRoot

Rooted classes may be further broken down into three types of classes.

IFC Class Description
IfcObjectDefinition These subclasses describe "objects" or "things" that relate to the AEC industry. This includes walls, people, and tasks. You may think of them as the "nouns" in IFC.
IfcPropertyDefinition These subclasses describe properties of "objects" and "things". They themselves are not an object, but instead a property or quantity like fire rating, energy usage, or volume.
IfcRelationship These subclasses describe relationships between "objects" themselves, between properties, or between objects and properties. The relationships can be objects that contain other objects, connect to objects, have system inputs or outputs, or are assigned a property or quantity.

Subclasses of IfcObjectDefinition

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.

IFC Class Description
IfcContext This special category holds the starting point of IFC data, by describing either a project or library. There are only two subclasses: IfcProject and IfcProjectLibrary. See IFC projects and contexts for more information.
IfcElement These hold physical built elements that we come across every day, like slabs, columns, beams, furniture, pipes, cables, ducts, and so on. Example subclasses of IfcElement include IfcColumn, IfcBeam, and IfcFurniture. They may have geometry associated with them.
IfcSpatialElement These describe spatial concepts, such as sites, buildings, bridges, storeys, and spaces. These IfcSpatialElement classes can contain IfcElement elements inside them, such as a slab being inside a building storey. Example subclasses of IfcSpatialElement include IfcSite, IfcBuilding, and IfcSpace.
IfcElementType These describe construction types. A construction type may be assigned to an IfcElement, just like a particular IfcWall might have a particular construction type of 2 layers of plasterboard on a metal frame. Example subclasses of IfcElementType include IfcWallType, IfcDoorType, and IfcWindowType.
IfcStructuralActivity, IfcStructuralItem These are useful for structural analysis. They hold data to describe an anaytical model, including members, nodes, connections, loads, and forces, as well as the results from the calculations. Example subclasses include IfcStructuralCurveMember, IfcStructuralPointConnection, and IfcStructuralPointReaction.
IfcActor, IfcControl, IfcProcess, IfcResource These are useful for scheduling information, describing responsibility, tasks, resources, and timelines for construction sequencing or project planning. Example subclasses include IfcTask, IfcConstructionMaterialResource, and IfcWorkSchedule.

Subclasses of IfcPropertyDefinition

The following non-exhaustive table describes common subclasses used to describe properties, which can later be assigned to objects.

IFC Class Description
IfcPropertySet These classes help store properties of other classes, such as IfcElement. For instance, it may store a fire rating associated with an IfcWall. Some properties names and values are standardised within IFC, but end-users can also create their own properties. See IFC attributes and properties for more information.
IfcQuantitySet This is similar to IfcPropertySet but focuses on calculated quantities (lengths, areas, volumes, weights, etc). Some quantity names and values are standardised within IFC, but end-users can also create their own quantities. See IFC attributes and properties for more information.
IfcPropertyTemplateDefinition If you don't want to actually to store the value of a proprety but instead want to describe a template of what properties exist, which are required, and what data is valid for the purposes of exchange requirements or company standards, then this template subclass allows you to do so.
IfcPreDefinedPropertySet For some reason, some properties to do with door and window linings are given a special status in the IFC schema and have their own category. This will likely disappear in the future and merge into IfcPropertySet.

Subclasses of IfcRelationsip

TODO

A summary of non-rooted elements

TODO

List of IFC classes

There are multiple versions of IFC in use in the industry, and each version has hundreds of IFC classes. This makes it impractical to describe them in their entirety in a separate community wiki. However, there are some resources available for those who do want a list: