Proposal to make IfcRelVoidsElement a one to many relationship --> IfcRelVoidElement

[theoryshaw]

Related conversations...

• Allow IfcRelVoidsElement to be a one to many relationship.  buildingSMART/NextGen-IFC#87
• https://community.osarch.org/discussion/comment/9580

[Moult]

I'm thinking of abusing IfcRelConnectsWithRealizingElements for this. Thoughts @aothms?

Window <-- Fills --> Opening <-- Voids --> Wall

Window <-- RelConnectsWithRealizingElement (Opening is RealizingElement) --> Covering (or whatever secondary thing the window is also voiding)

[aothms]

But did you consider Window - Fills - Opening - Voids - Wall - Decomposes - { Part, Covering }? Sent from a mobile device. Excuse my brevity. Kind regards, Thomas Op vr 10 mrt. 2023 11:09 schreef Dion Moult ***@***.***>:

…

I'm thinking of abusing IfcRelConnectsWithRealizingElements for this. Thoughts @aothms <https://github.com/aothms>? Window <-- Fills --> Opening <-- Voids --> Wall Window <-- RelConnectsWithRealizingElement (Opening is RealizingElement) --> Covering (or whatever secondary thing the window is also voiding) — Reply to this email directly, view it on GitHub <#2140 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAILWV4QJN6Y5P2O36S5WFTW3L4ULANCNFSM5TOCUFUQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Moult]

Would that work? Is there a rule that voiding the aggregate also voids all parts? I can't find it in the spec?

I'm generally not a fan of decomposition during design stages, as it would be pretty annoying when modeling to manage 2 times the number of walls, then have to also consider the object placement of this aggregate which is not very meaningful. Decomposition is great when dealing with assemblies (e.g. steel) and modular design for fabrication, but it's pretty imposing when architects just want to slab together walls.

[Moult]

Huh, it does work. I still can't find the rule in the spec though?

If it really does work I guess I can look at ways to make the UX of authoring this less painful. I noticed some weird behaviour when trying to move the wall parts around but maybe that's just a BlenderBIM Add-on bug.

test2.ifc.txt

[aothms]

I had a look, pretty sure it's written somewhere generically as well but here it is referenced for slabs "openings within the composite slab are directly assigned to IfcSlabElementedCase using IfcRelVoidsElement <https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/schema/ifcproductextension/lexical/ifcrelvoidselement.htm> pointing to IfcOpeningElement <https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/schema/ifcproductextension/lexical/ifcopeningelement.htm> and apply to all aggregated parts" https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/link/ifcslabelementedcase.htm It's not ideal I know, also doesn't solve the "elevator shaft problem". Sent from a mobile device. Excuse my brevity. Kind regards, Thomas Op vr 10 mrt. 2023 12:36 schreef Dion Moult ***@***.***>:

…

Huh, it does work. I still can't find the rule in the spec though? If it really does work I guess I can look at ways to make the UX of authoring this less painful. I noticed some weird behaviour when trying to move the wall parts around but maybe that's just a BlenderBIM Add-on bug. test2.ifc.txt <https://github.com/IfcOpenShell/IfcOpenShell/files/10941554/test2.ifc.txt> [image: 2023-03-10-223242_821x478_scrot] <https://user-images.githubusercontent.com/88302/224305835-0a54cae6-cc96-49be-8a38-0b4d233f44fc.png> — Reply to this email directly, view it on GitHub <#2140 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAILWV4GSMXYOTFYGFMYY4LW3MG2PANCNFSM5TOCUFUQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Moult]

Awesome! I'm working through the UX of it and so far I think it can work out!

BTW I think this is actually a different issue to the elevator shaft problem. The "elevator shaft problem" could be mitigated through mapped representations of many openings, one per slab. However, this is slightly different, this is about a single filling element filling multiple openings... which as you say is solved via decomposition!

[aothms]

Hm indeed I missed that emphasis. There's another somewhat prevalent case that can't be solved by decomposition: when an opening exists for a window that vertically spans multiple walls.

[Moult]

So this now works. I think over time we can refine the UX so that there are hotkeys to quickly combine wall parts (i.e. add to new aggregate, add as sibling to existing aggregate, unassign aggregate, delete aggregate), as well as manage how the voids are either affecting the aggregate or parts (i.e. promote fill/void to aggregate, or demote fill/void to part) but that will come with time and experience after playing with it more.

[aothms]

pass a list of elements

You'll have to iterate over the list yourself. I think it's better if the API to stays close to the schema.

void all the elements that the opening element intersects with

Again, you'll have to do it yourself. You can use ifcopenshell.geom.tree to get all intersecting elements.