handling of openings in the IFC4 reference view

[TLiebich]

We agreed for the scope of the Reference View to exclude direct and implied use of Boolean operations. Therefore the current use of IfcRelVoidsElement has to be:

• changed in the scope of the IFC4 RV
• excluded from the IFC4 RV

Since the main path element -> opening -> door/window should be maintained (to remain similar to the IFC4 design transfer view), it cannot be excluded. Hence we need to use IfcRelVoidsElement also in IFC4 RV, but have to define an alternative way of using it without implying a Boolean difference operation.

Currently we see two possibilities:

• use the Name attribute of IfcRelVoidsElement to differentiate between the two way of allying it (1) implying a Boolean difference, and (2) not implying it
• use a different shape representation identifier for the voided element (e.g. the IfcWall), instead of using "Body", use "NetBody" indicating, that it is the net geometry with all voiding already included. Add to the semantic definition of IfcRelVoidsElement that it only applied to "Body" geometry.

we need your opinion.

[pasi-paasiala]

The second option sounds simpler. There can be multiple openings for an element. The second option puts the info only to one element.

Pasi

-------- Alkuperäinen viesti -------- Lähettäjä: Thomas Liebich Päivämäärä:20.06.2014 1.15 (GMT+02:00) Saaja: BuildingSMART/IFC4-CV Aihe: [IFC4-CV] handling of openings in the IFC4 reference view (#14)

We agreed for the scope of the Reference View to exclude direct and implied use of Boolean operations. Therefore the current use of IfcRelVoidsElement has to be:

• changed in the scope of the IFC4 RV
• excluded from the IFC4 RV

Since the main path element -> opening -> door/window should be maintained (to remain similar to the IFC4 design transfer view), it cannot be excluded. Hence we need to use IfcRelVoidsElement also in IFC4 RV, but have to define an alternative way of using it without implying a Boolean difference operation.

Currently we see two possibilities:

• use the Name attribute of IfcRelVoidsElement to differentiate between the two way of allying it (1) implying a Boolean difference, and (2) not implying it
• use a different shape representation identifier for the voided element (e.g. the IfcWall), instead of using "Body", use "NetBody" indicating, that it is the net geometry with all voiding already included. Add to the semantic definition of IfcRelVoidsElement that it only applied to "Body" geometry.

we need your opinion.

Reply to this email directly or view it on GitHubhttps://github.com/BuildingSMART/IFC4-CV/issues/14.

[jlkiss]

Do we want cut the wall? No. In that case IfcRelVoidsElement should not be used. You can read this in the documentation: "This relationship implies a Boolean operation of subtraction between the geometric bodies of the element and the opening." I think instead of IfcRelVoidsElement another relation type should be used here.

[TLiebich]

@jlkiss - the proposal (option 2) is to not use Body representations for the element/opening here - because the implied Boolean operation shall only work on "Body" representation (of cause, the spec should be updated to write it in a clearer way).

If we do not use IfcRelVoidsElement here, we would have two different query paths between elements and door/windows between the reference view and the design transfer view (which of cause is also an option)

[AngelVelezSosa]

What if we had the "NetBody" representation as the main representation item, but also allowed for an optional "Body" representation? Even in the Reference case, we may want to know the original shape of the wall without cutouts.

[TLiebich]

@AngelVelezSosa we had this option (although originally considered for the design transfer view) already in mind, it would allow for having complex, dimension driven CSG geometry (as for design transfer) plus a tessellated net geometry (for viewing and validating) in the same IFC file.

[timchipman]

Angel's recommendation has been adopted, where 'Mesh' is the identifier of the representation providing the resulting shape as a tessellation. This enables either 'Body', 'Mesh', or both representations to be exchanged, and doesn't require any special conversion of voiding relationships for varying export.