IfcDoor - BaseQuantity

[Mats_Knutsson]

Hi,

The BaseQuantity Height for a door refers to the text in italic below. As seen in the attach the height refers to the wall opening height and not the door height. For some reason I've never thought of this...it makes the BaseQuantites irrelevant. Anyone using BaeQuantites with your builders?

/Mats

"Overall measure of the height, it reflects the Z Dimension of a bounding box, enclosing the body of the door opening. If omitted, the OverallHeight should be taken from the geometric representation of the IfcOpening in which the door is inserted. NOTE The body of the door might be taller then the door opening (e.g. in cases where the door lining includes a casing). In these cases the OverallHeight shall still be given as the door opening height, and not as the total height of the door lining."

[NandoMogollon]

Yep I rely on those BaseQuantities for cost estimating purposes ( I should say... a client off mine)

So far, and from experimenting with custom built Door and Window Objects, it seems like the BaseQuantites values are populated with whatever nominal values - like in your screenshot - something closer to the door panel or clearance, but definitely shorter than the measured opening height.

Would be much better to have information from the source rather than guessing, but I'm not confident the software architects do wander this forums.

Hope this helps

[Mats_Knutsson]

Well not really haha. Our client read the BQ and it's wrong. Simple as that. Also ceilings have to be modeled with slab or roof in order to get BQ out of it and we often model ceilings with profiles and frames. I'm fgravitating to nevere export BQ in the future. If the clinet knows which data in BQ that's correct it's fint but if he doesn't....it's bad. We usually use one pset for every data that is required ...one single source idea...The reason for modeling as in my example with the vertical door offset is that the footing is done by the contractor and not us.