buildingSMART Forums

How to position representations with a axis-specific scaled cartesian transformation operator?

If I create a regular IfcProduct subclass, I can nominate position using ObjectPlacement and Representation. The ObjectPlacement allows an IfcAxis2Placement3D which allows a Location, and through the Axis and RefDirection, it allows to specify a “rotation” as well. I do not see any ability to specify scale.

The IfcProductRepresentation allows a list of IfcRepresentation (one per context). One option is to directly place an IfcShapeRepresentation. This does not give me any placement / transformation capabilities, but does allow me to share the shape representation with other products.

Alternatively, I can place an IfcRepresentationMap using an IfcMappedItem. The IfcRepresentationMap allows another IfcAxis2Placement3D, where I can specify location and rotation. The IfcMappedItem allows me to place an IfcCartesianTransformationOperator3D. This again allows me to specify location, rotation (this time by specifying all axis), and scale. However, scale is a single IfcReal, so I cannot scale along an axis.

This leads to a few questions:

  1. Most 3D geometric systems I’ve used have a local axis, and a global axis. In IFC, as shown above, there seems to be a global axis (e.g. through the world axis), and a local axis through ObjectPlacement. However, there also seems to be additional axes through the IfcRepresentationMap and indirectly through the IfcMappedItem. I wonder if the number of axes can be reduced?
  2. How come scale can only be defined at the IfcMappedItem level, and not at the ObjectPlacement level?
  3. How come scale is only defined as a single value, and not as a per-axis value? How, then, would you handle “mirroring” transformations across a particular axis? Being able to mirror a shared representation would be very useful and efficient.
  4. In the IfcAxis2Placement3D, a location is specified first, followed by 2 axes. The third axis is derived. However, in the IfcCartesianTransformationOperator3D, the 2 axes (though not the same 2 as the IfcAxis2Placement3D) are specified first, followed by the location and scale. And only after that the third axis is specified, whereas it could be derived. Why is there this inconsistency in attribute order and axis derivation?
  5. The IfcShapeRepresentation documentation says Using IfcRepresentationMap is the way to share one representation (often of type IfcShapeRepresentation) by many products., yet it is clearly possible to simply reference the same IfcShapeRepresentation without needing to create a representation map, thus achieving the ability to share the representation. Admittedly, you do lose the ability to perform a cartesian transformation, but that can be applied using the ObjectPlacement assuming the transformation is the same for all representations and you don’t need to apply a scale. I only see real benefits of using this method if you have many small shape representations put together to build up a larger representation. In reality, I don’t see vendors really offering this ability.


In a 3D scenegraph system, each “node” can receive its own transformation. However, in the context of BIM I’d be very careful when introducing scaling somewhere in the transformation tree or stack.

In general having Scale is opening a huge potential for errors and inconsistencies. As witnessed in CAD systems, scale is always giving you additional complexity. Would you have to “scale” the dimensions and quantities too? What about mirroring? Non-uniform scaling? What about face orientation? What about parametric profiles? Scale the profile itself? Scale the path? Scale the length of an extrusion vector? What is the length measure of a column modelled as a 3m extrusion when scaling it 200%?

Yes, I understand that there are many complications as you’ve given examples of.

That said, it would be very nice to support the ability to mirror along an axis. Buildings can get very symmetrical, and this could result in a lot of efficiency in the IFC format. Otherwise, well, it’s twice the IfcRepresentation definitions. Mirroring is easier to tackle than scaling.

I would additionally argue that if scaling is only done at the representation stack, then it does no harm to the BIM data itself. After all, the IfcCartesianTransformationOperator3D already allows you to do scaling (admittedly, it is uniform scaling, but it is still scaling). The BIM data is added at the product level of the stack, and that is up to the vendor to ensure calculations are done properly for things like quantities.

Which buildingSmart group can help discuss opportunities with mirroring further?

I think we should investigate the answer in Grasshopper community and also DynamoBIM, because as I understand, adding scale and mirrors, etc., will cause “parametric” IFC which is one of the bSI goals and also the industry wants it

CC: @berlotti