LIP002 - uncertainty regarding default value of IfcAxis2PlacementLinear.Axis (affects calculated cartesian position when IfcPointbyDistanceExpression.OffsetVertical != 0)

[civilx64]

We've received a file that appears to be raising false Warnings for LIP002. The sample file uses four pairs of products (IfcReferent & IfcSignal) where each pair has the same (DistanceAlong, OffsetLateral). At each location, the signal also has an OffsetVertical = 2.5 where the referent has None.

Interestingly, all of the calculated cartesian locations match except for the last location pair. It appears that OffsetVertical for the signal is bleeding into the X, Y coordinate calculations. One possible clue is that this location is being offset from a vertical curve segment of type .CIRCULARARC. More specifically:

Pair	Horizontal Segment Type	Vertical Segment Type	Cant Segment Type
1	LINE	CONSTANTGRADIENT	CONSTANTCANT
2	CLOTHOID	CONSTANTGRADIENT	CONSTANTCANT
3	LINE	CONSTANTGRADIENT	LINEARTRANSITION
4	LINE	CIRCULARARC	CONSTANTCANT

Model screenshot:

Findings:

Both manual and AI-assisted review and troubleshooting have failed to resolve the issue.

[aothms]

I think it might help that I can find these values for you written out by the code. This probably tells us where implementations differs:

diff --git a/src/ifcgeom/mapping/IfcPointByDistanceExpression.cpp b/src/ifcgeom/mapping/IfcPointByDistanceExpression.cpp
index 180226fb8..5dc45a48b 100644
--- a/src/ifcgeom/mapping/IfcPointByDistanceExpression.cpp
+++ b/src/ifcgeom/mapping/IfcPointByDistanceExpression.cpp
@@ -52,6 +52,15 @@ taxonomy::ptr mapping::map_impl(const IfcSchema::IfcPointByDistanceExpression* i
    if (inst->OffsetVertical().has_value()) {
        auto offset_vertical = inst->OffsetVertical().get() * length_unit_;
        o += offset_vertical * z;
+
+       auto tmp1 = (z * offset_vertical).eval();
+       auto tmp2 = (Eigen::Vector3d(0, 0, 1) * offset_vertical).eval();
+       auto tmp3 = (tmp1 - tmp2).eval();
+
+       std::ostringstream oss;
+       oss << tmp3.x() << "," << tmp3.y() << "," << tmp3.z();
+       auto osss = oss.str();
+       std::wcout << osss.c_str() << std::endl;
    }

    if (inst->OffsetLongitudinal().has_value()) {

So in other words if you take our local Z times offset_vertical and compare that with global Z times offset_vertical you have exactly this delta.

-0.0227043,-0.00104331,-0.000103317

So the bleeding of OffsetVertical into the X,Y is caused by the inclination of cant.

Now, the docs are of course beautifully written

Default offset vertical to the basis curve where positive values indicate perpendicular to the tangent at DistanceAlong in the plane of the tangent perpendicular to the global XY plane.

https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcPointByDistanceExpression.htm

"perpendicular to the global XY plane" does that mean along global Z? Because we translate along local Z essentially.

[civilx64]

The model uses IfcGradientCurve as the BasisCurve so my assumption was that cant does not apply. If so, wouldn't it apply to all pairs and we would see coordinate "drift" for each of the four signals - instead of just 1?

[aothms]

Sorry, yes it's late here, updated, not due to cant most likely, just the vertical. For some reason the first three placements are at locations where the gradient curve tangent is in the XY plane?

[aothms]

If you write

       oss << "local z: " << z.x() << "," << z.y() << "," << z.z() << "; delta: " << tmp3.x() << "," << tmp3.y() << "," << tmp3.z();

You get

local z: 0,0,1; delta: 0,0,0
local z: 0,0,1; delta: 0,0,0
local z: 0,0,1; delta: 0,0,0
local z: -0.00908173,-0.000417322,0.999959; delta: -0.0227043,-0.00104331,-0.000103317

[civilx64]

Yes, possibly the others are in locations of flat vertical alignment. I will take a closer look to confirm.

"perpendicular to the global XY plane" does that mean along global Z? Because we translate along local Z essentially

Yes, I would think perpendicular to global XY would be global Z. But if that is the intent, then why not say "Global Z"? (Rhetorical question)

[evandroAlfieri]

Good stuff. If there's a docs fix please capture it.

[civilx64]

For some reason the first three placements are at locations where the gradient curve tangent is in the XY plane?

Indeed the other three placements not raising a warning with LIP002 are relative to vertical curve segments of type CONSTANTGRADIENT with StartGradient = 0. and EndGradient = 0.

[civilx64]

Related: jwouellette/TPF-5_372-Unit_Test_Suite#15

The complicating factor here is uncertainty regarding the default value of Axis (Z direction) when it is not defined as part of a LinearPlacement. However, the purpose of LIP002 is to confirm that:

1. CartesianPosition is provided as a "fallback" to viewing tools that don't support calculation of linear placement
2. The CartesianPosition matches what is calculated based on the attributes of the LinearPlacement.

Digging further yet into the model and looking at the IfcSignal instance that is flagged by the Validation Service, its linear placement does not provide a value for Axis. BUT the CartesianPosition (fallback) DOES provide a value for Axis of #2653=IfcDirection((-0.00908173185456385,-0.000417322497312702,0.999958673140273)). This is perpendicular to local Z at that location on the circular vertical curve, not gloabl Z (0, 0, 1). This means that the corresponding Location.Coordinates must be different than what is provided for the IfcReferent that is at the same position (DistanceAlong, OffsetLateral) but with no OffsetVertical.

The uncertainty regarding default value of Axis still remains, but in terms of the logic of LIP002 we can say that this instance is correctly flagged as a warning since it is internally inconsistent due to (X, Y, Z) coordinates indicating Axis = (0, 0, 1) but the provided Axis being != (0, 0, 1).

[peterrdf]

Hi @aothms, just to understand. In simple words I am calculating vertical offset to be 100% in the global Z direction (this was always my understanding), while it should depend on the tangent (and in case of Cant maybe even rotation arround its own axis) of the curve?

[peterrdf]

Fixed in revision 3217, however I am still not sure if OffsetVertical should not be interpreted as vertical globally,

[aothms]

@evandroAlfieri please put this on the agenda of something IF-like. I think most can live with both options (OffsetVertical along global Z or local Z). Local is a more pure in terms matrix math. Global better matches road design according to Scott and there are some hints for this in the docs.