For our company we are starting the use of BIM and IFC. One of the main reasons is for quantity takeoff.
That’s the reason for my question. For a concrete beam we need the amount of formwork besides the volume. For most other types of elements we have a solution (perimeter * width for a slab, OuterSurfaceArea for columns, …).
But for a beam we can’t use any of the existing properties. The OuterSurfaceArea includes the top and bottom surface so that value will be too high.
Ideally we’d be able to read somehow the side surface of the beams. But if that’s not possible we would be OK with the values for Length, Height and Width. Then it’s a simple formula to calculate the side surface and eventually the bottom surface, depending on the need.
For ifcFooting the Width and Height are included in the Qto_FootingBaseQuantities. Is there a particular reason why it doesn’t exist for ifcBeam? I understand that there are many other possibilities like I-shaped beams in concrete and all kinds of beams/columns for steel. But I can see a lot of advantages of having the “bounding box” dimensions also for those kind of shapes.
I hope someone can help me out, maybe with a workaround.
Thank you in advance!
I think the reason that bounding box dimensions aren’t stored in the IFC file is that they’re very easy to calculate on the fly from the shape of the material. Storing them in the file would just be wasted disk space.
Hmm… in general bounding box calculation may be non-trivial, imagine profile with chain of arcs and bsplines. However I think Johan referred to slightly different thing.
@JohanDeCock,
“The OuterSurfaceArea includes the top and bottom surface” - this is incorrect statement.
Both column and beam define this value as side surface only.
- Total area of the extruded surfaces of the beam (not taking into account the end cap areas), normally generated as perimeter * length
- Total area of the extruded surfaces of the column (not taking into account the end cap areas), normally generated as perimeter * length
@igor.sokolov, With the “top and bottom surface” I was reffering to a beam, not column. It is a part of the perimeter, right?
There are also software libraries (e.g XBIM and IfcOpenShell that integrate with OpenCASCADE) that enable to derive these kind of quantities from the geometry. That way you’re sure that the information is derived consistently and according to the procedure you’re after.
Thank you for the suggestion @aothms
However the same could be said for all kinds of quantities, which would make the use of the Qto_…BaseQuantities obsolete, would you agree?
It is a good point that we should also look to some kind of solution that works on any IFC that we might get.
The thing is, I don’t really see any benefit in not providing some very basic shape information in the IFC. For ifcFooting these parameters exist (probably because that kind of geometry is almost always a rectangular prism shape). For ifcSlab there is the attribute “Width” that should only be given in case of a constant tickness/width of the slab.
So why not provide Width and Height for an ifcBeam?
I was thinking about how that should fit with ifcColumn and ifcMember. For a column it might be very confusing to use “height” for something else than the vertical dimension (which is already called length).
@BenHollingsworthSDS2, that reply about wasted disk space, wouldn’t that be true for soo much more properties? I don’t think that should be a concern. I’d rather have a good structured IFC file that contains a little more data than a 100 MB IFC file with very detailed geometry (that I wouldn’t need) and no information at all.
Well, not necessarily. It still defines meaningful quantities that can be calculated/checked/fixed by automated tools.
But yes, quantities (and to a lesser extent properties) are somewhat sparsely and inconsistently defined. There are probably various reasons:
- Some of these properties are more characteristics of the profile than the element, we do have specific ProfileProperties (but not profile quantities). They are unfortunately a different mechanism as ProfileDef is not a rooted entity. [Defining these properties as part of the profile would also eliminate the ambiguity of “height” (as the profile is 2d).]
- There has been the tendency to define properties/quantities specific to a single entity and don’t generalize based on certain traits. That has resulted in some inconsistencies.
- Parts of IFC are developed as projects, where they focus on a certain domain and don’t have a mandate to make drastic changes to other domains. This can also result in inconsistencies.
I’m not sure on the time window for proposing changes to GitHub - buildingSMART/IFC4.3.x-development: Repository to collect updates to the IFC4.3 Specification but that repo would be the place to discuss these kind of proposals. They will probably move to 4.4 though.
1 Like
Exactly. This is why a “bS project” is a challenge, by itself. The need of including a review across the different involved/related domains should be a priority whenever a meaningful change is made in that regard.
@JohanDeCock I did not use “top” and “bottom” in my post but “end caps”