Towards a common understanding of IfcLinearPlacement, IfcAxis2PlacementLinear, IfcPointByDistanceExpression, IfcOffsetCurveByDistances, IfcSectionedSurface, and IfcSectionedSolidHorizontal

[RickBrice]

This issue consolidates discussions regarding IfcLinearPlacement, IfcAxis2PlacementLinear, and IfcPointByDistanceExpression in
buildingSMART/IFC4.x-IF#169
buildingSMART/ifc-gherkin-rules#506
buildingSMART/IFC4.x-IF#125
#732
#731
jwouellette/TPF-5_372-Unit_Test_Suite#15 (comment)

It also brings IfcOffsetCurveByDistances, IfcSectionedSurface and IfcSectionedSolidHorizontal into the discussion, with issues raised in https://github.com/RickBrice/IFC-Alignment-Geometry-Implementation-Guide/blob/main/5_OffsetCurves.md, https://github.com/RickBrice/IFC-Alignment-Geometry-Implementation-Guide/blob/main/8_LinearPlacement.md, and https://github.com/RickBrice/IFC-Alignment-Geometry-Implementation-Guide/blob/main/10_Sectioned_Surfaces_and_Solids.md.

IfcLinearPlacement, IfcAxis2PlacementLinear, IfcPointByDistanceExpression, IfcOffsetCurveByDistances, IfcSectionedSurface, and IfcSectionedSolidHorizontal all work together in many complex ways. A holistic discussion is needed.

To facilitate that discussion, @michelangelo-acca has developed a simple example. The example covers the following scenarios:

1 - User wants to place a sleeper along a track with cant

	- Parameters:
	
		- DistanceAlong 200
		- OffsetLateral 0
		- OffsetVertical 0
		- Rotation 0

	- The good:

		- The "tilt" is calculated automatically on import and not written in the file
	
	- The bad:
	
		- If the alignment changes, the sleeper correctly positions in its new place, but if fallback coordinates were originally written, they should be overridden with new ones 
	
2 - User wants to place a "vertical" object (i.e. a Sign) along the alignment

	- Parameters:
	
		- DistanceAlong 201
		- OffsetLateral 2
		- OffsetVertical 2.5
		- Rotation 0
		
	- The good:
	
		- We can override local Z axis to make global Z for making the object not be inclined by the slope at that point of the alignment
		
	- The bad:
	
		- In order to have a truly vertical OffsetVertical, we need to put 0 there, and the 2.5 in a LocalPlacement relative to the LinearPlacement, so the user will not see its 2.5 in the UI in correspondence of OffsetVertical
		
3 - User wants to place a rotated "vertical" object (i.e. a Sign) along the alignment	

	- Parameters:
	
		- DistanceAlong 202
		- OffsetLateral 2
		- OffsetVertical 2.5
		- Rotation 45
		
	- The good:
	
		- Same as previous case
		
	- The bad:
	
		- Same as previous case

Reference image

Scenarios 2 and 3 are common. The IFC coding of Michaelangelo's solution is not (in my opinion) obvious or convenient. I've added two additional scenarios, 4 and 5 which are the same as 2 and 3 except that (a) the signs are on the right side of the alignment and (b) the local placement with z=2.5 is not used because the vertical offset is handled in the point by distance expression.

4 - User wants to place a "vertical" object (i.e. a Sign) along the alignment

	- Parameters:
	
		- DistanceAlong 201
		- OffsetLateral -2
		- OffsetVertical 2.5
		- Rotation 0
		
	- The good:
	
		- We can directly specify the lateral and vertical offset in IfcPointByDistanceExpression consistent with common civil engineering thinking.
		
	- The bad:
	
		- Validation Service and several implementations do not evaluate OffsetVertical in the global Z direction.
		
5 - User wants to place a rotated "vertical" object (i.e. a Sign) along the alignment	

	- Parameters:
	
		- DistanceAlong 202
		- OffsetLateral -2
		- OffsetVertical 2.5
		- Rotation 45
		
	- The good:
	
		- Same as previous case
		
	- The bad:
	
		- Same as previous case

The example model
UTAlignmentSimpleSlope_Modified.zip

From my background in highway and bridge engineering, I would instinctively locate the sign relative to the gradient curve with

#15296 = IFCSIGNAL('3S_c_fxJD5UuVShHH7YMXt', #1, 'a vertical sign (right)', $, $, #15297, #15306, $, .VISUAL.);
#15297 = IFCLINEARPLACEMENT($, #15303, #15351);
#15303 = IFCAXIS2PLACEMENTLINEAR(#15304, #15305, $);
#15304 = IFCPOINTBYDISTANCEEXPRESSION(IFCLENGTHMEASURE(201.), -2., 2.5, 0., #5208); /* REQUIRES OffsetVertical TO BE GLOBAL-Z DIRECTION */
#15305 = IFCDIRECTION((0., 0., 1.)); /* Forces the orientation of the placed sign to be vertical */
#15306 = IFCPRODUCTDEFINITIONSHAPE($, $, (#15312));
#15307 = IFCMAPPEDITEM(#4073, #15308);
#15308 = IFCCARTESIANTRANSFORMATIONOPERATOR3DNONUNIFORM(#15309, #15310, #15, 1., #15311, 1., 1.);
#15309 = IFCDIRECTION((1., 0., 0.));
#15310 = IFCDIRECTION((0., 1., 0.));
#15311 = IFCDIRECTION((0., 0., 1.));
#15312 = IFCSHAPEREPRESENTATION(#17, 'Body', 'MappedRepresentation', (#15307));
#15351 = IFCAXIS2PLACEMENT3D(#15352, #15353, #15354); /* FALLBACK POSITION IS EXPECTED VALUE */
#15352 = IFCCARTESIANPOINT((201., -2., 52.75));
#15353 = IFCDIRECTION((0., 0., 1.));
#15354 = IFCDIRECTION((1., 0., 0.));

In my mind, I see that as:

Measure 201. along the projection of the gradient curve onto the horizontal plane
Measure 2.0 to the left (or -2.0 to the right), normal to the projection of the gradient curve onto the horizontal plane
Measure 2.5 up in the global Z direction from the gradient curve.
I want the sign to be vertical, so I explicitly set the Axis to (0,0,1)

NOTE: The current implementation of Blender/Bonsai with IfcOpenShell and usBIM.browser resolve the scenario 4 sign position to (200.39, -2, 52.675) instead of the desired (201., -2., 52.75). The Validation Service uses IfcOpenShell on the backend and flags the fallback position as an error since it computes the position as (200.39, -2, 52.675). These implementations are based on a contested interpretation of IfcPointByDistanceExpression.OffsetVertical. These implementations have chosen to treat OffsetVertical as local Z instead of global Z.

Before we can go further, there needs to be a consensus agreement on the direction of OffsetVertical

I propose the following to be the accepted interpretation for IfcLinearPlacement, IfcAxis2PlacementLinear, IfcPointByDistanceExpression, IfcOffsetCurveByDistances, IfcSectionedSurface.CrossSectionPositions, and IfcSectionedSolidHorizontal.CrossSectionPositions:

1. IfcPointByDistanceExpression.DistanceAlong is a curvilinear distance measured along the projection of IfcCompositeCurve (or its subclasses IfcGradientCurve and IfcSegmentedReferenceCurve) onto the global XY plane. (e.g. distance along the alignment curve in plan view)
2. IfcPointByDistanceExpression.OffsetLateral is an offset normal to the basis curve at DistanceAlong in a plane that is parallel to the global XY plane (e.g. measured normal to the plan view of the basis curve at DistanceAlong)
3. IfcPointByDistanceExpression.OffsetVertical is an offset from the basis curve in the global Z direction. (e.g. as viewed in a "DistanceAlong,Elevation" profile view of the basis curve, the vertical offset is up or down in the "Elevation" direction and not affected by the slope of the basis curve at that point.
4. IfcPointByDistanceExpression.OffsetLongitudinal is an offset in the plan view tangent direction from the point established by DistanceAlong, OffsetLateral and OffsetVertical.
5. The default IfcAxis2PlacementLinear.Axis is perpendicular to the basis curve (e.g. the local Z direction). IfcAxis2PlacementLinear.Axis = CurveTangent.Cross(Y) where Y = Z.Cross(CurveTangent), Z = (0,0,1) and CurveTangent is the vector that is tangent to the 3D basis curve at Location.DistanceAlong. CurveTangent rather than RefDirection is purposefully used to establish the default Axis direction - In all other IfcAxis2PlacementXXX, the Axis direction is the dominate factor and not influenced by RefDirection - For other IfcAxis2PlacementXXX, RefDirection and Axis establish Y then Axis and Y establish X if RefDirection is not orthogonal. The same semantics should apply to IfcAxis2PlacementLinear. IfcAxis2PlacementLinear is the only IfcAxis2PlacementXXX that does not require either both or neither Axis and RefDirection defined. If only IfcAxis2PlacementLinear.RefDirection is defined, it does not define IfcAxis2PlacementLinear.Axis.
6. The default IfcAxis2PlacementLinear.RefDirection is the vector that is tangent to the 3D basis curve at Location.DistanceAlong. This is the same as CurveTangent. This interpretation of default IfcAxis2PlacementLinear.Axis and .RefDirection allows for an object to be place and automatically get cant slope rotation as in Scenario 1 in the example above and also for IfcSectionedSurface and IfcSectionedSolidHorizontal as discussed in https://github.com/RickBrice/IFC-Alignment-Geometry-Implementation-Guide/blob/main/10_Sectioned_Surfaces_and_Solids.md#10611-minimal-definition and https://github.com/RickBrice/IFC-Alignment-Geometry-Implementation-Guide/blob/main/10_Sectioned_Surfaces_and_Solids.md#10621-minimal-definition, respectively
7. IfcLinearPlacement.PlacementRelTo should typically be omitted (or required to be omitted). The purpose of IfcLinearPlacement is to place something relative to a curve, not to define a placement relative to the start of a curve and then treat it as a delta placement relative to another placement. This is what is being done in Scenarios 2 and 3.
8. IfcOffsetCurveByDistances.OffsetValues with IfcPointByDistanceExpression.OffsetLateral/OffsetVertical as defined above would be consistent with traditional engineering analysis. Lateral is in a horizontal plane, vertical is in the direction of Elevation.
9. IfcSectionedSurface.CrossSectionPositions and IfcSectionSolidHorizontal.CrossSectionPositions must use an explicit IfcAxis2PlacementLinear.Axis = (0,0,1) when the plane of the cross section is to be vertical, such as in the case of a roadway layer cross section or a retaining wall cross section. Otherwise, the orientation of the cross-section plane will rotate with the gradient and cross slope (in the case of cant) along the length of the basis curve.

[RickBrice]

@evandroAlfieri a posting as promised. Let the discussion continue.

[michelangelo-acca]

Thanks @RickBrice for taking the time to analyze all of that and come with such a concrete proposal to make the standard better and less ambiguous, we will be more than happy to change the way we both import and export the IFC Linear Placement concept to comply with that.

Also, since it seems all documentation improvements / changes, should be something that can be accepted by the IF I guess.

Let's see also what others think about but we are definitely in favour of this. If you think more corner cases examples are needed to clarify even further, for this but also for other topics, we can produce them, we kept the first example simple just to get started with a common understanding.

[RickBrice]

I went back to the two sources that actually define OffsetVertical to settle whether current implementations are non-conformant.

The original IFC Alignment 1.1 proposal defines offsetVertical as an offset measure in the local up direction (normal to the alignment) (Liebich et al., 2017, IFC Alignment 1.1 Project: IFC Schema Extension Proposal: https://syncandshare.lrz.de/download/MktrQlVFTm1CTHBLS3lNcW5MQVdz/IFC%20Rail%2BRoad/2017-05-05_IfcRail&Road/bSI%20Summit%20Barcelona%20-%20Infrastructure%20Room/Documentation/IFC%20Alignment%201.1/IfcAlignment_ConceptualModel_20171017.pdf?inline). That's local to the alignment, not global Z.

IfcPointByDistanceExpression came out of the later critical-analysis paper, which kept the same convention while fixing the tangent-discontinuity problem in the original IfcDistanceExpression: offsets are clearly defined relative to the tangent of the curve at the location specified (Jaud et al., 2021, A critical analysis of linear placement in IFC models: https://mediatum.ub.tum.de/doc/1619740/jiqnwxmgyqf6p525e1ne0pdq6.2021_Jaud_etal_ECPPM.pdf).

Neither source defines OffsetVertical as global Z. Based on that, I don't think Blender/Bonsai + IfcOpenShell, usBIM.browser, or the Validation Service are wrong here — they're implementing what's actually written.

Figure 1 shows this reading: OffsetVertical perpendicular to the tangent T, in the vertical plane containing T. OffsetLongitudinal is along T itself. It's the mathematically consistent construction — Lateral, Vertical, and Longitudinal stay mutually orthogonal at every station, including through grade and cant. It's just not what a civil engineer means by "vertical offset."

Figure 1

Figure 2 shows the proposed alternative: OffsetVertical as plain global Z. Elevation stays elevation regardless of grade — the interpretation the sleeper/sign example above argues for. But global Z is not orthogonal to the full 3D tangent T once there's grade (T picks up a z-component), so OffsetLongitudinal can't stay defined as T here without breaking orthogonality. Figure 2 instead defines OffsetLongitudinal as the horizontal projection of T — call it T_h. T_h, Lateral, and global Z form the same kind of orthogonal triad that T, Lateral, and Figure 1's tangent-relative vertical do; it's just built from different vectors. Practically, this means Longitudinal offsets under this proposal move along the horizontal alignment only, with grade handled entirely by the Vertical offset.

Figure 2

So: OffsetVertical's current direction is probably not the right answer for civil engineering work, but as far as what the spec text says today, this looks resolved rather than open — both papers point the same direction, and current tooling matches them.

The default Axis and RefDirection of IfcAxis2PlacementLinear should come from the curve tangent as described in proposed items 5 and 6 in my posting above. Cant/slope rotation happens automatically (Scenario 1) without every consumer reimplementing it. I think this is mostly resolved from buildingSMART/IFC4.x-IF#125 and #732.

The spec documentation itself would be easier to implement against with something like Figure 1 next to the IfcPointByDistanceExpression definition. The text is correct, but it's dense enough that a diagram of the tangent-relative construction would save the next implementer some time. Also maybe a similar figure for IfcAxis2PlacementLinear. I will propose something next week. This is a holiday weekend and I should not be working :)

[SergejMuhic]

IfcPointByDistanceExpression was introduced to comply with ISO 19148. The definition is basically the same and sets the CRS. "For each vector offset distance expression, a CRS shall be specified or else the CRS of the expression's linear element is used. Offset referents are not supported with vector offsets." Otherwise, I would have used IfcPointOnCurve. This is not rocket science and was debated and agreed with OGC and this is how it is documented.

IfcSectionedSolidHorizontal handles a global vertical offset for creating infra type design data with an explicit Axis2Placement. The default CRS comes from IfcPointByDistanceExpression. It is an implementation of vector offset since by default we are in a 3D environment and to avoid ambiguity we agree on only having this implementation.

You can start changing ISO standards of course. But not only do we (IMHO) have a common understanding among the deployment project participants but also aligned with the OGC liaison:
https://docs.ogc.org/is/16-100r2/16-100r2.html#LinearElement

"bSI introduced a way of specifying vector offset distance expressions without the need for the OGC Abstract Specification Topic 19 Vector Offset Requirements Class. An optional, longitudinal offset of type double (units defined by the LRM, positive direction in the direction of the linear element, bearing tangential to the linear element at the distance along point) has been added. Together with lateral and vertical offsets, this provides the same functionality as the vector offset without the added complexity. A new subtype of gmllro:LateralOffsetDistanceExpressionType called OffsetsDistanceExpression is added which extends it to include this optional longitudinal offset value."

IfcPointByDistanceExpression came out of the later critical-analysis paper

No, it came from Release Candidtate 1 to 2. This was part of the projects, finding a consensus between the Rail and Road definitions of alignment and a common understanding of ISO 19148. https://bsi-infraroom.github.io/IFC-Documentation-Tunnel/4_4_0_0/general/HTML/link/ifc4x3_rc1-to-ifc4x3_rc2-changelog.htm

[SergejMuhic]

As for IfcAxis2PlacementLinear, it takes the default CRS. If you want the global Z vertical behaviour (Figure 2), it is very simple to achieve:

#1=IFCAXIS2PLACEMENTLINEAR(#2,#3,$);
#2=IFCPOINTBYDISTANCEEXPRESSION(...);
#3=IFCDIRECTION((0,0,1));

I have intentionally not used the AxisAndRefDirProvision rule so that only Axis can be given. Come to think of it, I should have introduced a rule that allows Axis and no RefDirection, but not the other way around since Axis sets the exact Z direction but RefDirection does not set the exact X.
Figure 1 is even simpler:

#1=IFCAXIS2PLACEMENTLINEAR(#2,$,$);
#2=IFCPOINTBYDISTANCEEXPRESSION(...);

[michelangelo-acca]

As for IfcAxis2PlacementLinear, it takes the default CRS. If you want the global Z vertical behaviour (Figure 2), it is very simple to achieve:

#1=IFCAXIS2PLACEMENTLINEAR(#2,#3,$);
#2=IFCPOINTBYDISTANCEEXPRESSION(...);
#3=IFCDIRECTION((0,0,1));

Thanks @SergejMuhic for the clarifications. I have a question from an implementer point of view:

• when we set the IfcAxis2PlacementLinear Axis to 0,0,1, and omit RefDirection (like in your example), then the IfcPointByDistanceExpression OffsetVertical, is calculated along the Axis (i.e. 0,0,1, aka global, in this scenario) or still depends on the Alignment curve at that point? I think this still needs clarification (or at least I did not understand the answer).

[RickBrice]

This is not rocket science

Agreed - so we aim to make the documentation clear and easy to implement against

IfcSectionedSolidHorizontal handles a global vertical offset for creating infra type design data with an explicit Axis2Placement.

Agreed - though there are some professional classes being taught in the marketplace that claim the cross section is always vertical. This is bringing confusion. Documentation errors as explained in buildingSMART/IFC4.x-IF#147 aren't helping either.

You can start changing ISO standards of course.

Changing ISO standards is not the objective. We aim to make the documentation clear and easy to implement against

But not only do we (IMHO) have a common understanding among the deployment project participants but also aligned with the OGC liaison:

The common understanding must be consistent among all implementers, not just deployment project participants. There seems to be an implicit requirement of having deep knowledge of how the specifications were developed. What is clear to those intimately familiar with the subject is not necessarily clear to newcomers.

No, it came from Release Candidate 1 to 2.

Thanks for the clarification. I should have dug deeper.

[civilx64]

As for IfcAxis2PlacementLinear, it takes the default CRS.

But this is not present in the 4.3 documentation - which is the root of much of this uncertainty for implementers. As Rick and others have noted, one could rightfully assume that the default for Axis is (0., 0., 1.) similar to IfcAxis2Placement3D. So a logical first step towards common understanding is a PR to add this clarification to IfcAxis2PlacementLinear - which is already underway via #1118 but not yet merged due to other uncertainties regarding OffsetVertical, OffsetLateral, OffsetLongitudinal as noted in #1143.

I propose that we merge #1118 as-is to establish that default Axis is tangent to the BasisCurve and not (0., 0., 1.), then move on to address #1143 in another PR. It will be more efficient to gather and document consensus via multiple small bites of the apple versus a one-shot attempt that addresses all permutations and open questions.

[RickBrice]

The IfcPointByDistanceExpression offsets are independent of IfcAxis2PlacementLinear. IfcPointByDistanceExpression.OffsetLateral/Vertical/Longitudinal establish a point in space relative to an IfcCurve. It does not define a full CRS. To establish that point, we need to know in which direction to measure OffsetLateral/Vertical/Longitudinal. As far as I can tell from Sergej's input above and a reading of ISO 19418, the offsets are measured in the local CRS of the IfcCurve at DistanceAlong. That is what is intended. I think this answers Michelangelo's question. IfcPointByDistanceExpression.OffsetLateral/Vertical/Longitudinal are always measured in the local CRS of IfcCurve at DistanceAlong, independent of IfcAxis2LinearPlacement.Axis/RefDirection.

Once the point is established, we then need coordinate directions to form a CRS. This is what IfcAxis2PlacementLinear.Axis/RefDirection gives us. The default Axis and RefDirection appear to be in the local CRS of the IfcCurve at DistanceAlong. This part is covered nicely by #1118.

IfcPointByDistanceExpression needs some work. Some of the issues are:

1. "The offsets default to the initial context of the curve relative to its tangent either specified in IfcProduct.Placement or in the case of a segment curve to the IfcCurveSegment StartPlacement"... Where is the initial context, at the start of the curve? - Start of the curve would not be consistent with what's defined above. There is no IfcProduct.Placement or IfcCurveSegment.StartPlacement.
2. If the offsets default to the context of the curve, what is "no default". Is there a way to explicitly define alternative methods of how offsets are defined?
3. We are generally thinking of "DistanceAlong" the basis curve as the curvilinear distance measured along the projection of the 3D curve onto the 2D global XY plane. This has an inherent assumption that basis curve is IfcCompositeCurve, IfcGradientCurve or IfcSegmentedReferenceCurve. However, IfcPointByDistanceExpression.BasisCurve is defined to be an IfcCurve. What is the correct "DistanceAlong" if BasisCurve is IfcPolynomialCurve, IfcOffsetCurve subtype, IfcSurfaceCurve or any of the other subclasses of IfcCurve? Since IfcPointByDistanceExpression was introduced for road and rail alignments, perhaps the type of IfcPointByDistanceExpression.BasisCurve should be changed or constrained.

#1148 attempts to provide some clarification for IfcPointByDistanceExpression. I think this PR needs some work, but it is offered as a start to address the issues above.

[civilx64]

Since IfcPointByDistanceExpression was introduced for road and rail alignments, perhaps the type of IfcPointByDistanceExpression.BasisCurve should be changed or constrained.

Agree and have added this as a suggestion on #1148.

[michelangelo-acca]

The IfcPointByDistanceExpression offsets are independent of IfcAxis2PlacementLinear. IfcPointByDistanceExpression.OffsetLateral/Vertical/Longitudinal establish a point in space relative to an IfcCurve. It does not define a full CRS. To establish that point, we need to know in which direction to measure OffsetLateral/Vertical/Longitudinal. As far as I can tell from Sergej's input above and a reading of ISO 19418, the offsets are measured in the local CRS of the IfcCurve at DistanceAlong. That is what is intended. I think this answers Michelangelo's question. IfcPointByDistanceExpression.OffsetLateral/Vertical/Longitudinal are always measured in the local CRS of IfcCurve at DistanceAlong, independent of IfcAxis2LinearPlacement.Axis/RefDirection.

Thanks for the clarification. To my understanding, this means that while its not the answer we were hoping for (because of the implications on end users, i.e. they will not see their "engineering" vertical offset in the VerticalOffset attribute of the LinearPlacement), the provided example is "correct", and we have to rely on a LinearPlacement relative to a LocalPlacement in which we express the truly vertical offset. At least now we have clarified this I guess...

another way could be the one suggested from @RickBrice with the use of the Horizontal Curve as BasisCurve and the VerticalOffset as quote of alignment at that point + user input...something we can try and provide examples

[RickBrice]

@michelangelo-acca

something we can try and provide examples

From your original example, made the following changes:

#5297 = IFCLINEARPLACEMENT(#5298, #5303, #5351); // Relative to local placement with Z = 2.5
#5297 = IFCLINEARPLACEMENT($, #5303, #5351); // No longer relative to local placement

#5304 = IFCPOINTBYDISTANCEEXPRESSION(IFCLENGTHMEASURE(201.), 2., $, 0., #5208); // BasisCurve = IfcGradientCurve
#5304 = IFCPOINTBYDISTANCEEXPRESSION(IFCLENGTHMEASURE(201.), 2., 52.75, 0., #5181); // BasisCurve = IfcCompositeCurve and OffsetVertical = 52.75, the desired elevation of the sign

This is consistent a with typically civil engineering (Station, Offset, Elevation) mind-set.

[SergejMuhic]

• when we set the IfcAxis2PlacementLinear Axis to 0,0,1, and omit RefDirection (like in your example), then the IfcPointByDistanceExpression OffsetVertical, is calculated along the Axis (i.e. 0,0,1, aka global, in this scenario) or still depends on the Alignment curve at that point? I think this still needs clarification (or at least I did not understand the answer).

@michelangelo-acca The intent was to have, similarly to how IfcAxis2Placement3D has an agreement on Axis=null and RefDirection=null, to have IfcAxis2PlacementLinear a default direction setting but (hence the specificity of IfcAxis2PlacementLinear, otherwise we could use IfcAxis2Placement3D - LocationIsCP rule was introduced to make a clear distinction). I agree, this is not very well documented because the project were abruptly closed and bSI TD took over, so don't shot the messenger (please).

Prologue done, now to actually answer your question. 😄 As soon as you set the exact direction, you are in the PlacementRelTo context:
https://bsi-infraroom.github.io/IFC-Documentation-Tunnel/4_4_0_0/general/HTML/index-new.htm#schema%2Ftemplates%2Fproduct-linear-placement.htm
meaning, your IfcAlignment.ObjectPlacement kicks in and 0,0,1 is in the context of the IfcAlignment placement which is Z in the projected coordinate system.