Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update IfcRelInterferesElement DocEntity & Documentation #40

Original file line number Diff line number Diff line change
Expand Up @@ -15,10 +15,10 @@
<Documentation></Documentation>
</DocAttribute>
<DocAttribute Name="InterferenceType" UniqueId="a92075e8-181d-4233-bd6a-e3efed6da830" DefinedType="IfcIdentifier" AttributeFlags="1">
<Documentation>Optional identifier that describes the nature of the interference. Examples include &apos;&apos;Clash&apos;&apos;, &apos;&apos;ProvisionForVoid&apos;&apos; (physical elements), and �Crosses�, �PassesThrough� �PassesOver� �PassesUnder� (spatial elements).</Documentation>
<Documentation>Optional identifier that describes the nature of the interference.</Documentation>
</DocAttribute>
<DocAttribute Name="ImpliedOrder" UniqueId="57512488-73cf-44cc-995d-d5e84df6ae44" DefinedType="IfcLogical">
<Documentation>Logical value indicating whether the interference geometry should be subtracted from the _RelatingElement_ (if TRUE), or whether it should be either subtracted from the _RelatingElement_ or the _RelatedElement_ (if FALSE), or whether no indication can be provided (if UNKNOWN).</Documentation>
<Documentation>Logical value indicating if the _RelatingElement_ has priority over the _RelatedElement_. TRUE value imply that relation is oriented from _RelatingElement_ to _RelatedElement_ (in regards of the _InterferenceType_) and that the _InterferenceGeometry_ should be subtracted from the _RelatingElement_. FASLE value imply that relation has no orientation and that _InterferenceGeometry_ may be subtracted from the _RelatingElement_ or the _RelatedElement_.UNKNOWN value imply that no information about the orientation is provided</Documentation>
AlexBrad1eyCT marked this conversation as resolved.
Show resolved Hide resolved
</DocAttribute>
</Attributes>
<WhereRules>
Expand Down
Original file line number Diff line number Diff line change
@@ -1,12 +1,25 @@
The _IfcRelInterferesElements_ objectified relationship indicates that two elements interfere. Interference is a spatial overlap between the two elements. It is a 1 to 1 relationship. The concept of two elements interfering physically or logically is described independently from the elements. The interference may be related to the shape representation of the entities by providing an interference geometry.
The _IfcRelInterferesElements_ objectified relationship indicates that two elements interfere. Interference is a spatial and/or shape interaction between the two elements. It is a 1 to 1 relationship. The concept of two elements interfering physically or logically is described independently from the elements. The interference may be related to the shape representation of the entities by providing an interference geometry.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is a spatial interaction and how is it different from a shape interaction?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change have being lost/reverted in actual version of the develop branch.


\* When the interference geometry is available it can be passed by the optional attribute _InterferenceGeometry_ pointing to _IfcConnectionGeometry_. The connection geometry is provided as a point, curve, surface, or volume within the local placement coordinate systems of the connecting elements. The _IfcConnectionVolumeGeometry_ is the default type to be used for interference in 3D space, as indicated in e.g. clash detections.
\* If the interference geometry is omitted then the interference is provided as a logical relationship. Under this circumstance, the connection point, curve, surface, or solid has to be recalculated by the receiving application.
* When the interference geometry is available it can be passed by the optional attribute _InterferenceGeometry_ pointing to _IfcConnectionGeometry_. The connection geometry is provided as a point, curve, surface, or volume within the local placement coordinate systems of the connecting elements. The _IfcConnectionVolumeGeometry_ is the default type to be used for interference in 3D space, as indicated in e.g. clash detections.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Volume is not a term in geometry items. Volume is a measurement type. Solid is the proper terminology.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why I cannot add a suggestion here but this "coordinate systems of the connecting elements" is ambiguous. Which element? Only one local placement can serve as the basis. I guess Implied order should influence this also?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* When the interference geometry is available it can be passed by the optional attribute _InterferenceGeometry_ pointing to _IfcConnectionGeometry_. The connection geometry is provided as a point, curve, surface, or volume within the local placement coordinate systems of the connecting elements. The _IfcConnectionVolumeGeometry_ is the default type to be used for interference in 3D space, as indicated in e.g. clash detections.
* When the interference geometry is available it can be passed by the optional attribute _InterferenceGeometry_ pointing to _IfcConnectionGeometry_. The connection geometry is provided as a point, curve, surface, or solid within the placement coordinate systems of the connecting elements. The _IfcConnectionVolumeGeometry_ is the default type to be used for interference in 3D space, as indicated in e.g. clash detections.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SergejMuhic amusingly your are wrong and right at the same time! :D

  1. you are correct in the sense the term is solid, but amusingly the subtype is called IfcConnectionVolumeGeometry so theres that !
  2. it sounds ambiguous but is correct IfcConnectionGeometry subtypes are made up of 2 geometries one for the overlapping zone on RelatingElement (in its placement) and the same for RelatedElement (in its placement). so...! :p

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Solid was kept is the actual version

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SergejMuhic amusingly your are wrong and right at the same time! :D

1. you are correct in the sense the term is solid, but amusingly the subtype is called _IfcConnectionVolumeGeometry_ so theres that !

2. it sounds ambiguous but is correct IfcConnectionGeometry subtypes are made up of 2 geometries one for the overlapping zone on _RelatingElement_ (in its placement) and the same for _RelatedElement_ (in its placement). so...! :p

You have to read my comments carefully. And I would appreciate that you refrain from labeling them wrong. Thank you.

Volume is not a term in geometry items.

That is a fact. IfcConnectionGeometry is by no means a geometric item. It has been introduced specifically to not be a geometric item (or a representation item) but to "describe the geometric and topological constraints that facilitate the physical connection of two objects". Semantics.

* If the interference geometry is omitted then the interference is provided as a logical relationship. Under this circumstance, the connection point, curve, surface, or solid has to be recalculated by the receiving application.

The _RelatingElement_ and _RelatedElement_ define the two elements in the relationship, that may have different roles. This is controlled by the attribute _ImpliedOrder_.

\* _ImpliedOrder_=TRUE\S\ The _RelatingElement_ constitutes the primary element of the interference relationship. If the interference is to be resolved by subtracting the overlapping part, it should be subtracted from the _RelatingElement_. The net result would be the _RelatingElement_ subtracted by the _InterferenceGeometry_. This would be the case in interference relationships where the _RelatedElement_ creates a void in the _RelatingElement_ dynamically.
\* _ImpliedOrder_=FALSE\S\ The _RelatingElement_ and _RelatedElement_ have no priority among each other. If the interference is to be resolved then no information about whether the _InterferenceGeometry_ should be subtracted from the _RelatingElement_ or thed _RelatedElement_ can be traced. This would be the case for clash detection results.
\* _ImpliedOrder_=UNKNOWN No information about the priorities is provided.
The _RelatingElement_ and _RelatedElement_ define the two elements in the relationship, that may have different roles. The relation orientation may be required by certain _InterferenceType_ values, this is done by setting the attribute _ImpliedOrder_ accordingly:

* _ImpliedOrder_=TRUE\S\ The _RelatingElement_ constitutes the primary element of the interference relationship that is oriented from _RelatingElement_ (source) to _RelatedElement_ (target). If the interference is to be resolved by subtracting the overlapping part, it should be subtracted from the _RelatingElement_. The net result would be the _RelatingElement_ subtracted by the _InterferenceGeometry_. This would be the case in interference relationships where the _RelatedElement_ creates a void in the _RelatingElement_ dynamically.
* _ImpliedOrder_=FALSE\S\ The _RelatingElement_ and _RelatedElement_ have no priority among each other. If the interference is to be resolved then no information about whether the _InterferenceGeometry_ should be subtracted from the _RelatingElement_ or the _RelatedElement_ can be traced. This would be the case for clash detection results.
* _ImpliedOrder_=UNKNOWN No information about the priorities is provided.

The _IfcConnectionGeometry_ property is used to define the interference shape, it can be part of the shape of one of the elements of the relationship (in the case of clash, overlapping and crossing interference types) or define the interface between the two shapes (in the case of along, over and under interference types).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The _IfcConnectionGeometry_ property is used to define the interference shape, it can be part of the shape of one of the elements of the relationship (in the case of clash, overlapping and crossing interference types) or define the interface between the two shapes (in the case of along, over and under interference types).
The _InterferenceGeometry_ attribute is used to define the interference shape, it can be part of the shape of one of the elements of the relationship (in the case of clash, overlapping and crossing interference types) or define the interface between the two shapes (in the case of along, over and under interference types).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This section was lost/reverted in actual devellop version ...should it be back ?


The _InterferenceType_ property optionally specifies the type of interference between the two elements, two set of default types are provided:
**Oriented interferences types** imply usage of _ImpliedOrder_ set to TRUE and specific choice of _RelatingElement_ and _RelatedElement_ to be meaningful:
* Crosses: the _RelatingElement_ is crossing the _RelatedElement_ (e.g. Railway crossing a road)
* PassesThrough: the _RelatingElement_ is passing through the _RelatedElement_ (e.g. a Road passing inside a tunnel)
* PassesOver: the _RelatingElement_ is passing over the _RelatedElement_ (e.g a bridge passing over a water canal)
* PassesUnder: the _RelatingElement_ is passing under the _RelatedElement_ (e.g a Pipe passing under a road)

**Non oriented interferences types** do not imply specific values of _ImpliedOrder_ (but can still be set to precise shape interference calculation)
* Clash: The _RelatingElement_ and _RelatedElement_ have a spatial or shape-based clash
* Along: The _RelatingElement_ and _RelatedElement_ have a common frontier/surface

> HISTORY&nbsp; New entity in IFC4.