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 100: Line 100:
 
== Subclasses of <code>IfcRelationship</code> ==
 
== Subclasses of <code>IfcRelationship</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.
+
TODO
 
 
{| class="wikitable"
 
! IFC Class
 
! Description
 
|-
 
| <code>IfcRelAssigns</code>
 
| This relationship is used when a particular object supplies a resource or fulfills a task for another object. It is commonly used for resource management and construction sequencing, determining processes, resources, and actions performed by people. Example subclasses include <code>IfcRelAssignsToResource</code>, <code>IfcRelAssignsToProcess</code>, and <code>IfcRelAssignsToProduct</code>.
 
|-
 
| <code>IfcRelAssociates</code>
 
| This relationship is used when a particular object has a source of information associated with it, such as an external document, classification system like Uniclass, project library, or material definition. This is commonly used for facility management. Example subclasses include <code>IfcRelAssociatesDocument</code>, <code>IfcRelAssociatesClassification</code>, and <code>IfcRelAssociatesMaterial</code>.
 
|-
 
| <code>IfcRelConnects</code>
 
| This relationship is used when a particular object is joined physically or virtually to another object. This is usually used in analytical models, such as structural analysis where members and nodes connect to each other, MEP systems analysis where ports join together, or environmental analysis, where spaces have boundaries and are covered by particular material layers. Example subclasses include <code>IfcRelConnectsStructuralMember</code>, <code>IfcRelConnectsPorts</code>, and <code>IfcRelSpaceBoundary</code>.
 
|-
 
| <code>IfcRelDecomposes</code>
 
| This relationship is used when a particular object (physical or virtual) is built up of smaller object parts. Smaller parts may be simple aggregated into a larger whole, or projecting from a object, or embed itself within another object. Example subclasses include <code>IfcRelAggregates</code>, <code>IfcRelProjectsElement</code>, and <code>IfcRelVoidsElement</code>.
 
|-
 
| <code>IfcRelDefines</code>
 
| This relationship is used when a particular object can be defined by a common set of definitions, such as properties, manufacturer / construction types, or a template of definitions. This relationship is very commonly used, specifically to define properties (both buildingSMART standard properties, and custom user properties) to objects, and define construction types. Example subclasses include <code>IfcRelDefinesByProperties</code>, <code>IfcRelDefinesByType</code>, and <code>IfcRelDefinesByTemplate</code>.
 
|}
 
  
 
== A summary of non-rooted elements ==
 
== A summary of non-rooted elements ==
  
There are far too many ''non-rooted'' elements to list in totality, however a curated selection as shown below give a indication of the types of data that are stored in an IFC file, which can be reused by ''rooted'' elements.
+
TODO
 
 
{| class="wikitable"
 
! IFC Class
 
! Description
 
|-
 
| <code>IfcMaterial</code>
 
| A material may be named, and then have further ''non-rooted'' classes assigned to it, such has simple RGB colours, textures, and material properties for environmental simulations.
 
|-
 
| <code>IfcCartesianPoint</code>
 
| As you might expect, IFC can store 2 or 3 dimensional Cartesian coordinates. This is one of the building blocks of many other ''non-rooted'' classes, such as the ability to locate an object in space, or build up geometric representations.
 
|-
 
| <code>IfcFacetedBrep</code>
 
| A huge variety of geometric forms may be described in IFC. One commonly known format is a faceted BREP, or series of polygons that describe the surface of an object.
 
|-
 
| <code>IfcPerson</code>
 
| Information about people and organisations can be recorded, which is especially useful as some countries have legislation that requires this to be stored.
 
|-
 
| <code>IfcPropertySingleValue</code>
 
| This commonly used class can define a single property in terms of a property name and its associated value. In addition, there are other classes that allow more complex properties in tabular or calculated form to be stored.
 
|-
 
| <code>IfcObjective</code>
 
| This little-known class can store design intentions, strategies, and objectives to be then associated with objects or portions of the BIM model.
 
|-
 
| <code>IfcRegularTimeSeries</code>
 
| When scheduling, events may occur at predictable time intervals, which may be stored.
 
|}
 
  
 
== List of IFC classes ==
 
== List of IFC classes ==

Please note that all contributions to Wiki.OSArch are considered to be released under the Creative Commons Attribution-ShareAlike (see Wiki.OSArch:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)

Template used on this page: