In some country regulations, there are specific technical rules about minimum free pass dimension for Doors and Windows (for example: fire exit regulations, ventilation regulations, habitability regulation, and so on). By now, the current parameters of IfcDoor and IfcWindow of IFC 4.2, are not enought to evaluate these regulations:
There aren’t direct parameters for ifcdoor or ifcwindow
To try to calculate these “free pass dimensions” with the current parameters of the IFC 4.2 standard, is really impossible, caused by the variability of the design of doors and windows.
I propose 2 current parameters of the IFC, to implement to IfcDoor and IfcWindow:
ClearHeight (currently only is for IfcSpace): the ClearHeigt for IfcDoor and IfcWindow, represents the maximum clear height or free height dimension, of an opened door or window (with the main panels/leaf opened).
ClearWidth (currently only is for IfcRamp): the ClearWidth for IfcDoor and IfcWindow, represents the maximum clear width or free width dimension, of an opened door or window (with the main panels/leaf opened).
Correct @jwouellette, about ClearHeigth, there is no any direct parameter for IfcDoor or IfcWindow, that gives this kind of value.
About PanelDepth: the value has no relation about the required evalutaion of “Free pass dimension”
About PanelWidth, I create a little PDF with all the arguments explaining why it’s not a good option to use PanelWidth, in order to evaluate the minimum width, of the free pass dimension.
I think best way to move this forward is create an issue here Issues · buildingSMART/IFC4.3.x-development · GitHub I think your motivation makes sense. From personal experience I know this is important information in automated building permit checks.
One last suggestion. Did you consider OverallWidth - LiningThickness?
Thanks for your comment and link: i will create an Issue about this proposal.
About to consider the strategy to use OverallWidth - Liningthickness, it has several problems and risks:
The design of doors and windows can be really variable. Therefore, this strategy can only be aplyed for “Free Width evaluation”, in very specific cases, like very standard doors/windows, with the same Liningthickness of each side of the IfcDoor and window, and so on.
This strategy can not been aplyed for “Free Heigth evaluation”, because you should taking into account another list of parameters, and they depends a lot about the desing of the door/window: Threshold (exist? not exist?), multiple panels, multiple transoms, and so on.
I think that the best option is to include direct parameters (as the proposed parameters: ClearHeight, ClearWidth), at IfcDoor/IfcWindow level, maybe as direct parameters (not inside Lining or Panel level), or maybe as parametes in Pset_DoorCommon / PsetWindowCommon.
Hang on one moment? The area of a window is not the OverallWidth * OverallHeight, nor would the Glazed area be ClearWidth * ClearHeight. The overall area is already IfcWindow…Qto_WindowBaseQuantities…Area (IfcAreaMeasure) . The glazed area is already that multiplied by IfcWindow…Pset_WindowCommon…GlazingAreaFraction (IfcPositiveRatiomeasure). The schema and our use of it should avoid geometric and cultural assumptions. My favourite is a Palladian/Venetian Window.
Hello, Nick. I am not sure this sentence could be applied consistently to many of the class definitions the schema has. Ultimately construction systems have always a cultural root which they come or have been engineered from. Do you mean the schema classes are neutral enough to skip that factor? Sorry, because probably I didn’t take your real meaning. It would be appreciated if you can clarify. Thanks!
There is no assumption in the schema that windows are rectangular, even if that’s the case with the majority of worldwide urban commercial development. The proposals introduce that assumption. I like Palladian/Venetian/Serlian windows.
The proposal of the parameters ClearWidth and ClearHeight for IfcDoor and IfcWindow, helps to bypass the cultural problem, I think, because the concepts are the same like the existing parameters described in the IFC schema.
For example, the ClearHeigth parameter
The ClearHeight description for IfcSpace, is: Clear Height between floor level (including finish) and ceiling level (including finish and sub construction) of this space; the average shall be taken if room shape is not prismatic.
The ClearHeigth for orthogonal IfcDoors: the vertical dimension of free pass
The ClearHeigth for non orthogonal IfcDoors: it can be, for example, the average vertical dimension of free pass