IFC4.3.x-development
IFC4.3.x-development copied to clipboard
Default value for IfcAxis2PlacementLinear.Axis is not defined
The default value of IfcAxis2PlacementLinear.Axis is not defined.
Using IfcAxis2Placement3D for inspiration, you could say that the default Axis is (0,0,1).
However, IfcAxis2PlacementLinear.RefDirection, when omitted, is taken from the curve tangent a IfcAxis2PlacementLinear.Location.
IfcAxis2PlacementLinear.Location is an IfcPointByDistanceExpression and the BasisCurve could be any IfcCurve type. In the context of alignments BasisCurve could be IfcCompositeCurve, IfcGradientCurve, or IfcSegmentedReferenceCurve.
For IfcGradientCurve or IfcSegmentedReferenceCurve, IfcAxis2PlacementLinear.Axis could be perpendicular to the curve in the "Distance Along - Elevation" plane. Of course, for IfcCompositeCurve, there is not elevation so (0,0,1) would be the natural default for Axis.
As a concrete example, consider the following taken from the FHWA Bridge Geometry Manual https://www.fhwa.dot.gov/bridge/pubs/hif22034.pdf
Plan View
Profile View
For the following linear placement the position and axes are desired.
#217=IFCGRADIENTCURVE((#144,#152,#160,#168,#176,#184,#192,#200,#208,#216),.F.,#78,$);
#219=IFCPOINTBYDISTANCEEXPRESSION(IFCNONNEGATIVELENGTHMEASURE(4000.),$,$,$,#217);
#220=IFCAXIS2PLACEMENTLINEAR(#219,$,$);
#221=IFCLINEARPLACEMENT($,#220,$);
The position is easy (3688.29,2171.56,115).
From #220
, we see that Axis and RefDirection are omitted. RefDirection defaults to the tangent to the gradient curve [0.22452 0.974418 -0.0099995]. If Axis is derived from the curve it would be [0.0022452 0.00974418 0.99995].
IFC file is attached. FHWA_Bridge_Geometry_Example.ifc.txt
So orthogonalize Axis, based on Ref and a constant Up vector of (0,0,1)?
>>> import numpy as np
>>> ref = [0.22452, 0.974418, -0.0099995]
>>> up = [0,0,1]
>>>
>>> np.cross(ref, np.cross(up, ref))
array([0.00224509, 0.00974369, 0.99989967])
This is exactly how I would understand the intention given my limited understanding of the domain, but makes the naming of the attributes rather unfortunate. We need to add a note that this is factually the opposite of how orthogonalization is implemented for IfcAxis2Placement3D.
Axis The exact direction of the local Z Axis.
RefDirection The direction used to determine the direction of the local X Axis. If necessary an adjustment is made to maintain orthogonality to the Axis direction. If Axis and/or RefDirection is omitted, these directions are taken from the geometric coordinate system.
Here we essentially reverse this and make RefDirection exact and Axis orthogonally derived from RefDirection.
I think we can actually also use the https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcBuildAxes.htm but then reverse the attribute order (is it still right handed then? I would have to check).
If I were to summarize I think we need to:
- Augment documentation
- Provide clear semantics on permutations of existence of the two direction vectors (and possibly constrain, eg for 3d we have a formal prop "Either both, Axis and RefDirection are not given and therefore defaulted, or both shall be given.", edit: see #731)
- Provide derived attribute referencing IfcBuildAxes
Is this something you could introduce in the IF?
@aothms Posted to IF issues https://github.com/buildingSMART/IFC4.x-IF/issues/125