IfcRectangleProfileDef - XDIM and YDIM

[vitorhpmartins]

The section that mentions 'YDIM' specifies it as the 'width of the rectangle', however, shouldn't it correctly be the 'height of the rectangle'?"

[aothms]

Length and Width are in my opinion the typical names for the extents of a rectangle, eg. see https://en.wikipedia.org/wiki/Rectangle#Formulae I would associate Height more with the Z-axis.

[vitorhpmartins]

@aothms It's true... I hadn't thought about it that way. It's because I was trying to find the height of a beam within the IFC structure documentation, so I ended up getting confused.

I found this example, so the height of the beam would be the "depth" of the section:

https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/annex_e/basic-geometric-shape/extruded-solid.html#Figure-E.B-shows-the-block-geometry-represented-by-an-extrusion.

But now another point has come to mind. Why is the depth (z) of an IfcBeam not part of the Qto?

Because the Qto of this entity contains the length, but the length would be the YDIM? I'm confused now.

Because when we look at this other image, it points out that the "length of the beam" would be the depth, but I confuse this with the property called length contained in the Qto of the IfcBeam class:

And forgive me if I'm raising more basic concepts, but here in Brazil as our default language is not English, we need to read the buildingSMART documentation and understand the concepts of Ifc's words and technical concepts well to "translate" the application into our projects in Ifc

[aothms]

I found this example, so the height of the beam would be the "depth" of the section:

Yes, but that's in this case specifically. We don't know how the 2d profile is embedded in 3d. It could also end up being rotated 90 degrees. IFC offers for a lot of flexibility and few conventions on how geometry is being defined (but there are some, for example walls always run along local X axis, doors open towards positive Y, etc.).

Because the Qto of this entity contains the length, but the length would be the YDIM? I'm confused now.

In case of a beam, indeed length of the beam equals the depth of the extrusion. This can indeed be confusing. I don't know @Jesusbill @Krande how do structural engineers typically disambiguate these terms?

[Krande]

@aothms unfortunately my company does not use IFC for quantity assesments, so I don't really know how one might disambiguate the terms based on IFC directly.

However, on a more general note regarding the terms height and length of a beam and my experience using them as a structural engineer. We always use height as a reference the cross-section height of a beam. And length refers to the extrusion length of the beam.

@Jesusbill Any other thoughts? :)

[Jesusbill]

@aothms I'd say we barely need to, as "depth" is not very common as a term for a beam's length. Width and Height are the common terms I believe for a rectangular cross-section for XDim and YDim respectively.

@vitorhpmartins

Because the Qto of this entity contains the length, but the length would be the YDIM? I'm confused now.

Qto should contain Length for the length of the beam and CrossSectionArea for the area of the profile

[vitorhpmartins]

@Jesusbill, @Krande and @aothms Ok, we have reached an "agreement" that the length of the beam extrusion is indeed specified in the Qto. However, my question/doubt is why the properties of the beam section, such as the height (YDim) and width (XDim) of the cross-section, are not present within the Qto set.

Even though these two properties exist and are associated with the cross-section of the IfcBeam, it is not possible to extract this information from the beam's Qto, as these details would be in another class of the object (IfcRectangleProfileDef).

The method I found to extract this information using BlenderBIM, for example, was as follows:

The question I pose here is that the cross-section information (YDim and XDim) of the beam (IfcBeam) serves to categorize the types of beams we will have in our project in order to quantify and plan the construction.

We also know that this information can be, for example, in the Name or ObjectType. In short, there are various possibilities to create categories and groupings to quantify the types and quantities of beams in a project.

The point was just to get your perspective on whether the information (YDim and XDim) could be included within the Qto of the IfcBeam, as these two pieces of information are "directly" extracted from the 3D geometry and are not merely properties that the user associated with the Name or ObjectType of the IfcBeam.

[Jesusbill]

@vitorhpmartins the answer would be that XDim and YDim are specific to rectangular profile but a general Qto of an IfcBeam should be applicable for any profile, so XDim and YDim would be obsolete. Instead, the CrossSectionArea exists for any profile and I guess it would be good for quantity calculation.

In general you would need to get the Profile of the beam from its associated IfcMaterialProfileSet to have access to the local attributes like XDim and YDim

[vitorhpmartins]

@Jesusbill I understand; however, the idea of having easy access to the section dimensions (XDim and YDim) is because, depending on the type of IfcBeam, we need to use these different dimensions to perform calculations for concrete formwork of beams.

Example 01:

If the beam is a beam located between two slabs or floors, the YDim dimensions considered in the formwork calculations would not be as impacted, as we can observe in the image below:

However, if the beam is a border or corner beam, we can notice that the dimensions to be considered for YDim may vary, thus altering the quantity when we use formulas based on the YDim dimensions:

The point here of having the possibility to access the section dimensions of a beam through the Qto set would be primarily to facilitate certain calculations for the user (designer).