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. Decomposition refers to the relationship to a lower level element (e.g. this storey has spaces or this road has road segments).
The project spatial structure may be made up of a selection of different spatial structure elements with the most generic and simplest form from low to high level as follows: IfcSpace, IfcFacilityPart (or IfcBuildingStorey in the case of buildings), _IfcFacility (or any of its subtypes), IfcSite and IfcProject with IfcSite, FacilityPart 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 high level facility in to 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 a 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 composed under 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 tables below shows a recommended list of general usage patterns that users may adopt.