IfcCurveMeasureSelect.SegmentLength cannot be a parameter, and parameter is issue in general

[I-Sokolov]

It is incorrect use parameter value for segment length - it implicitly assumes that length (param) is linear and length(0)=0, these are not a fact.

Generally, I think using of parameters is a nasty thing, because there are many parametrizations for the same curve, and there are many ways to join them for composed curve (and none of which I know is good), and mapping parameter precision to length precision is wired.

I believe the only parameters have sense for generic curve are natural length and fraction of full length

[aothms]

For the foreseeable future, until implementer agreements have resulted in a defined parametric space for all possible types in attribute ParentCurve, the values for attributes SegmentStart and SegmentStart shall be of type IfcLengthMeasure.

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

I think the spec agrees with you. Are there any actionable things you'd like to see addressed?

[I-Sokolov]

The spec says later "Length of segment measured as length or parameter"
If spec says this and those... I would say it agrees with anything-:)

I'm suggesting removing IfcParameterValue from IfcCurveMeasureSelect.

[aothms]

This solution - Select + Informal proposition - was chosen after a long session as a compromise. I understand the lack of clarity it provides but this was the only thing achievable

[I-Sokolov]

I want to clarify this is my personal opinion and it is not a request from any company I have contract with.

From my experience using parametrization is a scary thing:

• many ways to parametrize the same curve, and define parametrization full, consistent and exact is extremely hard
• not scalable to curve chains
• no good mapping to linear tolerance

If these considerations were discussed - the item can be closed, maybe we will back in next versions having more user experiences and examples.

[SergejMuhic]

@I-Sokolov thanks for opening the issue again. I have tried to keep the discussion going and I agree there should be only one way of measuring on the curve.

However, I would propose to parameterise the spirals. Let's parameterise it with length then. Drop the IfcCurveMeasureSelect in favour of IfcParameterValue and agree that the value is in project units, so we don't have to check back and forth. This means that any spiral can have its start value and length defined in a practically unitless value and curvature and bearing angle can be calculated from it.

I am not super confident with this proposal yet, but since it is a unique equation for each child of the IfcSpiral, I think this should work wonderfully.

Polynomial spirals are a special case because the length is always proportional with curvature. I am not certain, how it is for a general spiral, but IfcSpiral already is parameterised with deflection / bearing angle, so there we should be fine. This means we just need to update the documentation of the children, drop IfcCurveMeasureSelect and finally have a good specification. Then we can update the transition bends definitions and it is ready for implementation.

Connected issue: #884

[civilx64]

... and finally have a good specification.

My opinion from the perspective of 25 years in US Road and Bridge industry: IFC 4.3 is already good enough as-is. It is final and already being implemented. It has been ready for implementation for two years now - since the final ISO vote in January 2024.

Specifically regarding parameters and segment lengths for horizontal alignment layouts: For roads and bridges in the US, we only use lines, circular arcs, and clothoid spirals. I understand that there are other transition types critical in other industries such as Rail. And I understand that there are frustrations regarding the final state of the ISO 4.3.2.0 specification. If spec changes are truly required to support Rail-specific use cases, they have to be part of the next version - IFC 4.4 - and are not applicable to issues raised in this repository.