Depth and Width in Qto_SlabBaseQuantities

Comments

• theoryshaw

  February 13 edited February 13

  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

  February 13

  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

  February 13

  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

  February 13

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

  February 13 edited February 13

  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

  February 13

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

  PR welcome to fix Ifc5d.

  
• steverugi

  February 13

  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

  February 13

  :) I associate depth with pouring concrete and gravity

  
• JanF

  February 13 edited February 13

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

  
• Rio

  February 14

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

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

  
• Rio

  February 14 edited February 14

  @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

  February 15

  @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

  February 15

  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.