Industry Foundation Class STEP/XML Files (IFC) Feature Representation
This section describes the features which are output from the IFC reader. In general, the IFC writer will accept feature which have the same structure as those output from the reader.
IFC Objects – Relational Mode
When operating in relational mode, the IFC reader will produce a feature for each object in the source IFC file. In terms of the IFC data model, this means each object whose type is a subtype of IFCProduct will be output as a feature. These features will have a number of attributes which indicate its place within the IFC object hierarchy.
- GlobalId: This attribute will contain the object’s global id, as copied directly from the IFC file. When writing features, this value may be replaced if it is not a valid GUID. For more information, see the buildingSMART International IFC GUID specification.
- ifc_unique_id: This attribute will contain a value which is guaranteed to be unique among all features produced from a single IFC file. In some cases, multiple objects within a single IFC file will have the same GlobalId value. In those cases, the ifc_unique_id attribute can be used to distinguish between features with the same GlobalId.
- ifc_parent_id: This attribute will contain the GlobalId value of the feature’s parent object. For example, a wall feature will have a building storey feature as its parent, and a window may have a wall or opening as its parent object.
- ifc_parent_unique_id: This attribute is similar to the ifc_parent_id attribute, except that it will contain the same value as the ifc_unique_id attribute of the parent feature.
Each feature will have an IFMEAggregate geometry. The parts of the aggregate will be the various geometry representations of the object, as well as any property/quantity sets that describe the object.
IFC Objects – Hierarchical Mode
When operating in hierarchical mode, the IFC reader will produce a single feature which contains all the IFC objects in the source file. Each object will be represented by an IFMEAggregate geometry. The geometry name will indicate which type of IFC object is represented by the aggregate geometry.
Each part of the aggregate geometry will be a geometric representation of the object, a property/quantity set, or a nested IFC object. Typically, the top levels of the hierarchy will look like this:
IfcProject > IfcSite > IfcBuilding > IfcBuildingStorey
Writing IFC Objects
The IFC writer will accept features whose feature type is a known IFC object type. The full list of object types varies depending on the version of IFC being written. The most common feature types are:
- IfcProject
- IfcSite
- IfcBuilding
- IfcBuildingStorey
- IfcSpace
- IfcBeam
- IfcColumn
- IfcWall / IfcWallStandardCase
- IfcDoor
- IfcWindow
- IfcSlab
- IfcRoof
- IfcStair / IfcStairFlight
The IFC writer will automatically create project, site, and building objects, if none are provided as features from the workspace. In addition, a building storey object will be created to hold all features that have no parent id, or whose parent id cannot be resolved.
The writer will accept IFC objects as features, or as nested geometries. For example, a wall object could arrive as an IfcWall feature, or as a geometry contained within a parent object, with the geometry name set to IfcWall. This corresponds to the hierarchical and relational reader modes.
In addition to the id values described in IFC Objects – Relational Mode, all IFC objects can have a Name and Description value. Some object types may have further values as well. For example, when writing IFC2x3, IfcRailing objects may have a PredefinedType value, and when writing IFC4, an IfcWindow object may have several additional values, including PredefinedType and PartitioningType. To determine the exact values that an object may have, refer to the documentation for the IFC version that is being written.
Writing Geometry
An IFC object may have multiple geometric representations. For example, a wall could have a 3D model, as well as a simple line representation. Each geometric representation belongs to a representation context. The list of representation contexts the IFC writer will output can be set using the Representation Contexts parameter.
Each geometric representation must indicate which context it belongs to. This value can be set in the geometry name, or in the ifc_representation_identifier geometry trait.
This value must exactly match one of the values in the Identifier column of the Representation Contexts writer parameter, and the geometry type must match one of the types listed in the corresponding Geometry Types cell. A geometry will be ignored if it does not meet these criteria.
Writing Opening Geometry
In the IFC data model, openings are objects which must be explicitly created. For example, when creating a window in a wall, first the opening must be cut out of the wall, and then a window is placed into the opening.
The IFC writer expects IfcOpeningElement objects to arrive as features or nested geometries, exactly like any other IFC object. However, the geometric representation of an opening may arrive as part of another feature. If a CSG solid arrives as the geometry representation of an object, the writer will look at any subtracted solids for an ifc_opening_id trait. If this trait exists, the geometry will be used as the geometric representation of the linked opening object. If the trait value does not correspond to an IfcOpeningElement object, a new one will be created.
Property Sets
Depending on the value of the Read Property/Quantity Sets As reader parameter, the IFC reader represents property sets with nested geometries, or as features. If the feature representation is used, the feature type will be IfcPropertySet. Similarly, if the geometry representation is used, the geometry name will be set to IfcPropertySet. The IFC writer will look for these values when determining which type of IFC object a feature or geometry represents. The ifc_property_set_name attribute/trait will be set to the property set name, and the GlobalId attribute will contain the property set ID. When writing property sets, the GlobalId is not required, and an ifc_unique_id value may be used instead. If an ifc_unique_id value is used, the IFC writer will automatically generate a valid GUID for the property set.
When property sets are read as features, an IFC object will refer to a property set by including the property set’s GlobalId value in the object’s ifc_property_sets{} list attribute. Similarly, the IFC writer will look for this list attribute when relating IFC object features to property set features. In the writer, this list attribute may contain the GlobalId or ifc_unique_id value of the related property set. The individual properties in the property set will be set as attributes on the IfcPropertySet feature.
When property sets are read as nested geometries, the IFMEAggregate geometry representing an IFC object will contain a geometry instance for each property set associated with the IFC object. The geometry instance will refer to a geometry definition, which will be an IFMENull geometry. The individual properties in the property set will be set as traits on the geometry. Since the property set is nested within the object’s aggregate geometry, there is no need to link the object to the property set with the ifc_property_sets{} list attribute.
Quantity Sets
Quantity sets are handled similarly to property sets – the IFC reader will produce quantity sets as features or as nested geometries. Depending on the representation used, the feature type or geometry name will be set to IfcQuantitySet. The ifc_quantity_set_name attribute/trait will contain the quantity set name, and the GlobalId attribute/trait will contain the quantity set id. When writing quantity sets, the GlobalId is not required, and an ifc_unique_id value may be used instead. If an ifc_unique_id value is used, the IFC writer will automatically generate a valid GUID for the quantity set.
When quantity sets are read as features, an IFC object will refer to a quantity set by including the quantity set’s GlobalId value in the object’s ifc_quantity_sets{} list attribute. Similarly, the IFC writer will look for this list attribute when relating IFC object features to quantity set features. In the writer, this list attribute may contain the GlobalId or ifc_unique_id value of the related quantity set. The individual quantities in the quantity set will be set as attributes on the IfcQuantitySet feature.
When property sets are read as nested geometries, the IFMEAggregate geometry representing an IFC object will contain a geometry instance for each quantity set associated with the IFC object. The geometry instance will refer to a geometry definition, which will be an IFMENull geometry. The individual quantities in the property set will be set as traits on the geometry. Since the quantity set is nested within the object’s aggregate geometry, there is no need to link the object to the quantity set with the ifc_quantity_sets{} list attribute.
Property and Quantity Set Definitions
The IFC reader can optionally produce features which contain the definition of the property and quantity sets in an IFC file. This behavior is controlled by the Create Property/Quantity Set Definition Features parameter.
These definition features can be considered as "schema features" for the property and quantity sets in an IFC file. They will contain list attributes that describe the names, types, and data types of the properties in a property set, or the quantities in a quantity set.
The IFC writer will only write property and quantity sets for which it has a definition. By default, the writer is aware of the property and quantity sets that are defined in the IFC specification, such as Pset_BuildingCommon or Qto_WallBaseQuantities. In order to write property or quantity sets that are not defined in the IFC specification, a definition feature must be sent to the writer. In particular, when performing an IFC-to-IFC translation, the source property and quantity sets will only be preserved if the property and quantity set definition features from the reader are sent to the writer.
Property Set Definitions
A property set definition feature will have its feature type set to PropertySetDefinition. The property set name will be stored in the ifc_property_set_name attribute. Information about the properties in the property set will be stored the following list attributes:
- ifc_properties{}.name – This list attribute will contain the names of the properties in the property set.
- ifc_properties{}.property_type – This list attribute will contain the type of the property. At the moment the only supported property types are:
- IfcPropertySingleValue
- IfcPropertyBoundedValue
- IfcPropertyEnumeratedValue
- ifc_properties{}.data_type – This list attribute will contain the data type of the property. There is a larger number of supported data types. The full list can be seen at the following pages:
IFC2x3 | IFC4 |
---|---|
Quantity Set Definitions
A quantity set definition will have its feature type set to QuantitySetDefinition. The quantity set name will be stored in the ifc_quantity_set_name attribute. Information about the quantities in the quantity set will set stored in the following list attributes:
- ifc_quantities{}.name – This list attribute will contain the names of the quantities in the quantity set.
- ifc_quantities{}.type – This list attribute will contain the types of the quantities in the quantity set. Valid values in this list attribute are:
- IfcQuantityArea
- IfcQuantityCount
- IfcQuantityLength
- IfcQuantityTime
- IfcQuantityVolume
- IfcQuantityWeight
Reading/Writing Distribution Port Objects
Objects of type IfcDistributionPort define the topology of distribution systems in a building, such as the plumbing, electrical, or HVAC systems. The IFC reader produces a feature for each IfcDistributionPort object in the IFC file. These features use the ifc_parent_id attribute to refer to the distribution object they are a part of, such as a pipe fitting or an air duct. In addition, if two ports are connected, each one will have its ifc_connected_port_id attribute set to the GlobalId value of the other.
When writing distribution port objects, it is not necessary for two connected port objects to refer to each other. The reference may go in one direction only.