Provision of a spatial structure of the project by aggregating spatial elements. The spatial structure is a hierarchical tree of spatial elements ultimately assigned to the project. Composition refers to the relationship to a higher level element (e.g. this storey is part of a building or this road segment is part of a road).
The project spatial structure may be made up of a selection of different spatial structure elements with the most generic and simplest form from high to low level as follows: IfcProject, IfcSite, IfcFacility (or any of its subtypes), IfcFacilityPart (or IfcBuildingStorey in the case of buildings), and IfcSpace with IfcSite, IfcFacilityPart and IfcSpace being optional levels. Therefore a spatial structure element should only be part of an element at the same or higher level, with the exception of IfcFacility which can be part of an IfcFacilityPart to allow for the regional or longitudinal division of a higher level facility into sections which can then contain one or more smaller functional facilities.
Where possible, the relevant subtype of IfcFacility should be used to describe the spatial structure element in question. When an adequate subtype of IfcFacility with predefined or user defined type is not available the higher level, generic IfcFacility entity can be instantiated with the relevant and agreed typing identifier defined in IfcFacility.ObjectType. This allows for nearly full coverage of built environment domains and/or scenarios that have yet to be addressed with specific extensions.
In addition to the identified spatial structure elements IfcSpatialZone can be used to provide cross domain or functional zones within a project. These elements are included into the hierarchy using the Spatial Containment concept (IfcRelContainedInSpatialStructure) and can be aggregated into a functional hierarchy in the same manner as other spatial structure elements, with the constraint that an IfcSpatialZone can only be composed within another IfcSpatialZone.
The following diagram shows the generic classes and relationships used when applying this concept.
In addition, concepts may have particular importance to common or standardised industry practices and scenarios. For these specific usage scenarios, the table below shows a recommended list of general usage patterns that users may adopt.