How can an IfcOffsetCurveByDistances be a 2D curve?

[RickBrice]

Problem
The documentation for IfcAlignment lists supported shape representations including:

IfcOffsetCurveByDistances as a 2D or 3D curve defined relative to an IfcGradientCurve or another IfcOffsetCurveByDistances.

IfcGradientCurve is a 3D curve as stated in https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcGradientCurve.htm.

A three-level chain would look like:
Curve 1: IfcGradientCurve (3D)
Curve 2: IfcOffsetCurveByDistances that is offset from Curve 1 (inherits 3D from Curve 1)
Curve 3: IfcOffsetCurveByDistances that is offset from Curve 2 (inherits 3D from Curve 2)

In this scenario, there is no way that IfcOffsetCurveByDistances can be anything but a 3D curve.

Additionally, the documentation for IfcOffsetCurveByDistances defines the BasisCurve as an IfcCurve. IfcOffsetCurveByDistances does not itself impose any restrictions on the BasisCurve type.

Should the restriction that IfcOffsetCurveByOffsetDistances.BasisCurve be constrained to IfcGradientCurve and IfcOffsetCurveByDistances be stated in the documentation for IfcOffsetCurveByDistances?

Solution(s)
Alternative 1
IfcOffsetCurveByDistances must be 3D.

In IfcAlignment, replace the fourth item in the list of supported shape representations with "IfcOffsetCurveByDistances as a 3D curve defined relative to an IfcGradientCurve or another IfcOffsetCurveByDistances"

In IfcOffsetCurveByDistances revise the first paragraph of 8.9.3.42.1 Semantic definition to start as "An IfcOffsetCurveByDistances is a 3D curve defined by ..." the balance of the sentence is unchanged. Additionally, add a rule that restricts BasisCurve to IfcGradientCurve or IfcOffsetCurveByDistances.

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

• ✓ where rule: a constraint embedded in the IFC schema
• other normative rule: a normative check of the IFC Validation Service. Every IFC file must pass this check
• good practice check: just triggers a warning, but the IFC file is still valid
• don't know

IfcOffsetCurveByDistances.BasisCurve must be an IfcGradientCurve or IfcOffsetCurveByDistances.

Alternative 2
IfcOffsetCurveByDistances can be 2D or 3D.

In IfcAlignment, replace the fourth item in the list of supported shape representations with "IfcOffsetCurveByDistances as a 2D or 3D curve defined relative to an IfcCompositeCurve, IfcGradientCurve or another IfcOffsetCurveByDistances"

Require schema changes?

• yes
• ✓ no
• don't know

Require documentation changes?

• ✓ yes
• no
• don't know

[aothms]

1 And to be clear here (but not really on topic for the question covering 2d vs 3d) are we all agreeing on IfcSegmentedReferenceCurve? An IfcSegmentedReferenceCurve is also an IfcGradientCurve due to inheritance, so they are accepted as a basis for an offset curve.

2 Does there need to be some explicit statement on IfcPointByDistanceExpression.BasisCurve equal to IfcOffsetCurveByDistances.BasisCurve?

3 I would say that an offset curve over solely an horizontal alignment doesn't make as much sense as over the combined curve, in the former case adjusting the segments directly is much more informative I'd say. Also the ability to introduce an OffsetVertical to a 2D curve is maybe somewhat surprising. So I think there is some sense to the intuition of IfcOffsetCurveByDistances being 3D.

Of course take this with a grain of salt given my limited knowledge of the domain.

[RickBrice]

1. IfcSegmentReferenceCurve can use IfcGradientCurve as a basis curve, but it is not inherited from IfcGradientCurve but rather IfcCompositeCurve.
   
2. I think yes - the IfcPointByDistanceExpression defining an offset from a BasisCurve should be tied to the same basis curve.
3. In my experience having parallel offset horizontal curves is a good way to define geometry. An example is a bridge on a curved alignment. Parallel curves can be used to define the plan view location of girder end points and vertical offsets then position the girder vertically. This is more geometric construction rather than representation so it might not be appropriate for IFC. It's just the way I think based on my experiences.

[aothms]

IfcSegmentReferenceCurve can use IfcGradientCurve as a basis curve, but it is not inherited from IfcGradientCurve but rather IfcCompositeCurve.

Thanks. I keep confusing myself on that. That changes the question though, should IfcSegmentReferenceCurve be allowed in addition to IfcGradientCurve?

[RickBrice]

I still struggle to understand IfcSegmentedReferenceCurve. As I understand it, IfcSegmentedReferenceCurve acts as a modifier on IfcGradientCurve adding adjustments to elevation and adds tilt rotation. The cant related change in elevation could be captured in an offset curve, but could the tilt rotation be captured? Does it need to be?

Additionally for (2) IfcPointByDistanceExpression and IfcOffsetCurveByDistances referencing the same BasisCurve, another rule is that an IfcOffsetCurveByDistances.BasisCurve cannot directly or indirectly reference itself as a BasisCurve. No recursion in a chain of offset curves.

[RickBrice]

Looks like I brought this issue up at an earlier date

buildingSMART/IFC4.3.x-development#733

[civilx64]

3. In my experience having parallel offset horizontal curves is a good way to define geometry. An example is a bridge on a curved alignment. Parallel curves can be used to define the plan view location of girder end points and vertical offsets then position the girder vertically. This is more geometric construction rather than representation so it might not be appropriate for IFC. It's just the way I think based on my experiences.

I also agree based on industry experience and this recent FHWA study seems to indicate it as well based on the entities indicated in the cover image. Obviously the final entity names in IFC 4.3 are a little different but it's illustrating the same concept you described.

[RickBrice]

That report is on my reading list. 😀
The image on the cover is the same as IfcSectionedSolidHorizontal. A similar image of just the curves, no bridge, is in IfcOffserCurveByDistances. The curves in these cases are 3D IfcGradientCurve. At any rate, the documentation needs some revision.

[civilx64]

If you are strapped for time I recommend jumping straight to Chapter 6 for a discussion of entity types for geometric modeling as well as data exchanges for structural analysis.

[evandroAlfieri]

@RickBrice @civilx64 @aothms similar question: do you have a suggestion for docs change and/or VS rule, for this issue?

[RickBrice]

I proposed two alternatives in the original post. I prefer alternative 2. I don't think there is a consensus.

[civilx64]

I agree with @RickBrice that alternative 2 - IfcOffsetCurveByDistances can be 2D or 3D - is the better choice. Even if offsetting from IfcGradientCurve you have the attribute BaseCurve which gives you a 2D projection. By extension that would mean that the documentation is ok to remain as-is.

One way to think of it in a programming sense is that you can "cast" a 3D curve to 2D by ignoring the Z dimension.

I can't think of anything that would need to be enforced by a rule in the validation service because the curve would be considered valid regardless if it is 2D or 3D.