How to make voids to spatial elements like IfcBridgePart?
IfcBridgePart is not inherided from IfcElement but IfcSpatialElement.
The IfcRelVoidsElement schema definition says:
ENTITY IfcRelVoidsElement
SUBTYPE OF (IfcRelDecomposes);
RelatingBuildingElement : IfcElement;
RelatedOpeningElement : IfcFeatureElementSubtraction;
END_ENTITY;
As a result of which, IfcRelVoidsElement cannot be used for an objectified relationship between IfcBridgePart and an opening element.
The schema validation result:
For instance:
#459923=IfcRelVoidsElement(‘3uJiDo3f50XPijYIJPReze’,#5,$,$,#407853,#407903)
^^^^^^^
With attribute:
<attribute RelatingBuildingElement: >
Value:
#407853=IfcBridgePart(‘32qVXIieLAqOSIpmqE5abU’,#5,‘Blinding (Pier)’,$,‘BLINDING’,#405382,#407852,‘B1-1’,$,.NOTDEFINED.,.USERDEFINED.)
Not valid
IfcBridgePart plays a similar role for bridges as IfcBuildingStory for buildings. It is a spatial/project decomposition structure - like superstructure or substructure. So I would assume, that it does not have own volumetric geometry. Therefore I should not have openings either.
Some of the predefined types for IFCBridgePart do sound like volumetric objects, such as “PYLON” or “ABUTMENT”. But it is true that in the same list you find more “conceptual” entities like SUBSTRUCTURE. Abutments for instance are considered as substructures anyways, so the list does not really make sense, seems to be listing different types of concepts.
So, if we are not meant to rename an object (e.g in Revit, Tekla) to IFCBridgePart>ABUTMENT (because these are volumetric objects) what should I use? IFCWall? IFCBuildingElementProxy? + Userdefined= “Abutment”?
There is also IfcRelInterferesElements, which specifically uses a newly introduced type IfcInterferenceSelect which selects IfcSpatialElement and IfcElement. So it seems relevant here. @sergej@PeterBonsma maybe one of you can clarify?
As @TLiebich explained, spatial structure elements are abstract hierarchical project breakdown structure elements and therefore any geometric representation attached to them is very sketchy. What would that even mean? The extent of a building is the sum of its parts. If there are no external walls and a roof, there is no building.
If a pylon is just a conceptual grouping of parts i.e. it is not one physical thing (could still be made up of parts) that is assembled on-site, then IfcBridgePart makes sense. If you are treating your pylon as one physical element that is assembled off-site and brought as one piece/product and installed on-site, please opt for IfcElementAssembly.PYLON. It is a matter of physical element vs organizational project structure. For this reason both a spatial structure and an element assembly can be typed as a pylon. These were the requirements of stakeholders in the IFC Bridge project.
Albeit IfcRelInterferesElements as mentioned by @aothms was expanded to ‘model’ interferences in spatial structure (was just elements before), it was not meant as a voiding type of concept. Unfortunately, there was never a broad consensus on how to use it and was more of a political consensus than a properly documented concept template. See here: https://github.com/bSI-InfraRoom/IFC-Specification/pull/40 → It is merely a possibility to have a reference to a footprint geometry if a road and a rail part interfere with each other. The hierarchical nature of Spatial De/Composition and Spatial Containment inherently does not allow one element to reside in many spatial containers i.e. spatial structure elements. Meaning, voiding makes little sense.
The exception to the above were curtain walls that were not modelled per storey and were IfcRelReferencedInSpatialStructure. I cannot say this is the clearest and I cannot remember seeing it in IFC4 but it was an exception. I would have seen a more clear approach in containing overreaching IfcCurtainWalls in IfcBuilding. Digressing, so shutting up now.