buildingSMART / buildingSMART/IFC4.x-specification-models

Possible errors in the linear-placement-of-signal.ifc example

Open
#23 21 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
13
Forks
10
PR merge metrics
No merged PRs in 30d

Description

I'm not sure if there are problems with the linear-placement-of-signal.ifc example or a lack of understanding of IfcSegmentedReferenceCurve and cant on my part. It may be both. I make this post to begin the discussion.

**Issue 1 - Clothoid constant for linear transitions**

Here is a plot of cant values based on the business logic defined in the IfcAlignmentCantSegment entitites.
![image](https://github.com/buildingSMART/IFC4.3.x-sample-models/assets/37087370/f3c2766a-c231-4795-910b-4a794b2f23df)

There are clearly regions where the cant is increasing, constant, then decreasing. The geometry of the first transition is defined by

~~~
#2605 = IFCCURVESEGMENT(.CONTSAMEGRADIENTSAMECURVATURE., #2609, IFCLENGTHMEASURE(0.), IFCLENGTHMEASURE(39.9999999999926), #2610);
#2610 = IFCCLOTHOID(#2613, 39.9999999999926);
~~~

The cant is then constant then decreases back to zero. The decreasing cant geometry is defined by

~~~
#2627 = IFCCURVESEGMENT(.CONTSAMEGRADIENTSAMECURVATURE., #2631, IFCLENGTHMEASURE(0.), IFCLENGTHMEASURE(39.9999999999925), #2632);
#2632 = IFCCLOTHOID(#2635, 39.9999999999925);
~~~

In both cases, the clothoid constant has a positive value. I think the second clothoid constant should have a negative value. Such is the case for the ACCA sleeper linear placement example from https://github.com/buildingSMART/ifc-gherkin-rules/issues/213#issue-2350530096.

~~~
#2681 = IFCCURVESEGMENT(.CONTINUOUS., #2687, IFCLENGTHMEASURE(0.), IFCLENGTHMEASURE(49.999993741124), #2691);
#2691 = IFCCLOTHOID(#2692, 70.7106692672674);

#2709 = IFCCURVESEGMENT(.CONTINUOUS., #2715, IFCLENGTHMEASURE(0.), IFCLENGTHMEASURE(400.), #2719);
#2719 = IFCCLOTHOID(#2720, -565.685424949238);
~~~

**Issue 2 - Point of rotation**

From the graph above based on the business logic, the point of rotation is at the mid-point between the rails. For the first curve, the right rail goes up and the left rail goes down equal amounts meaning the (1/2)Cant value from [Figure 8.9.3.62.A](https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcSegmentedReferenceCurve.htm) is equal to zero. However, this figure implies the point of rotation is at one of the rails.

My understanding of cant is that the IfcSegmentedReferenceCurve.CurveSegment.ParentCurve provides the geometric definition for **both** the superelevation and the cross-slope (Axis direction) between rail heads along the length of the segment.

From IfcSegmentedReferenceCurve

>The superelevation rate of change is directly proportionate to the curve segment parent curve curvature gradient equation ([IfcCurveSegment](https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcCurveSegment.htm).ParentCurve) in the linear parameter space of the base curve.

The superelevation is the difference in elevation between the IfcGradientCurve and the IfcSegmentedReferenceCurve. All of the IfcCurveSegment for this IfcSegmentedReferenceCurve have Position with z=0.0 which suggests there is no superelevation at the start of each segment. For segments with IfcLine parent curves, the superelvation remains 0.0 over the length of the segment. However, for segments with IfcClothoid parent curve, the cant should increase (or decrease if negative constants are used) over the length of the segment. This is not consistent with the rotation at the mid-point between the rails.

Here is the plot the elevations for the IfcSegmentReferenceCurve using IfcOpenShell based on my understanding of IfcSegmentedReferenceCurve. There are linearly increasing elevations wherever the parent curve is IfcClothoid.

![image](https://github.com/buildingSMART/IFC4.3.x-sample-models/assets/37087370/8df13eaf-6ebc-4eab-a19e-4ea6b4469aeb)

Additionally, from IfcSegmentedReferenceCurve

> If no deviation in the position of the curve segment to the base curve axis is specified, the axes (Axis and RefDirection) directions of [IfcAxis2Placement](https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcAxis2Placement.htm) are interpolated between the initial curve segment placement and the placement of the subsequent curve segment.

For all of the segments, deviation is specified as 0.0 so I take that to be "no deviation". In this case, the Axis and RefDirection are to be interpolated in an unspecified way. The parent curve provides that interpolation regardless of the curve segment position as discussed at the end of https://github.com/buildingSMART/IFC4.x-IF/issues/145#issuecomment-2169089806.

It seems that there are cases when the IfcSegmentedReferenceCurve.IfcCurveSegment.Parent curve defines

1. Superelevation and cross slope along the segment
2. Superelevation only along the segment
3. Cross slope only along the segment

The ACCA sleeper example seems to be Case 1. The linear-placement-of-signal example seems to be Case 3. Case 2 seems to occur only if "no deviation in the position of the curve segment to the base curve axis is specified".

How are these three cases distinguished using only the geometric representation?

@civilx64 @evandroAlfieri @michelangelo-acca @peterrdf @aothms

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with linear-placement-of-signal.ifc and the cited IfcSegmentedReferenceCurve and IfcCurveSegment definitions, then compare the geometry with the ACCA sleeper example. Reproduce the elevation plots using IfcOpenShell and review the linked discussion and 21 comments. Done means the example’s clothoid constants, rotation point, and geometric cases are resolved or clearly documented.

Written by the indexing model from the issue text.

Assessment

Domain
documentation
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.