Intereference of spatial structure elements

[SergejMuhic]

The documentation of IfcRelInterferesElements has to be updated and the type of ConnectionGeometry changed to a select that allows IfcSpatialZone. Additionally, IfcSpatialZoneTypeEnum requires a new entry .INTEREFERENCE..

This issue is connected to a backlog issue that will address a more comprehensive solution regards project breakdown structure.
#112

[MatthieuPERIN]

Linked to #40 and solved by PR #39

[TLiebich]

I disagree to the proposed solution to add IfcSpatialZone to the SELECT for ConnectionGeometry. This would mix up two completely different concepts in IFC - the spatial zone as a semantic entity derived from IfcProduct and not a pure geometry, as the current connection geometries. Also it would conflict with the current pair of geometries at relating and related elements.

If I understand the concept expressed here correctly, the PDT would say:

the relating element (here a railway track) interferes with the related element (here a road segment) and that this inferference takes place (or is realized) in a spatial zone (IfcSpatialZone reflecting the overlay of the spatial reservations of the rail track and the road segment).

In analogy to a similar concept in IFC to express the connection between two pysical elements, like a beam and a joinst that is realized by a fastener, like a weld - see IfcRelConnectsWithRealizingElements I would rather adapt the concept of a RealizingElement to IfcRelInterferesElements - e.g.

ENTITY IfcRelInterferesWithRealizingElements
SUBTYPE OF (IfcRelInterferesElements);
RealizingElement : IfcSpatialZone; -- or any sensible supertype (also debatable, if a single one, or a potentially a set).
END_ENTITY;

Since ConnectionGeometry is optional it may not be set in this case.

P.S. IfcSpatialZoneType should still be updated with enumerator .INTERFERENCE.

somehow it also provokes (probably too late) the question, whether using IfcRelInterferesElements, that was introduced in IFC4.0 to identify and communicate clashes between physical elements was the best approach for the use case of overlapping spatial structures. So alternatively:

ENTITY IfcRelInterferesSpatially
SUBTYPE OF (IfcRelConnects);
RelatingElement: IfcSpatialElement;
RelatedElement: IfcSpatialElement;
RealizingElement: OPTIONAL IfcSpatialElement;
InterferenceType: OPTIONAL IfcIdentifier;
END_ENTITY;

and withdraw the changes from IfcRelInterferesElements to bring it back to IFC4.0 status.

[MatthieuPERIN]

Sevaral layer of answer

A/

I understand the concerns of @TLiebich regarding homogeneity of possible targets by the ConnectionGeometry, but concerns was raised by @SergejMuhic that relation with geometries are unpractical (weak objects) and should be avoided.

I actually agree with both point and this matter should be addressed (separated issue ?) in a near future as standalone Geometry cannot be shared easily and are not proper semantical objects (IMHO).

B/

Onto the maters at hand, I like the idea of an added new entity dedicated to hold the Interference between two Spatial Elements (maybe we will have use case with interference between two SpatialZone in some upcoming future) But this is a rather drastic change that was not discussed today ...

If @SergejMuhic agree, I will update documentation (reverting it !) and push actual documentation to the new object, I propose a more coherent name (@TLiebich please give feedback) IfcRelInterfersSpatialElements for this new Entity.

C/

Please also give feedback on this side request: actually IfcRelReferencedInSpatialStructure is used to "place" a SpatialZone within a Spatial structure and that somehow prevent it to be used to "reference" it in another SpatialElment. As IfcRelAggregates is out of scope here, I propose to use IfcRelContainsInSpatialStructure to actually "locate" the SpatialZone and keep IfcRelReferencedInSpatialStructure for (weak) referencing.

Telle me if you agree on this (small) change of usage, and update in documentation might be necessary (but schema-wise is already covered).

[SergejMuhic]

First, regarding selects there is plenty of cases where

This would mix up two completely different concepts in IFC

is not upheld. One of the most crazy selects is this or this. Another broken select is interference itself. Hence, my reluctance to use this. Then there is the issue of describing the "nature" of the relationship such as position, geometry, interference with strings.

I do not understand the desire to introduce a new relationship. This I have proposed on several occasions (even in our talk yesterday) and every time it was rejected. We had a wide acceptance in the meeting today.

From what our previous meetings and discussion, IfcRelInterferesElements is the desired way of representing such cases. If this has not changed and this last minute comment, although the PR is up and has been assigned more than 20 days ago, is what produced the problem, I would just say add an optional attribute to IfcRelInterferesElements that allows an IfcSpatialZone. As @MatthieuPERIN proposed the name ConnectionZone, I think we could go with it.

@MatthieuPERIN on C/ RelReferenced is non hierarchical Containment is hierarchical i.e. an element can be referenced in more than one spatial container but contained in only one. Consequently, local placement of the element is always relative to its container. That said, you cannot contain the spatial zone in two spatial structure elements.

ENTITY IfcRelInterferesElements
  SUBTYPE OF (IfcRelConnects);
    RelatingElement : IfcInterferenceSelect;
    RelatedElement : IfcInterferenceSelect;
    InterferenceGeometry : OPTIONAL IfcConnectionGeometry;
    InterferenceType : OPTIONAL IfcIdentifier;
    ImpliedOrder : IfcLogical;
    InterferenceZone: OPTIONAL IfcSpatialZone;
  WHERE
    NoSelfReference : RelatingElement :<>: RelatedElement;
END_ENTITY;

Keeps the storylines very close since that was an issue for not introducing a new relationship or a more sustainable solution. Should also not be problematic as ImpliedOrder was introduced in 4x3 also.

[TLiebich]

this propsal looks identical to my first proposal with the only exception, that you prefer to add an attribute at the end of the existing entity, whereas I proposed to use a subtype to distinguish betwen both. To me, both are potential resolutions.

Question: do you forsee a mixed use, i.e. that relating and related element are a physical and a spatial element, or are they always either or? If the second is correct, I would argue that having two different entities, IfcRelInterferesElements and IfcRelInterfersSpatially_ is the better solution, but also accept that it is very (too) late in the process.

My only concern (but this could be addressed to IFC5) is that the single entity IfcRelInterferesElements now is really overloaded for the sake of a connectivity relationship (brings it into the area of IfcRelSpaceBoundary which I would also prefer to modify at the next, probably IFC5, occasion).

[SergejMuhic]

The same entity was required due to storylines already producing datasets. Otherwise, if the naming is allowed to be changed, it would make more sense to introduce a well defined relationship and rethink all the added attributes in IfcRelInterferesElements.

I still think the proper way would be the option that I advocated for from the start and everyone agree to ti being the best solution:

It does not require schema changes, we can remove the interference changes that have made a mess out of IfcRelInterferesElements and would just require a concept template describing it. For now, we could even do without a dedicated IfcFacility for intersections.

IfcRelSpaceBoundary is exactly what I brought up as a relationship that slowly grew and suddenly looked more like an element. This is the main motivation to tame IfcRelInterferesElements before it is too late.

[MatthieuPERIN]

@SergejMuhic Solution E/ is not optimal for mixed infrastructure because it impose a rupture in Project organisation for infrastructure.

In #40 I have added property an dthat seems good for me.

Please have a review (I fear I might have missed something).

And I agree a full review and cleanup of the schema would be a good idea for IFC 5 🙈

[SergejMuhic]

Project organisation for infrastructure

Nope, it does not.

[MatthieuPERIN]

My point is that solution E/ make the shared infrastructure not a part (IfcRelAggregates) of the Rail nor the Road Structure, thus creating a (possibly several) separate projet organization. This means that the Rail/Road structure will be discontinuous in the tree representation which was not acceptable for Stakeholders.

Moreover, the option of having domain-related Physical objet not contained in domain specific SpatialStructure was not tested.

[SergejMuhic]

@MatthieuPERIN hence the right side proposal to have a FacilityPart in between to keep that relation going. Containment would be handled in those parts, location shared with the Facility in the common dataset. All of the intersetions could be described in the common dataset when bringing the parts together.

[MatthieuPERIN]

Agreed (imperfect) solution in PR #40 was merged by @AlexBrad1eyCT but reverted by @SergejMuhic (9f8c688).
I must admit I do not know what to do now !