It had always been “the way” in IFC such that the glazing panel in a curtain wall was classified as an IfcPlate.CURTAIN_PANEL.
However I’m increasingly questioning this. I’ve been recently working a lot with trying to do facade costing and sustainability analysis, and finding this a very problematic area.
Here are the problems I’m finding:
- CURTAIN_PANEL as a predefined type for IfcPlate is the odd one out. Everything else is … well, what I would traditionally detail as a plate, not the glass panel.
- IFC classes predominantly classify based on function, not on form. So I don’t quite buy the argument that a vision panel or spandrel panel in a curtain wall is an IfcPlate. Semantically, I’d say a vision panel is an IfcWindow, and the spandrel panel is an IfcCovering.
- IfcWindow, who’s definition is “… a building element that is predominately used to provide natural light and fresh air … includes … and fixed panels”, also states " … be part of an element assembly, typically an IfcCurtainWall". So it looks like the specification already talks about classifying the glazing panels as IfcWindow in the curtain wall. After all, we classify IfcDoor for doors in curtain walls.
- One of the most critical bits of information for curtain wall glazing is for things like the number of glazing layers, whether it’s coated, fill gas, etc, and all of this is available in Pset_DoorWindowGlazingType … which is applicable to IfcDoor and IfcWindow, but not IfcPlate.
I see two possible solutions:
- Use IfcWindow instead of IfcPlate, I think it’s a much better fit.
- Create a custom pset to store the glazing data for an IfcPlate.