Object's position differ from its centroid's coordinates

[yasser]

Hi there,
I have created some IfcBuildingElementProxys using xBim to enrich an IFC file, gave them a geometry using the swept solid representation type. I followed the IFC schema in generating these objects. I am able to view the newly created elements in all kind of softwares that understand the IFC (BIMVision, FZKViewer, Revit,…), so far so good, Until a colleague makes a remark about the distances between these new elements.

To simplify the issue at hand, the screenshot below showcases one of the elements, its hard coded coordinates are (40.0, 40.0, -5.0) when creating the IfcCartesianPoint, but when the IFC file is generated and viewed, the actual position is at (120.0, 120.0, -8), and for the life of me I can’t figure out how is it happening. I tried different values like (2.0, 2.0, 0) but I get the position at (6.0, 6.0, 0).

Any idea or insight what I could be doing wrong?

Any help is much appreciated.

[Moult]

Sharing your IFC file would help. Have you tried opening in BlenderBIM?

[yasser]

Hi @Moult , here I share my IFC file, the screenshot shows four blocks of elements I have created, respectively starting at at coordinates (0, 0, 0), (0, 40, 0), (40, 0, 0) and (40, 40, 0) but if you check the distance between them it’s going to be 120 as mentioned before.

geo_enriched_last.ifc (563.8 KB)

[Moult]

As shown in this top-down view, your model has the four objects at (0, 0, 0), (0, 40, 0), (40, 0, 0) and (40, 40, 0). The 120, 120, -8 is a calculated value that your IFC viewer is calculating and does not actually exist inside the IFC file.

The GlobalId of the element you selected is actually 1KdxB0pO9C$AaIlh3XF2oI in your export. It seems your authoring program did not maintain the GlobalId in your subsequent import, which is a problem in itself.

Nevertheless, that object has a local placement which is placed absolutely (i.e. not relative to anything) at 40, 40, -5. The object has one shape representation, which is an extruded area solid. The extrusion itself has its own position defined as 40, 40, 0 extruded downwards (i.e. 0, 0, -1) for 6m. The profile is defined as a circle of 2m radius, with a center at 40, 40, 0. These altogether create a series of offsets. First, we start with the object location, then the extrusion position, then the profile position, so (40, 40, -5) + (40, 40, 0) + (40, 40, 0). This means that the top of the circle profile ends up being at 120, 120, -5. Because the circle is extruded 6m down, the final calculated centroid is at 120, 120, -8. This relationship is described here, and visualised by this diagram:

You can see in BlenderBIM with a 10m grid background that the object origin (represented by the small orange circle) is indeed at (40, 40, -5) and the shape itself is offset an additional 80, 80, 0. I hope the explanation makes sense. The behaviour of your BIM viewer is correct.

[yasser]

I didn’t really think the profile and the extrusion position would add up to the offset, will give it more reading to understand it.
@Moult thank you for your explanation, cheers.

[yasser]

A bit far from the issue you have clarified but related, do you have some insights on why in Revit it moves the whole new objects to a different starting position, I tried blender and it’s amazing how the elements are where they are expected to be, but with Revit they just moved, as if the origin (0,0,0) of the elements is different than the one of all the objects that were there before enriching the ifc.

[jonm]

First suggestion would be the project base point has been relocated, and the Revit IFC import/link is relative to project internal origin.
There is no provision to control this in the out of the box importer. As an alternative, the 3rd party Geometry Gym (I’m the developer) Ifc importer could be tried as we do present import options including placement relative to shared coordinates or project base point location.

[yasser]

Will reread this article from @Moult https://thinkmoult.com/ifc-coordinate-reference-systems-and-revit.html. @jonm, I think you pointed the right direction.
Thank you.