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

[Test Case]: Alignment Superelevation & Width #9

Open
AlexBrad1eyCT opened this issue Jan 2, 2022 · 3 comments
Open

[Test Case]: Alignment Superelevation & Width #9

AlexBrad1eyCT opened this issue Jan 2, 2022 · 3 comments
Assignees
Labels
test case issues & pull requests relating to test cases

Comments

@AlexBrad1eyCT
Copy link
Collaborator

Test Case Purpose

Please provide a brief description of the purpose of the Test case proposal

Test case covering the export of superelevation and width transition data mounted on a road alignment.

Scope Summary

please provide some information around the scope of your test case proposal

Alignment Curve definition imported from previous test case annotated with:

  • Various superelevation definitions
    • left
    • right
    • both
  • Various Width transition
    • left
    • right
    • both

Test Case Proposal

MVD Code: IFC4x3_AbRV
Exchange Code: E1a
Name: Alignment Superelevation & Width
Test Code: ALSE

Additional context

Add any other context about the test case proposal here.

Miro Dependence Card

@AlexBrad1eyCT AlexBrad1eyCT added the test case issues & pull requests relating to test cases label Jan 2, 2022
@ccast1
Copy link

ccast1 commented Jan 31, 2022

Most of the case, the superelevation is not calculated on the alignement. this case is only for the case of a roof profile. On a double carriageway, the alignment is on the "central reserve" or "medium". the rotation center is calculated from the edge of pavement ( on the left in case of green field, on the right, in case of extension by the right side) . This case is not exactly the "cant" case, but very similar

@larswik
Copy link
Collaborator

larswik commented Jan 31, 2022

The IfcAnnotation PDTs SUPERELEVATIONEVENT and WIDTHEVENT are there to describe nominal values and not geometry. To describe geometries one can use e.g. sectioned solids/surfaces (swept along alignment curves), TINs etc. It would for example be possible to specify an alignment and a lateral spatial structure that captures the structure of the whole road reserve including a dual carriageway and the central reserve and specify superelevation and width for the carriageways and e.g. the central reserve width by using these annotations and spatial containment. Linear placement for superelevation and width would specify where along the referenced alignment these nominal values begin.

@ccast1
Copy link

ccast1 commented Jan 31, 2022

@larswik : ok , with your first remark on geometry. The point is the case when the superelevation is calculated or applied on a string representing the edge of pavement layer. It means the red line for the vertical is applied on this string ( the elevation reference) but the geometry of the horizontal alignment is applied on another one string on the central reserve. Just say me if my question is clear enough, may be I'm totally wrong. Anyway, if "cant" is supported, this case it's just one case of the "cant" case, but for the road.
Capture d’écran 2022-01-31 à 16 49 05

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test case issues & pull requests relating to test cases
Projects
Status: In Progress
Development

No branches or pull requests

3 participants