Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Helmert Transition Segment #143

Closed
RickBrice opened this issue Feb 15, 2024 · 22 comments
Closed

Helmert Transition Segment #143

RickBrice opened this issue Feb 15, 2024 · 22 comments
Assignees
@peterrdf @apinzenoehler

Comments

@RickBrice
Copy link

I'm confused by the Helmert Transition Segment. For now, let's keep this strictly to horizontal alignment geometry. I want to compute (X,Y) and tangent along the curve segment.

Is an IfcSecondOrderPolynomialSpiral always a two-part "mirrored" curve?

From the Partial Concept Template 4.2.2.2.6, we see that the IfcCurveSegment.ParentCurve is an IfcSecondOrderPolynomialSpiral. The description talks about the Quadratic term for the first half and Quadratic, Linear, and Constant terms for the second half.

image

Should I expect a consecutive pair of IfcCurveSegment with ParentCurve = IfcSecondOrderPolynomialSpiral for each IfcAlignmentHorizontalSegment with PredefinedType = HELMERTCURVE? The first IfcCurveSegment would be the "first half" and the second the "second half". This doesn't seem to be the intent.

If the intent is a single IfcCurveSegment.ParentCurve = IfcSecondOrderPolynomialSpiral for each IfcAlignmentHorizontalSegment.PredefinedType = HELMERTCURVE, then are all IfcSecondOrderPolynomialSpiral entities to be interpreted as a two-part curve? I don't see anything in the documention for IfcSecondOrderPolynomialSpiral, 8.9.3.60, that would indicate this curve is to be treated differently from the other IfcThird... and IfcSeventhOrderPolynimalSpiral entities.

Documentation Error?

4.2.2.2.6 says "SegmentStart is the bearing angle at start and SegmentLength is the bearing angle at the end of the segment". However, the IfcCurveSegment.SegmentStart and IfcCurveSegment.SegmentLength are of type IfcCurveMeasureSelect, which by the informal proposition of 8.9.3.28.1, must be IfcLengthMeasure. The figure also indicates IfcLengthMeasure.

Note also that Bloss Transition Segment 4.2.2.2.2 and Viennese Bend Transition Segment 4.2.2.2.10 do not make any statements about the SegmentStart and SegmentLength attributes.

Is this statement in error and should it be removed from the documentation?
@RickBrice
Copy link
Author

I found the following in @peterrdf presentation - it answers my first question - one business logic Helmert curve maps into two geometry curves.
image

@civilx64
Copy link

@RickBrice are there any other predefined types where this is the case? This will affect the alignment rules being developed for the validation service. Currently there is a check of number of segments in the business logic and the representation to confirm the same number of total segments in both. But based on your feedback, a single Helmert curve segment corresponds to two curves in the geometry, which means that some additional nuance will be needed in the implementation of validation rule ALA002.

@RickBrice
Copy link
Author

@civilx64 as far as I know, this is the only case. I don't know if it is a strict rule or not. This is just my conclusion based on observation. The examples from the RailRoom seem to have 2 geometry for 1 business logic helmert curve segment. Perhaps 4.2.2.2.6 needs to illustrate this.

@civilx64
Copy link

Thanks, I reviewed the docs for segment type enumerations and came to the same conclusion. I will revise ALA002 accordingly.

@aothms
Copy link

aothms commented Feb 22, 2024 via email

@RickBrice
Copy link
Author

Not sure if this answers your question but the IfcCompositeCurve is a representation at the level of IfcAlignment, which is just a collection of IfcCurveSegments.

At the IfcCurveSegment level, the 'Axis' 'Segment' representation is a representation context referencing two IfcCurveSegments.

Here is an example taken from the Rall Room. See #55

ISO-10303-21;
HEADER;
FILE_DESCRIPTION (('ViewDefinition [CoordinationView]'), '2;1');
FILE_NAME ('Single-LANDXML.ifc', '2021-05-24T11:00:00', ('IFC Rail Technical Services'), ('buildingSMART International RailwayRoom'), 'RailCOMPLETE\X2\FFAE\X0\', '2019.1.1995.0', '');
FILE_SCHEMA (('IFC4X3_ADD2'));
ENDSEC;
DATA;
#1 = IFCPROJECT('1FNFy8AJeHwwz7wDZHIYIu', #3, 'IFC Rail Referencedata', 'Rail alignment sample', $, 'Longname', 'Design', $, #9);
#2 = IFCAPPLICATION(#5, '2019.1.1995.0', 'RailCOMPLETE\X2\00AE\X0\', 'Unknown');
#3 = IFCOWNERHISTORY(#6, #2, $, $, $, $, $, 999999);
#4 = IFCPERSON('TS', 'IFC Rail Technical Services', $, $, $, $, $, $);
#5 = IFCORGANIZATION('bsI RWR', 'buildingSmart International Railway Room', $, $, $);
#6 = IFCPERSONANDORGANIZATION(#4, #5, $);
#7 = IFCSIUNIT(*, .LENGTHUNIT., $, .METRE.);
#8 = IFCSIUNIT(*, .PLANEANGLEUNIT., $, .RADIAN.);
#9 = IFCUNITASSIGNMENT((#7, #8));
#10 = IFCCARTESIANPOINT((0., 0., 0.));
#11 = IFCDIRECTION((0., 0., 1.));
#12 = IFCDIRECTION((1., 0., 0.));
#13 = IFCAXIS2PLACEMENT3D(#10, #11, #12);
#14 = IFCLOCALPLACEMENT($, #13);
#15 = IFCRAILWAY('1FNFy9AJeHwuVmwDZHIYIu', #3, 'optional Railway Name', 'optional Railway Description', $, #14, $, 'Longname for Railway track geometry (alignment)', $, $);
#16 = IFCDIRECTION((0., 1.));
#17 = IFCGEOMETRICREPRESENTATIONCONTEXT($, 'MODEL', 3, 1.E-5, #13, #16);
#18 = IFCRELAGGREGATES('1FNFyAAJeHwu6TwDZHIYIu', #3, 'Documentation Container', 'Container for IfcProject, collects relevant products', #1, (#15));
#19 = IFCRELCONTAINEDINSPATIALSTRUCTURE('1FNFyBAJeHwvmywDZHIYIu', #3, 'IfcProducts contained in myIfcRailway', 'Association between IfcProducts and IfcRailway', (#20), #15);
#20 = IFCALIGNMENT('1FNFyCAJeHwxedwDZHIYIu', #3, 'Spor', 'optional Railway Description', $, #63, #66, $);
#21 = IFCALIGNMENTHORIZONTAL('1FNFyDAJeHwv87wDZHIYIu', $, $, $, $, #68, #71);
#28 = IFCCARTESIANPOINT((0., 0.));
#29 = IFCALIGNMENTHORIZONTALSEGMENT($, $, #28, 0., 0., 300., 100., $, .HELMERTCURVE.);
#30 = IFCALIGNMENTSEGMENT('1FNFyHAJeHwuDtwDZHIYIu', #3, $, $, $, #51, #54, #29);
#34 = IFCRELNESTS('3BxjiarjCHwuiObERtTLTf', $, $, $, #21, (#30));
#35 = IFCRELNESTS('3BxjiYrjCHwwCwbERtTLTf', $, $, $, #20, (#21));
#36 = IFCCOMPOSITECURVE((#37, #50), .F.);
#37 = IFCCURVESEGMENT(.CONTSAMEGRADIENTSAMECURVATURE., #43, IFCLENGTHMEASURE(0.), IFCLENGTHMEASURE(50.), #46);
#38 = IFCLOCALPLACEMENT($, #39);
#39 = IFCAXIS2PLACEMENT3D(#40, $, $);
#40 = IFCCARTESIANPOINT((0., 0., 0.));
#43 = IFCAXIS2PLACEMENT2D(#44, #45);
#44 = IFCCARTESIANPOINT((0., 0.));
#45 = IFCDIRECTION((1., 0.));
#46 = IFCSECONDORDERPOLYNOMIALSPIRAL(#47, 1224.74487139159, $, $);
#47 = IFCAXIS2PLACEMENT2D(#48, #49);
#48 = IFCCARTESIANPOINT((0., 0.));
#49 = IFCDIRECTION((1., 0.));
#50 = IFCCURVESEGMENT(.CONTSAMEGRADIENTSAMECURVATURE., #56, IFCLENGTHMEASURE(50.), IFCLENGTHMEASURE(50.), #59);
#51 = IFCLOCALPLACEMENT($, #52);
#52 = IFCAXIS2PLACEMENT3D(#53, $, $);
#53 = IFCCARTESIANPOINT((0., 0., 0.));
#54 = IFCPRODUCTDEFINITIONSHAPE($, $, (#55));
#55 = IFCSHAPEREPRESENTATION(#17, 'Axis', 'Segment', (#37,#50));
#56 = IFCAXIS2PLACEMENT2D(#57, #58);
#57 = IFCCARTESIANPOINT((49.9972443634885, 3.47204361427475E-1));
#58 = IFCDIRECTION((9.99614222337484E-1, 2.77742056705088E-2));
#59 = IFCSECONDORDERPOLYNOMIALSPIRAL(#60, -1224.74487139159, 7500., -3.33333333333333E-3);
#60 = IFCAXIS2PLACEMENT2D(#61, #62);
#61 = IFCCARTESIANPOINT((1.15725277555399E-2, -6.942977411122E-1));
#62 = IFCDIRECTION((9.98457186998745E-1, 5.55269820047339E-2));
#63 = IFCLOCALPLACEMENT($, #64);
#64 = IFCAXIS2PLACEMENT3D(#65, $, $);
#65 = IFCCARTESIANPOINT((0., 0., 0.));
#66 = IFCPRODUCTDEFINITIONSHAPE($, $, (#67));
#67 = IFCSHAPEREPRESENTATION(#17, 'Axis', 'Curve2D', (#36));
#68 = IFCLOCALPLACEMENT($, #69);
#69 = IFCAXIS2PLACEMENT3D(#70, $, $);
#70 = IFCCARTESIANPOINT((0., 0., 0.));
#71 = IFCPRODUCTDEFINITIONSHAPE($, $, (#72));
#72 = IFCSHAPEREPRESENTATION(#17, 'Axis', 'Curve2D', (#36));
ENDSEC;
END-ISO-10303-21;

@peterrdf
Copy link
Collaborator

peterrdf commented Feb 22, 2024 •
edited
Loading

Also to my knowledge the HelmertCurve is the only enumeration value for available transition curves that generates two individual 'clipped curves', i.e. two IfcCurveSegment instances. I would say as the example above shows that for this case the IfcAlignmentSegment (# 29) references two elements within IfcShapeRepresentation.Items. Note, in my perception the link to geometry is kept to allow applications to understand and find the link between IfcAlignmentSegment and its IfcCurveSegment's counterpart (in this case two of them). Implicitely this relation is also there through the IfcCompositeCurve that is linked to IfcAlignment and both IfcAlignmentSegment and IfcCurveSegment are linked in an ordered fashion allowing to find the same relation, however in a much harder to implement manner.

Also note that technically there could be more cases where an IfcAlignmentSegment has other than exact one IfcCurveSegment related. For example the case where it represents the last zero length element; in case of vertical and cant alignment this knowledge could be represented in EndPoint of IfcGradientCurve and IfcSegmentedReferenceCurve, although to my knowledge we agreed not to use EndPoint's in this case but to create a 0-length IfcCurveSegment in line with IfcCompositeCurve that does not have this EndPoint attribute. As a consequence it could also happen that IfcCurveSegment exists that do not have an IfcAlignmentSegment counterpart as the zero length last element was not defined.

@apinzenoehler
Copy link
Collaborator

The two halfs for HELMERT are a result of the two distinct curvature functions for the first and the second half of a HELMERT transition bend. As others already noted HELMERT is the only transition bend supported in Ifc 4.3 with a split curvature function.

In Ifc 4.3 documentation an explanation can be found at https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcAlignmentHorizontalSegmentTypeEnum.htm.

This curvature transition was proposed first by Friedrich Helmert in 1873. According to some sources HELMERT transition bends were in use by Deutsche Bahn in the past. It is still used in Finland and possibly also in Sweden.

Therefore the HELMERT transition bend is included in European Norm 13803.

A note for readers interested in technical history:

Before the availablity of computing devices HELMERT transition bends were approximated by the biquadratic parabola, as no economically viable calculation methods with good accuracy were available.

@aothms
Copy link

aothms commented Feb 22, 2024 via email

@peterrdf
Copy link
Collaborator

peterrdf commented Feb 22, 2024 •
edited
Loading

I didn't think it through totally however my first feedback on this idea would be that currently each IfcCurveSegment.ParentCurve is an unbounded curve (not by definition however). Making a nested structure (and therefore introducing bounded curves for parent curves) could introduce tricky issues especially as tangent (and in some cases even second order direction / tangent) at least at the end points of the clipped curves are relevant.

@civilx64
Copy link

civilx64 commented Mar 3, 2024

Also note that technically there could be more cases where an IfcAlignmentSegment has other than exact one IfcCurveSegment related. For example the case where it represents the last zero length element; in case of vertical and cant alignment this knowledge could be represented in EndPoint of IfcGradientCurve and IfcSegmentedReferenceCurve, although to my knowledge we agreed not to use EndPoint's in this case but to create a 0-length IfcCurveSegment in line with IfcCompositeCurve that does not have this EndPoint attribute. As a consequence it could also happen that IfcCurveSegment exists that do not have an IfcAlignmentSegment counterpart as the zero length last element was not defined.

I respectfully disagree with these possible additional cases. The concept template for alignment segments states that a zero-length segment must be present as the final IfcAlignmentSegment for horizontal, vertical and cant. Furthermore it states that each zero-length IfcAlignmentSegment must have a corresponding zero-length curve segment.

Net result is that a Helmert segment is the only case where one IfcAlignmentSegment is represented by more than 1 curve segment - and it must be represented by exactly 2 segments per discussion upstream.

@peterrdf
Copy link
Collaborator

peterrdf commented Mar 3, 2024

Although theoretically you are correct, it depends on the purpose of use. For example in our case as a library provider we will need to support different situations, especially in case no schema violation is triggered when implementing the last zero-length segment differently or completely omit it. My expectation is that several IFC file providers will produce technically indeed still incorrect files that however are fully in accordance with the schema itself. I know there are discussions if it is correct to support incorrect data, however for now we keep trying to support as much cases as possible.

@apinzenoehler
Copy link
Collaborator

apinzenoehler commented Mar 4, 2024 •
edited
Loading

Net result is that a Helmert segment is the only case where one IfcAlignmentSegment is represented by more than 1 curve segment - and it must be represented by exactly 2 segments per discussion upstream.

Looking at the regulations which were the basis for IFC alignment requirements I think it is possible to define the proposed constraint of an one to one association of alignment business definition and IFC-geometry representation (with the exception of Helmert).

But please keep in mind that the regulations cover only the rules for the participating rail infrastructure managers and also keep in mind that only the prioritized processes were considered.

A nice example of such deliberations can be found at https://github.com/bSI-RailwayRoom/IFC-Rail-Unit-Test/issues/52.

This "doucine" issue from 2020/2021 was closed in January 2021 because French SNCF decided that the detailed representation of doucine was not required in a first IFC version for rail.

In case the quoted decision would have been otherwise very possible there would be another geometric representation. One business segment would then possibly be represented by three IFC geometry segments to model the smoothing logic of the doucine.

If the validation rule proposal is meant to safeguard a "minimum average" of trackgeometry designs then please go ahead. As long as there are options for implementing more sophisticated designs with alternative IFC geometry representations I see no issue.

However if the validation rule proposal is meant to define a constraint for all potential cases I would strongly object to the rule. I would see no benefit to restrict the applicability of IFC to more sophisticated track geometry designs without real necessity.

@civilx64
Copy link

civilx64 commented Mar 4, 2024 •
edited
Loading

I see. So I would clarify my summary position as

a Helmert segment is currently (schema version 4.3) the only case where one IfcAlignmentSegment is represented by more than 1 curve segment

If a future schema version needs to accommodate other sophisticated designs such as the doucine mentioned, then the validation rule can be updated accordingly.

The validation rule proposal is not seeking to define a constraint. The goal is to reflect the requirements of the 4.3 specification as faithfully as possible. This special case of a Helmert curve type segment having two representation segments was a bit of a "surprise" so to say, so the goal of this conversation is to make certain that there are no other similar cases that need to be accommodated in the validation process.

@civilx64
Copy link

civilx64 commented Mar 4, 2024

For example in our case as a library provider we will need to support different situations, especially in case no schema violation is triggered when implementing the last zero-length segment differently or completely omit it.

Very good point... from this perspective there is a need to be more flexible in what is accepted as valid input, compared to what the validation service identifies as pass / fail.

@RickBrice
Copy link
Author

@civilx64 @peterrdf @aothms @apinzenoehler

Would another case where one business logic definition (IfcAlignmentHorizontalSegment) map into two geometric representations (IfcCurveSegment) be a S-curve or reverse curve?

This situation would occur for an IfcAlignmentHorizontalSegment where .StartRadiusOfCurvature and .EndRadiusOfCurvature have opposite signs, meaning one is CCW and one is CW.

@civilx64
Copy link

Per my understanding, no.

LINEAR segments require start and end radius to be 0. CIRCULARARC segments require start and end radius to be the same magnitude and same sign. Assuming you are thinking of an S-curve as two back-to-back arcs, that situation would require two logic segments, each with a corresponding representation segment.

This leaves transition curves as the only PredefinedType that could have start and end radius of different sign. With the exception of HELMERTCURVE previously discussed this transition segment would have a single representation.

@RickBrice
Copy link
Author

@civilx64 I think you are right. With a transition curve in an S-shape it would have start and length with opposite signs and length would be of sufficient magnitude to cause the curve to go through the origin and beyond.

@evandroAlfieri
Copy link
Contributor

@RickBrice @civilx64 @aothms did you reach a conclusion? Namely, I'm interested in one or more of these: change in documentation, creation of validation service rules. Do you have proposals for any of these?

@RickBrice
Copy link
Author

I think we got things figured out that the Helmert curve will have a 1:2 mapping from business to geometry. I don't think any documentation changes are needed for that per se, but stating it explicitly in plain language might be helpful in the future.

There remains an open question about the documentation, copied from above

Documentation Error?
4.2.2.2.6 says "SegmentStart is the bearing angle at start and SegmentLength is the bearing angle at the end of the segment". However, the IfcCurveSegment.SegmentStart and IfcCurveSegment.SegmentLength are of type IfcCurveMeasureSelect, which by the informal proposition of 8.9.3.28.1, must be IfcLengthMeasure. The figure also indicates IfcLengthMeasure.

Note also that Bloss Transition Segment 4.2.2.2.2 and Viennese Bend Transition Segment 4.2.2.2.10 do not make any statements about the SegmentStart and SegmentLength attributes.

Is this statement in error and should it be removed from the documentation?

@civilx64
Copy link

civilx64 commented Apr 6, 2024

This is already covered in the validation rules that have been created thus far, so no additional rules required at this time.

@civilx64
Copy link

civilx64 commented Apr 23, 2024 •
edited
Loading

This is already covered in the validation rules that have been created thus far, so no additional rules required at this time.

Deployed in v0.6 of Validation Service via normative rule ALS010.

@civilx64 civilx64 mentioned this issue Apr 23, 2024
Open
@matgitbac matgitbac mentioned this issue Jul 5, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@peterrdf peterrdf

@apinzenoehler apinzenoehler

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@aothms @peterrdf @civilx64 @RickBrice @apinzenoehler @evandroAlfieri