-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proper representation entity for IfcAlignmentCant segment of type LINEARTRANSITION #145
Comments
@peterrdf have you seen those two files? Can you confirm they are incorrect? Any input from you is very appreciated |
Hmmm ..... That seems to be a rather complex misunderstanding. The description in the schema for "IfcAlignmentCantSegmentTypeEnum" might lead the fast readers to wrong conclusions. To understand alignment in the rail business one needs to understand the horizontal layout, the vertical layout and the cant layout at the same time. In the Ifc 4.3 context this means that one must read And it is very helpful to keep in mind that each layout is dealing with a separate distinct parameter. In the horizontal layout the relevant parameter is the curvature, in the vertical layout it is the gradient and in the cant layout it is the bank-angle or the much better to measure cant-value (occasionally also known as superelevation). So transition bends like IfcAlignmentHorizontalSegmentTypeEnum.CLOTHOID describe trackgeometry segments which deal with the smoothing of direction changes. Its purpose is to give the curvature some time/space to adapt to the curves in the track and to reduce the jerk exerted to running trains. For CLOTHOID the curvature change is linear in reference to the relevant segment extension. It usually does not matter much if one uses the segment length or the time a vehicle needs to pass the segment to express this mathematically. IfcAlignmentCantSegmentTypeEnum deals with the compensation of lateral acceleration experienced by a vehicle in a curve. For changes of this parameter smoothing is applied too. Similar to the horizontal layout linear smoothing is the most common. IfcAlignmentCantSegmentTypeEnum.LINEARTRANSITION defines the rate of change of the parameter cant (angle or value) to be constant in reference to the length of the segment. With the horizontal CLOTHOID the LINEARTRANSITION segment shares the same mathematical function, although there are two different physical concepts behind it. Now comes the complicated/confusing part: because of the kinematic objectives horizontal CLOTHOID elements and cant LINEARTRANSITION elements typically share the same extension (start station to end station). In the early stages of Ifc 4.3 development there was a cant enumeration CLOTHOID. This was replaced by LINEARTRANSITION to provide a clear indication of the separate concepts. What does this mean for geometry representations? Here I have only a hearsay contribution to make. According to my memory the ParentCurve IfcClothoid for cant LINEARTRANSITION was chosen simply to avoid introducing new entities. Please take this with a grain of salt, maybe @peterrdf or Sergej can confirm it or give a better explanation. |
I did review all three together.
Yes, I understand this. I stated the same in my original comment, although maybe could have worded it differently to be more clear.
Ok. I was not aware of that. So the similarity is that in the horizontal layout, the clothoid provides a linear adjustment of curvature over the same station range as the linear adjustment of cant.
I hope my reference to this section did not come across as criticism. That certainly was not my intent.
If I graph a long section of the cant based purely on the business logic information in the signal placement example, I get nothing but linear segments: This corresponds to geometry in the isolated cant parameter space defined by a series of IfcLine entity types, not a repeating pattern of IfcLine, IfcClothoid, IfcLine... |
@civilx64 will ALA003 close this issue or do you think we need a change in docs too? |
Yes, ALA003 will close this issue. There's no need to update the 4.2.2.2 concept template as it already indicates I'd recommend including some clarifying text in the Validation Service docs. I developed a table of documentation already as it was helpful when implementing the rule. |
Deployed in v0.6 of Validation Service via normative rule ALA003. |
Yes, but the horizontal linear segments are constant value (slope = 0). Cant and curvature are the derivative of the parent curve function and have the same functional form. The derivative of IfcLine is a constant value (zero or otherwise). The derivative of IfcClothoid is linear. IfcLine cannot represent a linearly increasing cant because its derivative is a constant value.
The parent curves for the IfcSegmentReferenceCurve in the linear-placement-of-signal example are alternating IfcLine, IfcClothoid, IfcLine, ... I believe this is correct. |
Yes, curvature is the derivative of the 2D (x-y space) parent curve. How is cant the derivative of the parent curve?
Agreed.
I agree with the logic but am still struggling to understand how cant is the derivative. |
I understand it is confusing, I disagreed with it and did not understand the solution at first also. Now I see it makes sense (given restrictions in the schema) an think it is a good solution even though it is arguably a bit too much getting infrastructure domain knowledge in the geometry domain. So technically the same IfcCurveSegment instance could be used as a segment for IfcCompositeCurve, IfcGradientCurve and for IfcSegmentedReferenceCurve (note that I would not advise this). In IfcCompositeCurve and IfcGradientCurve this segment (if its ParentCurve is an IfcClothoid) represents a non linear profile (i.e. a simple spiral part), while the same segment represents a linear profile if used by IfcSegmentedReferenceCurve. Another confusig factor can be that enumeration values (of IfcAlignmentCantSegmentTypeEnum) can be seen as inconsequent while CONSTANTCANT and LINEARTRANSITION represent the actual profile in geometry the other enumeration values slightly more define the actual IfcCurveSegment.ParentCurve definition (still derived from the way the domain looks at these terms). |
@civilx64, it took me way too long to understand this, and I'm only about 95% confident in my understanding. I think the relationship between cant and the derivative is easier to see with the polynomial spirals. Consider a Bloss curve with a IfcThirdOrderPolynomialSpiral parent curve. In the 2D horizontal space, the slope or tangent of the curve taken from 8.9.3.72 is Curvature is the derivative of this function Now consider the cant equation for a Bloss transition Expand the terms This equation has the same form as the curvature equation. They are both cubic polynomials. Parameter: Constant term: Linear term: Quadratic term: Cubic term: So that's the basic idea as I understand it. The math seems to be a little different in practice. Using the EnrichIFC4x3 program in the Rail repository - thanks @peterrdf this was a huge help, I have reverse engineered the following. The Bloss curve equation for cant is This has the same functional form as before. From the business logic start left cant: start right cant: end left cant: end right cant: Constant term: Linear term: Quadratic term: Cubic term: Using the GENERATED__CantAlignment_BlossCurve_100.0_1000_300_1_Meter.ifc example.
Constant term: Linear term: Quadratic term: Cubic term: Evaluate the cant curve at I understand this to mean the IfcSegmentedReferenceCurve is 0.04 meter above the IfcGradientCurve at 50 m along the segment. Additionally, the Axis vector (assuming a rail head distance of 1.5 m) is:
I'm sure my explanation isn't perfectly mathematically correct, but this is what I understand about cant. |
@peterrdf @RickBrice thanks very much to you both for explaining this. I stepped away from the theory a bit and did some calculations for the sample model and ended up with exactly the results I would have expected for the linear transition in cant. So I agree that the Validation Service should be modified accordingly. Which leads to the next question: does the Validation Service need additional revisions for other values of the possible cant segment type enumerations? Here is the current logic behind ALA003:
|
looks correct to me, just note that an HELMERTCURVE exists of two segments (both IfcSecondOrderPolynomialSpiral) |
I’m not certain the linear-placement-of-signal.ifc example is correct. Seems like that is a discussion for a different thread. I’ll post soon so we can discuss. |
Corrected in Validation Service v0.6.5. |
Example data appears to incorrectly implement linear transitions of alignment cant layouts
Concept Templates 4.2.2.2 are very useful for understanding which ParentCurve entity type should be used for various business logic segment types. However, this documentation only addresses
PredefinedType
values for IfcAlignmentHorizontal.One example is the entity type to be used as the IfcCurveSegment.ParentCurve that serves as representation of a cant business logic segment of type LINEARTRANSITION. The current documentation suggests that IfcLine should always be used to represent a cant LINEARTRANSITION. Specifically, the base formula in the documentation for IfcAlignemtCantSegmentTypeEnum indicates a linear variation in the amount of cant over the length of the segment:
This contradicts at least two examples currently in the wild:
The confusion in the two examples listed above likely stems from the reference to linear transition of cant being the "natural" formula for horizontal clothoids. This sentence in the documentation is correct - cant is varied in a linear manner for the same length and over the same beginning and end of a clothoid transition segment in the horizontal alignment. This allows for the centripetal acceleration experienced by the vehicle body as it traverses the horizontal alignment to be counter-acted in a synchronized manner by the introduction of cant.
If the design intent truly is to use a non-linear transition between two cant values, other PredefinedType values such as BLOSSCURVE or VIENNESEBEND should be utilized in the cant business logic segment.
Solution(s)
The two examples listed above should be revised from IfcClothoid to IfcLine to align with the schema.
Require schema changes?
✓
noRequire documentation changes?
✓
noExpansion of the Concept Templates might be helpful to make this explicitly clear, but the current documentation
clearly indicates that LINEARTRANSITION of cant should be represented by IfcLine.
Rule required
Need for a formal rule? Describe it
✓
other normative rule: a normative check of the IFC Validation Service. Every IFC file must pass this checkThis relates to rule
ALA003
which is currently under development as part of the IFC Validation Service. ALA003 will report a validation error when IfcClothoid is utilized as representation of a cant LINEARTRANSITION.Additional context
An SVG graph of the alignment data in
linear-placement-of-signal.ifc
The text was updated successfully, but these errors were encountered: