Depth and Width in Qto_SlabBaseQuantities

Rio

I think there is an error in the assignment of Depth and Width for slabs (IfcMaterialLayerSet) in the qto-function...

https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/Qto_SlabBaseQuantities.htm

theoryshaw

i could be wrong, but i think what determines length and width is based on the x and y direction the profile relative to the rotation of the origin--not whether an edge is longer or shorter--if that's what you were inferring.
So if you want these to read inversely, i would tab into the slab and rotate the profile 90degrees.

Rio

I think, according to my interpretation of the definition in the ifc spec, the width should always be this value in case of an slab with IfcMaterialLayerSet:

theoryshaw

I see what you're saying! Yes, having read the spec i would agree with the following...
ping @Massimo thoughts?

IFC Quantity	What it REALLY is	How humans say it
Width	Thickness	slab thickness
Length	Plan dimension	slab length
Depth	Plan dimension	slab width

Massimo

Does it change if you select Blender engine instead of ifcopenshell?

steverugi

My 2 1/2 cents as a human QS..
for a slab (horizontal layer) length and width are the horizontal dimensions, depth the vertical one (thickness)
but buildingSMART says differently:

in case of a slab or horizontal element depth in my opinion should be the extruded dimension

PS consulting Grok, ChatGPT, and Gemini they confirm my view= width and length are dimensions visible in plan view, depth in section view

Moult

Huh, I think we all agree the spec is silly here. I assume its for "consistency" with walls.

PR welcome to fix Ifc5d.

steverugi

Just to clarify, I don't see anything wrong with Qto_*BaseQuantities for IfcSlab and IfcWall, they correctly measure their _extrusion_ and the other two dimensions.
For IfcWall its thickness is expressed as "Width", given its LayerSetDirection AXIS2 (Y)
while for IfcSlab thickness goes with "Depth", its LayerSetDirection AXIS3 (Z)

Sure there might be cases where a particular slab geometry is created by extruding a X/Z profile along Y axis (concrete staircase/ramp, which have their own class), but in floors everybody measure it as WxLxH, Depth being the smallest of them, or just area (horizontal dimensions WxL, or calculated polyline) by height/thickness (H).

If anything to fix I'd humbly suggest the way Qto_SlabBaseQuantities are described in the page.
Interesting topic by the way, thanks

Nigel

:) I associate depth with pouring concrete and gravity

JanF

Just to add a central European pov:
here the z dimension would be either thickness, or height. Depth is even weirder than width.

Rio

@Massimo said:
Does it change if you select Blender engine instead of ifcopenshell?

no, its the same, but Length and Width are switched

Rio

@JanF said:
Just to add a central European pov:
here the z dimension would be either thickness, or height. Depth is even weirder than width.

I agree - thickness seems to be a better term if changing the ifc spec in the future. In the meantime, I think it would be best to stick to the current IFC specification definition to maintain interoperability in projects.

steverugi

@Rio

In the meantime, I think it would be best to stick to the current IFC specification definition to maintain interoperability in projects.

could you please point to a case where the current Qto values caused issues? thanks

Rio

For work, I check tender quantities against the corresponding IFC models. The models we review come from OpenBIM projects, where each project is planned by different companies using different software (Revit, Archicad, Allplan, etc.).
I discovered the discrepancy when I summed up the wrong net volumes for slabs – in Austria, we group them, among other parameters, by slab thickness (e.g. my query sums up the netvolumes of all slabs with a max. width of 5,0 m instead of 0,25 m). So this use case of automated quantity takeoff relies on standardized quantity definitions to ensure consistent quantities, regardless of the authoring software used.