Update IfcVoidingFeature.md

[52-78]

The number of holes in buildings can exceed the number of openings. I suggest adding the use of Reference Geometry concept for IfcVoidingFeature in the same way as IfcOpeningElement. An IFC file with Reference Geometry for IfcVoidingFeature will make the work of viewers easier.

I also suggest using Quantity Sets concept for IfcVoidingFeature. Holes reduce the weight of building structures while increasing the surface area of the structure. It will be useful to get the design characteristics of holes for consideration in the building model.

I note that these changes will be useful in IFC4_ADD2_TC1 - 4.0.2.1

[aothms]

It would be good to know if the current situation is intentional or not. I can imagine that for example holes for screws increase the triangle count dramatically more than window openings do, while maybe not as significant for visual display or quantities. But it could also simply be an oversight due to abstractions being introduced into the inheritance hierarchy. Maybe @TLiebich has some recollection of this?

On a technical note, this only the documentation change, the actual association of a concept template to an entity needs to be defined in UML, but we can apply that change.

[berlotti]

@TLiebich please provide insights.
@evandroAlfieri please put this on the agenda of the Implementer Forum for discussion and potential implementer agreement (with validation service rule)

[TLiebich]

not sure whether I completely follow the original question. There seems to be several aspects to the issue:

1. usage of voiding features to describe the substractions both geometrically and semantically
2. usage of reference geometry to disable Boolean Difference operations (i.e. forcing support for CSG in receiving applications

to 1) voiding features should be handled the same way as opening elements - looking back to the IFC specification, some documentation to this regard should be added (e.g. the explicit use of reference geometry not to be used on Boolean operations, the definition of a base quantity set, etc.)
to 2) for IFC4 RV it was decided to not use CSG - same applied to IfcVoidingFeature (but documentation is sparse)

whether or not holes for bolds and screws are to be modelled and exchanged is more an information requirement question and not an IFC or MVD question. I know that software like TEKLA provides an export option to avoid having all this holes that increases file size and import time with little added value.

so my recommendation would be to enhance the definition of IfcVoidingFeature (following mainly IfcOpeningElement)

[aothms]

I also suggest using Quantity Sets concept for IfcVoidingFeature.

Agreed. Feel free to suggest a proposal.

I know that software like TEKLA provides an export option to avoid having all this holes that increases file size and import time with little added value.

To me this make sense. Similar to how we have "if the IfcShapeRepresentation.RepresentationIdentifier = 'Reference', then the Reference shape representation of the opening is not subtracted. It is provided in addition to the hole in the Body shape representation of the voided element."

We could either:

• Create two variants: Reference and (e.g) AuxiliaryReference, or
• On VoidingFeature we write "... the opening may or may not be subtracted depending on user or implementation choices regarding the trade-off between increased triangle count versus geometric correctness ..."

I think option1 is not too great of an idea because this reference string may actually be checked in implementation, so if we silently introduce an additional string variant of it, it may break assumptions (we could also add this additional detail in yet another attribute, but it's a bit ugly either way). Also if an implementation would want it's not that hard to reverse engineer whether the opening was actually cut out of the body or not.

[TLiebich]

Quantity Sets concept for IfcVoidingFeature

copy of Qto_OpeningElementBaseQuantities

with one modification:

Depth | The depth of the object. | Depth (or thickness) of the voiding feature. Only provided, if the depth is constant.

Representation - would opt for:
On VoidingFeature we write "Depending on the RepresentationIdentifyer, the void has to be subtracted from the body geometry of the parent element, if its value is 'Body', or it shall not be subtracted, if its value is 'Reference'.

Whether or not an application does exclude voids from the export all together is in my view not part of the spec. It is an application functionality for its IFC interface.