IfcLinearPlacement with cant - explicit or implicit tilting of sleepers

[evandroAlfieri]

Problem How to export objects (e.g., railway sleepers) placed with IfcLinearPlacement and affected by Cant. Do they automatically tilt, based on the fact that the linear placement refers the Cant curve (i.e., IfcSegmentedReferenceCurve), or should the rotation be explicitly stored in the IFC file - as the object axis?

Solution(s) Wish for the first one but at the moment we had to fallback to the second solution. - @michelangelo-acca

Require schema changes?

• yes
• ✓ no
• don't know

Require documentation changes?

• yes
• no
• ✓ don't know

Rule required Need for a formal rule? Describe it

• 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 See examples and background discussion's recording here

[aothms]

From my naive understanding you have the option to reference CompositeCurve, GradientCurve or SegmentedReferenceCurve in the local placement. If you choose SegmentedReferenceCurve I would expect that cant rotation is applied to the placement. If you don't want that, reference the GradientCurve in your local placement instead.

[peterrdf]

I agree with aothms. Even when IfcSegmentedReferenceCurve is required as super elevation is required it is possible to override the inheritance of tilt from the IfcSegmentedReferenceCurve by defining the normal vector (i.e. overriding automatic calculation).

[michelangelo-acca]

I do agree with both @aothms and @peterrdf, but then during the meeting some other SW representatives said that they would prefer the actual situation (i.e. where the tilt is explicit in the file) because otherwise it is/may be difficult to calculate it on import...

[michelangelo-acca]

Maybe make it implicit and, if and when possible, use the fallback scenario with CartesianPosition could be a solution?

[peterrdf]

Agree, it could be said in the MVD that CartesianPosition should be available. In the future consistency between CartesianPosition and the definition of IfcLinearPlacement could be part of a geometric validation, a similar solution I would see for consistency between business logic and geometry for alignment

[RickBrice]

I agree with @aothms - there are options regarding placement relative to the CompositeCurve, GradientCurve, and SegmentedReferenceCurve.

It seems to me that IfcLinearPlacement.CartesianPosition is a stop-gap measure to ease the burden of supporting IFC4x3. In a perfect world, all implementors would support linear referencing and placement - but in reality, there is a lag. The fallback option helps to bridge the gap. Is there are plan to phase out (depreciate) the .CartesianPosition attribute in IFC4x4 or 5 schema after implementors have had sufficient time to address the new alignment based elements of the schema?

[peterrdf]

In my perception such attributes will not be phased out and also should not be phased out. We see such derived knowledge to ease the burdon of implementation more often, for example the IfcSurfaceCurve that in principle does not require a Curve3D representation if everybody implemented IfcPCurve.

The Model View Definitions should be the technology / content to decide when an what to expect from implementors concerning implementation requirements. In this light I also liked the 1, 2, 3 stars proposal from Leon allowing on schema level already knowledge on complexity level of a concept (geometrical entity), for example if alignments would be a 3 star geometry concept it makes sense (and is technically explanable) to define a CartesianPosition. Now it looks like a bit of an arbitrary choice to create such a fall-back here (and in IfcSurfaceCurve) and not in other complex cases.