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.

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

Clarity needed for Alignment Cant axis of rotation #160

Open
civilx64 opened this issue Jul 4, 2024 · 3 comments
Open

Clarity needed for Alignment Cant axis of rotation #160

civilx64 opened this issue Jul 4, 2024 · 3 comments

Comments

@civilx64
Copy link

civilx64 commented Jul 4, 2024

Problem
Ref buildingSMART/IFC4.3.x-sample-models#23

As I see it there are four variables related to fully describing cant:

  1. Point of rotation (expected to be about one of the railheads or at the center point between railheads)
  2. Distance between left and right railhead
  3. Superelevation (elevation difference between top of low and high railheads)
  4. Cross slope (superelevation / railhead distance)

Figure 8.9.3.62.A in the docs for IfcSegmentedReferenceCurve illustrates these relationships when the low rail is the point of rotation:

There is no corresponding figure to illustrate how rotation about centerline is to be defined.

Solution(s)

Another graphic illustration for rotation about centerline of rail is needed.

Require schema changes?

  • yes
  • no
  • don't know

Require documentation changes?

  • yes
  • no
  • don't know

Rule required

  • other normative rule: a normative check of the IFC Validation Service. Every IFC file must pass this check

My hypothesis is that business logic - specifically IfcAlignmentCantSegment.DesignParameters - must be provided in addition to the IfcCurveSegment representation entity. If true then this should be enforced by a normative rule.

@civilx64
Copy link
Author

civilx64 commented Jul 6, 2024

Looks like I can answer my own question based on discussion in the referenced thread. The geometry representation can stand on its own and does not require anything from the business logic. The other two points still stand - another diagram is required to describe rotation about centerline and both diagrams need updated to dimension CantLeft and CantRight that are contained in the business logic. Which then also means another normative rule in the ALA series is required to confirm that the point of rotation described by the representation matches what is described by the values of CantLeft and CantRight in the business logic.

@civilx64 civilx64 changed the title Can Alignment Cant be described fully by geometric representation only or is business logic required as well? Clarity needed for Alignment Cant axis of rotation Jul 7, 2024
@civilx64
Copy link
Author

Revised diagrams:

ROTATION ABOUT RAILHEAD
IfcSegmentedReferenceCurve_RailheadRotation

ROTATION ABOUT CENTERLINE
IfcSegmentedReferenceCurve_CenterRotation

@RickBrice
Copy link

In practice, I think you are right that the point of rotation is at one of the rail heads or at the center point between. However, the semantic and geometry definitions could be used for rotation about any point.

Here is a quick sketch to illustrate what I mean.

image

LeftCant, RightCant, and Railhead Distance define slope and point of rotation
IfcSegmentCurve.Placement.Axis and IfcSegmentCurve.Placement.Location[2] also define slope and point of rotation.
These should be consistent

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants