IFCPolynomialCurve is missing a clear definition

[Tgest]

I think we should provide a short definition of a polynomial curve in IFC beyond Polynomial Curve.

How should the coefficients be applied? should it be: IFCPOLYNOMIALCURVE([#], (0.0,1.0,3.14), [y], [z]) -> 0.0*x^0 + 1.0*x^1 + 3.14*x^2, y's, z's which seems like to most logical

Should we assume any missing degree is 0? As expressed in a question from the forum:

e.g. #7= IFCPOLYNOMIALCURVE(#4, (0.0,1.0), (0.0,0.0,-1.08943564E-04), $);

Does this mean that when the number of elements in the lists is different then all lacking coefficients in the lesser list are equal to zero (in my example third element of the 'CoefficientX list)?

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

[RickBrice]

A proposal to improve the documentation of IfcPolynomialCurve and correct what appears to be an incorrect FP and WHERE rule.

8.9.3.52.1 Semantic definition The IfcPolynomialCurve is an unbounded curve expressed in the form

$$ \lambda(u) = ((CoefficientsX[0] + CoefficientsX[1] u + CoefficientsX[2] u^2 + ... + CoefficientsX[n-1]u^{n-1} + CoefficientsX[n] u^n)x, (CoefficientsY[0] + CoefficientsY[1] u + CoefficientsY[2] u^2 + ... + CoefficientsY[n-1]u^{n-1} + CoefficientsY[n] u^n)y, CoefficientsZ[0] + CoefficientsZ[1] u + CoefficientsZ[2] u^2 + ... + CoefficientsZ[n-1]u^{n-1} + CoefficientsZ[n] u^n)z)$$

where n is a non-negative integer.

This curve type is primarly used for parabolic transitions in an alignment vertical profile.

8.9.3.52.3 Attributes

#	Attribute	Type	Description
1	Position	IfcPlacement	Defines the location and orientation of the curve
2	CoefficientsX	OPTIONAL LIST [2:?] OF IfcReal	Coefficents defining the X ordinate of the curve
3	CoefficientsY	OPTIONAL LIST [2:?] OF IfcReal	Coefficents defining the Y ordinate of the curve
4	CoefficientsZ	OPTIONAL LIST [2:?] OF IfcReal	Coefficents defining the Z ordinate of the curve

8.9.3.52.4 Formal propositions

Name	Description
CorrectPositionDim	For a 2D curve, CoefficientsZ shall not be used
((Position.Dim=2) AND (NOT EXISTS(COefficientsZ))) OR (Position.Dim=3)
ValidCoefficients	Coefficients must be X and Y, X and Z, Y and Z or X, Y, and Z
(EXISTS(CoefficientsX) AND EXISTS(CoefficientsY)) OR (EXISTS(CoefficientsX) AND EXISTS(CoefficientsZ)) OR (EXISTS(CoefficientsY) AND EXISTS(CoefficientsZ)) OR (EXISTS(CoefficientsX) AND EXISTS(CoefficientsY) AND EXISTS(CoefficientsZ))

**NOTE: The Formal propositions are in conflict. By CorrectPositionDim, CoefficientsZ don't exists when Position.Dim=2, then 2D curves in X,Z and Y,Z should not be permitted. However, ValidCoefficients would seem to permit such combinations.

Since the intent seems to be to model parabolic vertical curves in the "Distance Along - Elevation" plane of IfcGradientCurves, and other IfcCurveSegment.ParentCurve (such as IfcCircle) reside in the XY plane, the CorrectPositionDim proposition is adequate and the ValidCoefficients proposition and associated WHERE rule should be changed to (EXISTS(CoefficientsX) AND EXISTS(CoefficientsY)) OR (EXISTS(CoefficientsX) AND EXISTS(CoefficientsY) AND EXISTS(CoefficientsZ))**

[aothms]

Looks great to me.

EXPRESS is 1-based, so we should adapt the list indexing accordingly. Should we use a summation or is the expanded notation more clear? I would probably prefer angular brackets as opposed to round to express the coordinate tuple, but I'm not sure if we already have a convention for this in the spec.

$$ \langle \sum_{i=1}^{n} CoefficientsX[n] u^{n-1}, \sum_{i=1}^{n} CoefficientsY[n] u^{n-1}, \sum_{i=1}^{n} CoefficientsZ[n] u^{n-1} \rangle $$

(edit: is this the same n or should we use variables n, m, o to indicate these can be of various lengths?).

I can't comment much on the ideas wrt to the possible permutations of valid coefficients, but it seems this was explicitly designed. If we go into the direction you sketch of a more conventional 2d/3d distinction (which I personally thinks makes sense, because in IFC we can only distinguish between 2d and 3d curves using the IfcCurveDim() func, so any further differentiation between various planes seems highly error prone). But again, I don't know the reasons or use cases why this was established like it is now.

• EXISTS(CoefficientsX)
• EXISTS(CoefficientsY)
• EXISTS(CoefficientsZ) XOR (Dim == 2)

IfcCurveDim:

  IF ('IFC4X3_ADD2.IFCPOLYNOMIALCURVE' IN TYPEOF(Curve)) THEN
    return(Curve\IfcPolynomialCurve.Position.Dim);
  END_IF;

to make it completely analogous to how IfcSpiral is handled there.

[RickBrice]

I like the summation version of the equation better. It should be $$u^{i-1}$$

Does OPTIONAL before CoefficientsX and CoefficientsY need to be removed as both are required for a 2D curve?

[SergejMuhic]

The design intent was to have any 2D coordinate system to be valid for 2D polynomial curves. This feature was added later and apparently only one of the WRs was corrected.

I completely forgot about CorrectPositionDim which still reflects the original definition where only XY was allowed for 2D curves.

This would then make sense:

  CorrectPositionDim :
    ((Position.Dim=2)
    AND 
    (NOT EXISTS(CoefficientsX) OR NOT EXISTS(CoefficientsY) OR NOT EXISTS(CoefficientsZ)))
    OR
    (Position.Dim=3);

[RickBrice]

It probably isn't my place to disagree, but in this case I think the value of simplicity and consistency outweighs the expressiveness of a more general approach. For 2D, line, circle, ellipse, spirals (clothoid, others) are all XY plane. Polynomial becomes a one-off inconsistent curve type when there are 3 options for a 2D plane. Consistency eases development burden.

[SergejMuhic]

I can relate to that. It definitely makes sense. I would not be against that approach.