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 == |