IfcRelInterferesElements new usage in IFC Infra project

[MatthieuPERIN]

This issue is to track discussion about the update usage of IfcRelInterferesElements for IFC Infra project:

• Link between IfcSpatialElement as a mean to describe interaction between Spatial structure
• Evaluate need for IfcSpatialElement x IfcElement relation
• Update documentation to clarify Relation properties in these new context

Proposed InterferencesTypes are : " Crosses", "PassesThrough", "PassesOver", "PassesUnder", "Clash", "Along"

[AlexBrad1eyCT]

In relation to above I am of the opinion that there is no use case currently for spatial to physical interference therefore some restriction (informal or formal) is required to to restrict this cross interference.

As far as everything else the related pull request covers 90% of the expected cases and guidance on encoding.

[MatthieuPERIN]

There is an use case in Rail: interactions between the footprint of a railway (IfcRailway) and existing / designed duct system (IfcProduct)

This Unit test (UT_RSS3) was postpone to Storyline test because of the work on IfcRelInterferesElements(Chicken-and-egg issue).

Overview of the spatial composition:
 

Duct (multi-tubular + manholes) positioning:
 

Overview of the data structure (without interactions):
 

[MatthieuPERIN]

Comment by @SergejMuhic in #40 copied here to be discussed:

Spatial structure elements are not supposed to intersect. That is kind of their purpose, reserving space. If subtracting anything, does the dataset have to feature the subtracted geometry, or are both elements supposed to have original geometry (e.g. IfcRelVoidsElement)?

To me two points here:

1. The Spatial Structure Element intersecting issue
2. The substracted geometry / IfcRelVoidsElement

[MatthieuPERIN]

Comment on point 2 above:

The updated documentation is just a reformulation of the old one about the subtraction of geometry. I think that we should stick to the usage of IfcRelVoidsElement and state that the geometry should remain complete.

[MatthieuPERIN]

Comment on point 1 above:

• The spatial structure are defined in the documentation as "organizing structure" without any physical/geometrical regulation (as their shapes are optional).
• The traditional usage of these concepts in Building description imply non spatial overlapping (buildings / storey description)
• Infra stakeholder will need to have overlapping structural description for their projects as for example: a railway level crossing is an area part of the road structure and the rail structure altogether.

I propose therefor to release the usage rule about preventing spatial structure overlapping.

Nevertheless, some misleading and ineffective spatial decomposition may then exists (e.g:  a spatial element holding all the sleepers and another for the rails) if we do not provide "usage rueles", I propose to add an explicit statement in documentation to prevent that:

1. The spatial project structure, established by the IfcRelAggregates, shall be acyclic. (existing rule in documentation)
2. At the exception of shared area where several infrastructures meet, the spatial structure elements should not overlap with each other.

These rules may be added to IfcRElInterfers documentation and maybe updated in IfcSpatialStructureElement ?

[larswik]

On Issue 1: The use of IfcRelInterferesElement for spatial structure elements was agreed on already in the Infra/Rail harmonization meeting in Stockholm mid September 2019 as a replacement for the previously proposed new relationship type from IFC Road project (I don't remember the exact name of the proposed relationship type) derived from Stakeholder requirements coming from concepts such as overpass and underpass and the fact the e.g. IfcBridge and IfcRoad or IfcRailway are separate (but related) facilities.
Options:

1. Leave as proposed
2. Find an alternative solution if the current proposal is not allowed.
3. Delete this option from schema and accept this as a gap between stakeholder's requirements and schema put the requirement in the backlog

I would put my personal vote on 1 or 3 given the available time.
From a data structure point-of-view, I don't see a problem at all. Each physical element may still belong uniquely to exactly one spatial structure element (very much like files in a folder structure where some files may be "shortcuts" across to another place in the structure). The problems may be the overlap (which there actually is in the physical world - the road or railway is inside the tunnel), if there is such a strict rule, and maybe also some software vendors being unwilling to implement the concept, at least in the short term.

[MatthieuPERIN]

Solution to be implemented, follow in #111