The Spatial Interference with Zone concept is an extension of the Spatial Interference concept which defines the relationship of spatial elements, such as facilities (IfcFacility & specialised subtypes) or facility parts (IfcFacilityPart with domain specific predefined types) that interfere or interface with other spatial elements across discipline spatial hierarchy branches, and extends the dataset with a related interference IfcSpatialZone via the IfcRelInterferesElements.InterferenceSpace attribute. The realizing IfcSpatialZone should always have the PredefinedType value set to INTERFERENCE.
The addition of a realizing IfcSpatialZone extends the functionality of this relationship with the following:
- The ability to attach property sets to the co-engineering (or interference) zone.
- Allows explicit definition of the shared footprint or body geometry representing the zone where the IfcSpatialElement entities interfere, without impacting the footprint or body geometry of the interfering IfcSpatialElement entities.
- Products are still positioned within the domain spatial structure and can use relative positioning.
The Spatial Interference with Zone concept is defined to cover complex use cases where the interference results in co-engineering zones where multiple teams have to collaborate within the same spatial area while maintaining ownership and rights over there domain elements. A common example of this is a level crossing between a railway and a road. The road and railway hierarchies each have a segment that relates to the level crossing and an IfcRelInterferesElements relationship is defined to encode this connection. The relatiohsip is then extended with an IfcSpatialZone that defines the co-engineering zone and specific overlapping footprint or body geometry. Property sets can then be attached to the IfcSpatialZone and the explicit footprint or body geometry can be utilised for automated clash and cross domain approval/notification of model updates.
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.