IfcLinearPlacement.PlacementRelTo needs clarification

[RickBrice]

Problem
IfcLinearPlacement.PlacementRelTo only makes sense under certain conditions.

Placement is constrained to a curve so IfcLinearPlacement.PlacementRelTo should be constrained to be an IfcLinearPlacement. I don't see how a placement can be constrained to a curve and simultaneously relative to an arbitrary placement. The only exception would be if the IfcLinearPlacement.PlacementRelTo is the exact same IfcLocalPlacement as used to place the alignment curve.

Example E.2.2 - Linear Placement of Signal uses a deeply nested sequence of placements for IfcLinearPlacement, but they all end up being relative to (0,0,0) Axis (0,0,1), RefDirection (1,0,0) which basically is the same as IfcLinearPlacement.PlacementRelTo = null. Placement would not make sense if each IfcLocalPlacement.Location was a different IfcCartesianPoint because that would break the constraint to the context of the curve.

Snippet of IfcLinearPlacement for Linear Placement of Signal example.

#2702 = IFCLINEARPLACEMENT(#2279, #2703, $);
#2279 = IFCLOCALPLACEMENT(#2274, #2282);
#2280 = IFCDIRECTION((0., 0., 1.));
#2281 = IFCDIRECTION((1., 0., 0.));
#2282 = IFCAXIS2PLACEMENT3D(#15, #2280, #2281);
#2274 = IFCLOCALPLACEMENT(#2269, #2277);
#2275 = IFCDIRECTION((0., 0., 1.));
#2276 = IFCDIRECTION((1., 0., 0.));
#2277 = IFCAXIS2PLACEMENT3D(#15, #2275, #2276);
#2269 = IFCLOCALPLACEMENT($, #2272);
#2270 = IFCDIRECTION((0., 0., 1.));
#2271 = IFCDIRECTION((1., 0., 0.));
#2272 = IFCAXIS2PLACEMENT3D(#15, #2270, #2271);
#15 = IFCCARTESIANPOINT((0., 0., 0.));

Not only should IfcLinearPlacement.PlacementRelTo be constrained to an IfcLinearPlacement, both linear placements should be constrained to the same basis curve. That is both placements' IfcLinearPlacement.RelativePlacement.Location.BasisCurve need to be the same curve. This allows to easily layout placement at a uniform spacing along an alignment by using the same IfcAxis2PlacementLinear or IfcPointByDistanceExpression in each IfcLinearPlacement.RelativePlacement.Location.

In the following example, #999 is a curve. #100 is placement 50.0 from the start of that curve, #110 is 50.0 from #100 and #120 is 50.0 from #110 ... and so on

#100 = IFCLINEARPLACEMENT($,#101,$)
#101 = IFCAXIS2PLACEMENTLINEAR(#102,$,$)
#102 = IFCPOINTBYDISTANCEEXPRESSION(IFCLENGTHMEASURE(50.0),0,0,0,#999)

#110 = IFCLINEARPLACEMENT(#100,#101,$)
#120 = IFCLINEARPLACEMENT(#110,#101,$)

This then brings up another question that is not clear in the specification. How are the Axis and RefDirection from each IfcAxis2PlacementLinear in the sequence of IfcLinearPlacement combined. For the example above, #101 uses the default values for Axis and RefDirection (which are not well defined, see #125) at multiple locations along the curve.

Should the 4x4 placement matrices be multiplied together as would be the case for a sequence of IfcLocalPlacements? In my experience with infrastructure, this isn't particularly useful. Items are typically placed relative to a point on a curve using the plan-view curve tangent and normal vectors at that point.

Is a rule needed (or clarifying documentation) that says the Axis and RefDirection are based on curve at the IfcLinearPlacement.RelativePlacement.Location and not combined with the IfcLinearPlacement.PlacementRelTo.RelativePlacement.Location?

Solution(s)
Develop clear examples of valid relative linear placement cases.
Document constraints (can only be relative to another IfcLinearPlacement using the same BasisCurve)
Document treatment of Axis and RefDirection if it differs from IfcLocalPlacement

Require schema changes?

• yes
• ✓ no
• don't know

Require documentation changes?

• yes
• no
• ✓ don't know

Rule required
IfcLinearPlacement can only be relative to another IfcLinearPlacement using the same BasisCurve

• ✓ normative check: every IFC file must pass this check
• good practice check: just triggers a warning, but the IFC file is still valid
• don't know

Additional context
@aothms @civilx64 @evandroAlfieri @peterrdf
Thoughts?

[RickBrice]

I think CT 4.1.7.4.2 addresses the requirements for an IfcLocalPlacement used for IfcLinearPlacement.PlacementRelTo. Though the Linear Placement of Signal example uses multiple levels of IfcLocalPlacement.PlacementRelTo while the CT only shows one.

[SergejMuhic]

Please read the documentation in Product Linear Placement. The IfcLinearPositioningElement is the georeferenced element of which the ObjectPlacement attribute places it. This local placement is supposed to be referenced by all IfcLinearPlacement along the alignment.

[RickBrice]

@SergejMuhic Thank you, I missed that subtle detail on the Product Linear Placement concept template - a rookie mistake.

If I understand correctly, the IfcLinearPositionElement.ObjectPlacement refers to the exact same IfcLocalPlacement as the IfcLinearPlacement.PlacementRelTo.

The requirement on IfcLinearPlacement.PlacementRelTo be an IfcLocalPlacement by Product Linear Placement documentation eliminates the possibility of relative placements along an alignment. Is that intended? Relative linear placement is very useful. If you want to layout bridge piers, Pier 1 can be defined at some distance from the start of the alignment and all subsequent piers could be defined at some distance from the previous pier (via IfcLinearPlacement.PlacementRelTo = IfcLinearPlacement of previous).

In the IF meeting last week @peterrdf was saying implementers should support relative linear placement. How is that accomplished if it can't be done with IfcLinearPlacement.PlacementRelTo?

[SergejMuhic]

If I understand correctly, the IfcLinearPositionElement.ObjectPlacement refers to the exact same IfcLocalPlacement as the IfcLinearPlacement.PlacementRelTo.

Precisely.

The requirement on IfcLinearPlacement.PlacementRelTo be an IfcLocalPlacement by Product Linear Placement documentation eliminates the possibility of relative placements along an alignment. Is that intended?

Correct again. The intention was to not allow relative linear placements. Facilitating all the relations between entities would be quite complex between IfcPointByDistanceExpression.DistanceAlong and BasisCurve also stationing etc. Deriving stations from absolute measurement data remains quite easy (see Product Relative Positioning) but from a data modelling point of view the data structures would be complex.

There is also the concept of measuring along curves in IfcGeometryResource Parameterization of analytic curves and surfaces. At that layer, the important layer 😄 , the placements are always in a particular context i. e. coordinate system. What would it mean if an IfcAxis2PlacementLinear would be in the context of another IfcAxis2PlacementLinear. In order to keep the relativity to the BasisCurve concessions have to be made. It was a strong requirement (hence the introduction of IfcAxis2PlacementLinear and IfcPointByDistanceExpression) to keep the relation to the curve for placement. Otherwise (would have been my preference), IfcAxis2Placement3D and IfcPointOnCurve could have been used.

So, if we eventually see a curvature continuous C2 alignment that can produce parametric sweeps, we have to stick to these local well defined concepts. In the resource layer we do not get any benefits from relative placement, just complexity.

For relative positioning the above linked concept template (Product Relative Positioning) should be used.

[evandroAlfieri]

@aothms @RickBrice would the rule in our backlog here close this issue or there's a need for a separate rule?