search

buildingSMART / IFC4.3.x-development

Repository to collect updates to the IFC4.3 Specification
Other
168 stars 83 forks source link

IfcDoor and IfcWindow : add "ClearHeight" and "ClearWidth" parameters #88

Open EipmXcoll opened 3 years ago

EipmXcoll commented 3 years ago

Hi all, @TLiebich and @aothms ,

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:

I propose 2 current parameters of the IFC, to implement to IfcDoor and IfcWindow:

These proposed parameters can be stored as direct parameters for IfcDoor/IfcWindow (not inside Lining or Panel level), or maybe as parametes in Pset_DoorCommon / PsetWindowCommon.

Thanks and kind regards, Xavier Coll EiPM

aothms commented 3 years ago

I'm typically not a big fan of explicit properties. Due to (a) redundancies and that (b) anyway the data typically isn't provided (c) often these kind of parameters are computed using different local norms. So I'd rather try to get the data structure in a way that the parameters are directly expressed in it rather than as secondary meta-data.

In this case I tend to agree that (a) the use case is valid (b) it's hard to base this data off of the current parameters (c) similar properties exist on other entities.

In the long run I think we need to solve this problem (and others) more with decompositions. As an example: this set of window arrangements is not exhaustive https://standards.buildingsmart.org/IFC/DEV/IFC4_3/RC2/HTML/schema/ifcsharedbldgelements/lexical/ifcwindowtypepartitioningenum.htm It shouldn't be an enum. Decompositions give us the flexibility to encode any kind of config and attach necessary meta data to the panels. And maybe have some other element in there with reference-opening-like-semantics to have the free pass area in there (if it's still necessary then: if we have properly tagged decompositions, computation on them is also much more trivial either by doing a boolean union on the constituents or by adding subtraction quantities).

TLiebich commented 3 years ago

my recommendation would be to add them as property definition to Pset_DoorCommon / PsetWindowCommon. We should phase out the few direct properties in order to have one generic way to handle properties via property sets.

aothms commented 3 years ago

Agreed

Sent from a mobile device. Excuse my brevity. Kind regards, Thomas

Op ma 30 aug. 2021 09:49 schreef Thomas Liebich @.***>:

my recommendation would be to add them as property definition to Pset_DoorCommon / PsetWindowCommon. We should phase out the few direct properties in order to have one generic way to handle properties via property sets.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/buildingSMART/IFC4.3.x-development/issues/88#issuecomment-908120328, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAILWV2YTIWPFEQFL3M364DT7MZYBANCNFSM5C67U4KQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

NickNisbet commented 3 years ago

There is already a Qunatity "Area" and a Property "GlazingAreaFraction".

EipmXcoll commented 3 years ago

Good morning @NickNisbet , First of all, thanks for your answer.

The scopes of "Area" and "GlazingAreaFraction" are completely different to the proposed "ClearHeight" and "ClearWidth" parameters.

I write my comments about the current parameters suggested, and why they can not be used like the proposed "ClearHeight" or "ClearWidth" parameters:

Kind regards, Xavier Coll EiPM

NickNisbet commented 3 years ago

Apologies! Two meanings of ‘Clear’. Yes, this requirement will be part of the buildingSMART Regulatory Room “Regulatory Information Requirements” project to identify common properties that are crucial to regulations, regardless of any contractual Expectations.

Sent whilst away from my desk.

Regards,

Nick.

Nicholas Nisbet FRSA MA(Cantab) DipArch(UNL)
Fellow: Royal Society of Arts Fellow: buildingSMART International & UKI Chapter Director: AEC3 UK Ltd Web: http://www.aec3.com E-mail: @.*** Direct: +44 (0) 1494 714 933
Mobile: +44 (0) 781 616 8554
Skype: nicholasnisbet Registered Address: 46 St Margaret's Grove, Great Kingshill, High Wycombe, Bucks, HP15 6HP, UK

Vice-Chair: buildingSMART UK Chapter Convenor: buildingSMART Regulatory Room

** Confidentiality Notice **. This e-mail and any file(s) transmitted with it, is intended for the exclusive use by the person(s) mentioned above as recipient(s). This e-mail may contain confidential information and/or information protected by intellectual property rights or other rights. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender and delete the original and any copies of this e-mail and any printouts immediately from your system and destroy all copies of it.

On 5 Sep 2021, at 10:01, EipmXcoll @.***> wrote:

 Good morning @NickNisbet , First of all, thanks for your answer.

The scopes of "Area" and "GlazingAreaFraction" are completely different to the proposed "ClearHeight" and "ClearWidth" parameters.

I write my comments about the current parameters suggested, and why they can not be used like the proposed "ClearHeight" or "ClearWidth" parameters:

"Area" (maybe do you mean Qto_DoorBaseQuantities-> Area?) (1) the value is the area of the IfcOpening, not the "Free pass" of a door or of a window. And well, (2) it's an area, not a vertical or horizontal dimension.

"GlazingAreaFraction" -> (1) It's for glazed panels, as it's described in the standard IFC. (2) This area is a sum of the glazed panel areas: the designs of doors and windows are really variable, with mobiled panels and fixed panels. And well, (3) his value it's an area, not a vertical or horizontal dimension.

Kind regards, Xavier Coll EiPM

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

Moult commented 2 years ago

Agree with this proposal and that these attributes are incredibly useful in the building domain. +1 to @TLiebich's solution of adding these two as properties to the psets.

For windows, such as in awning windows, in Australia the requirements are not particular to a width or height, but just a "clear opening" (e.g. such that a sphere of X millimeters can pass through). Perhaps "ClearOpening" is useful in other countries too?

TLiebich commented 2 years ago

So far, I am only aware of clear width (German: lichte Breite) and clear height (lichte Höhe) as requirements. Of cause it somehow preassumes a rectangular opening. But also the max. opening angle of the door leaf and its handles may influence the clear width. So it is best a property within the Pset_DoorCommon / WindowCommon property set that can be provided independently from the actual opening geometry.

Moult commented 2 years ago

It looks like we all pretty much agree on this and there is a clear proposal, so I'm going to upgrade to "decided". If anyone has objections, now is the time :)