How are the sides of IfcTrapeziumProfileDef's bounding box calculated in most implementations?

According to the specification, the center of the bounding box of the trapezoid is placed at Position.Location. From what I’ve seen using BlenderBIM and ifcviewer it seems that the sides of the bounding box are BottomXDim and YDim, and (TopXDim + TopXOffset) is not taken into account. However this is wrong when (TopXDim + TopXOffset) is bigger than BottomXDim. Does what I described happen in just those two viewers or is it how bounding boxes for trapezoids are calculated in general? I’d like to know what’s the general consensus so that I can create my IFC exports accordingly.

Dear Giovanni,

If I look into the documentation I read:
‘the BottomDim defines the length measure for the bottom line (half along the positive x-axis)’. so independently of the TopXDim + TopXOffset. In my perception even if TopXDim + TopXOffset is larger than BottomXDim (or ifTopXDim is negative) the BottomDim defines the centerpoint. Maybe my interpretation is wrong? Could you show me where it is stated it should be different?

Best regards,

Peter.

The description you posted is the one of the bottom line of the trapezium, not of the bottom line of the bounding box. Here is a definition of bounding box.
Here’s a drawing I made to show why it’s not always ok take into account only BottomDim and YDim when calculating the dimensions of the bounding box (drawn with a dashed line):


I’m not saying that this is an issue that must be fixed, I’d just like to know how the bounding box is calculated in most implementations.

EDIT: I read again what you posted and you’re right, so this is an issue with conflicting information in the IFC specification, because first they say

It is placed centric within the position coordinate system, i.e. in the center of the bounding box.

and then what you quoted

The IfcTrapeziumProfileDef is defined within the position coordinate system, where the BottomDim defines the length measure for the bottom line (half along the positive x-axis) and the YDim defines the length measure for the parallel distance of bottom and top line (half along the positive y-axis).

I see your point and considering the conflicting descriptions I actually think you are correct. The second conflicting placement description could be read as specific to the given example image.

We will change our implementation to follow the bounding-box approach what makes more sense and seems to be the correct interpretation from the documentation after reading it carefully for a second time.

By end of this week our ifc engine and ifc viewer should interpret Trapezium profiles in the way you described it, i.e. by having their origin in the center of the bounding box.

Wait a second, before modifying your implementation I would wait to hear from other implementers how they did this, because if all of you used BottomXDim and YDim there’s no reason to fix your code. I’ve personally confirmed that both your program and BlenderBIM do it this way, I don’t know about other products. Paging @angel.velez, @jonm, @andreas.geiger

Good point, I will wait with committing this change till we know how the others implemented it.

We don’t support it. I’m not sure that anyone’s ever noticed, because I am not sure it is actually generated by any software. To be honest, this is a better example of what we should remove from IFC than to try to figure it out.

@giovanniv the BlenderBIM Add-on does not currently support exporting an IfcTrapeziumProfileDef as IFC parametric geometry. Instead, it will convert it into a mesh at export time. Similarly, any bounding box generated after such a shape is imported will be calculated based on the mesh. As a result, it should take into account the entire shape. How are you getting your conclusions?

@giovanniv your interpretation is correct wrt to how the handling is implemented in IfcOpenShell and hence the software built around it. Profile is centered around BottomXDim / 2. https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.6.0/src/ifcgeom/IfcGeomFaces.cpp#L587 If indeed the section under Parameter is read as description of the picture instead of normative definition of the attributes. I agree with your reading and that of @PeterBonsma that our current implementations are wrong.

Do you agree then that the center_x should be (min(TopXOffset, 0) + max(TopXOffset + TopXDim, BottomXDim)) / 2?

I wholeheartedly agree with @angel.velez that these kind of definitions are not worth the ambiguity they introduce.

Clear, lets change the implementation. We all agree the current implementation is incorrect or not implemented.

I am not sure I agree if these definitions (even if not used frequently) should be removed from the schema. In my perception the schema is a theoretical structure where as much as possible clean, complete and with minimal redundancy geometrical (and other concepts) are described. In a sense independent from practical use, more from a theoretical level as a long term solution that covers what we expect to be used or even don’t yet expect to be used.

The MVD’s afterwards define what practical subsets from this theoretical model will seem relevant for certain exchange situations. Even if a concept is never used but it would make sense in a theoretical view on consistency, completeness etc. I would argue it should be part of the schema.

This is of course just my personal opinion and totally dependent on how BuildingSMART looks at development of long-term schemas.

Ok :slight_smile: OpenBIM at work. I’ve updated mine https://github.com/IfcOpenShell/IfcOpenShell/commit/ac2494968c1b617a98646c1df4791b66e518997e

@PeterBonsma here’s a file for testing. https://github.com/IfcOpenShell/files/blob/master/IfcTrapeziumProfileDef.ifc Using my latest code it’ll now look like this, so with the bounding boxes all centered around the Y-Axis

@angel.velez
Right, I just checked and apparently IfcTrapeziumProfileDef is not included in CoordinationView 2.0, I mistakenly assumed it was because all the viewers I used to open my files were able to render solids generated by sweeping trapeziums. I’ll have to stop using them.
@Moult
Sorry for the confusion, I only imported .ifc files in Blender to view them, I never tried exporting them. I got my conclusions from importing this file (2.9 KB), where the trapezium is positioned as if its center was at (BottomXDim/2, YDim/2), and comparing it to what I get from importing this other file (2.9 KB), where the trapezium is positioned considering the center of its bounding box. The solid represented in both files is supposed to have a single empty cylinder going throughout its length, however with the second file I was getting 3 empty cylinders of different radius, because the trapezium revolved to create the sectioned cone was in the wrong position. So I assumed that BlenderBIM uses only BottomXDim and YDim to calculate the center of the trapezium, which apparently is correct according to @aothms.
@aothms

Personally I was fine with the previous way you did it as I just wanted to know what was the most popular way, anyway if TopXOffset is the

Offset from the beginning of the top line to the bottom line, measured along the implicit x-axis.

then it should be negative if while going from the beginning of the top line to the bottom line I’m going left, which is the case of the image from the specification. So in the following case we would have TopXOffset = 2, BottomXDim = 4 and TopXDim = 6:


center_x should be 3 but with your formula we get (min(2, 0) + max(2 + 6, 4)) / 2 = 4, which is wrong.
I modified you formula to make it work and it seems to me that this one is correct: center_x = (max(TopXOffset, 0) + max(-TopXOffset + TopXDim, BottomXDim))/2

I would say the formula from Thomas is better. In your example TopXOffset = -2 and not 2.

We changed the implementation, will be available somewhere early next week.

Sorry, I don’t want to nitpick but it seems to me that if offset is measured from the beginning of the top line to the bottom line along the x-axis, then it must be positive in my example because it’s going from left to right, which is the direction of the x-axis.
But yes, if it’s the opposite of what I just said @aothms’ formula is correct.

Again more than one interpretation possible :slight_smile:

However here I think Thomas and my interpretation are correct, see for example the following explanation:
‘The top line starts with a distance of TopXOffset from [-BottomLine/2,YDim]’

I found one case where @aothms’ formula is wrong if you use TopXOffset as you defined it, which is a trapezium with BottomXDim=2, TopXDim=3 and TopXOffset=-6. center_x will be -2 which is impossible (it should be 4). So either my formula with my definition of TopXOffset should be used, or if you want to use your definition of TopXOffset the formula should be (abs(min(TopXOffset, 0)) + max(TopXOffset + TopXDim, BottomXDim)) / 2

Isn’t -2 the expected answer?

afbeelding

Yeah, I was measuring center_x from the left side of the bounding box to the right side, we should have agreed on what center_x meant before discussing how to find its value