IFC4.3.x-development
IFC4.3.x-development copied to clipboard
buildingSMART
How is IfcReferent used to indicate transitions for cross-sections?
https://forums.buildingsmart.org/t/how-is-ifcreferent-used-to-indicate-transitions-for-cross-sections/3649
Ping @SergejMuhic is this still valid?
I’m reading the description of IfcReferent in 5.4.3.32.1 and it says “Referents may be used for several scenarios: … * indicating transitions for cross-sections (e.g. beginning of curvature where road is relatively flat, maximum curvature having super-elevated cross-slope to accomodate design speed)”
How are roadway surface transitions (superelevations) defined?
Roadway surface transitions (superelevations) are defined using IfcAnnotation/SUPERELEVATIONEVENT having linear placement along an alignment curve. No IfcReferent is required. A semantic relationship between the annotation and the alignment may be defined using IfcRelPositions relationship. Does this answer the question? Furthermore, a General Usage specification should be added to IfcAnnotation/SUPERELEVATIONEVENT and IfcAnnotation/WIDTHEVENT. Question could also have to do with IfcSectionedSolidHorizontal or IfcSectionedSurface (if actual geometry is being referred). Also in this case, there should be General Usage for e.g. IfcCourse.
IfcAnnotation/SUPERELEVATIONEVENT => Product Linear Placement & Product Relative Positioning (IfcAlignment) IfcAnnotation/WIDTHEVENT => Product Linear Placement & Product Relative Positioning (IfcAlignment) IfcCourse (geometry) => Surface Sectioned Geometry/Body Swept Solid Geometry/Body AdvancedBrep Geometry (aren't we missing something such as a CT for "Surface Stringline Geometry"? Ping @SergejMuhic
IfcAnnotation/SUPERELEVATIONEVENT => Product Linear Placement & Product Relative Positioning (IfcAlignment)
IfcAnnotation/WIDTHEVENT => Product Linear Placement & Product Relative Positioning (IfcAlignment)
Note that currently the Geometry templates don't have a predefined type rule to bind to. It can quickly be added, but I'm not sure if I'm in favour of that. I think geometry is "special" enough in the sense that if it is applicable to specific predefined types then those type should be uplifted to an entity. The world is already confusing enough.
@SergejMuhic @larswik
aren't we missing something such as a CT for "Surface Stringline Geometry
What would such a template look like?
Note that currently the Geometry templates don't have a predefined type rule to bind to. It can quickly be added, but I'm not sure if I'm in favour of that. I think geometry is "special" enough in the sense that if it is applicable to specific predefined types then those type should be uplifted to an entity. The world is already confusing enough.
The listed templates are not geometry templates. Maybe you have meant Product Shape templates?
I would be in favour of adding dedicated entites for superelevation and width also. Where to put them in the data model is another issue though. No matter what, usages would have to be specified even if only IfcAnnotation stays.
Regarding string line template, I would go for a geometric curve set. It is a bit late for such a discussion though. We have to bring this to the software implementers and find a consensus.
Hm, correct, not strictly geometry, but I think we agree. Even if I don't really understand the domain concepts this is about, it's odd to just slide this under an annotation which seems rather unsemantic.
I think for adding dedicated entities the window of opportunity is really closing fast. Usages can probably still be somewhat refined after.
I would probably go for something similar to cant. Add an IfcAlignmentParameterSegment (sorry for the naming, should have been parameterized or parametric even) and name them IfcAlignmentSuperelevationSegment and IfcAlignmentWidthSegment respectively. ping @larswik
Then they could be incorporated/nested into the Alignment Layout as IfcAlignmentSegment.DesignParameters : IfcAlignmentSuperelevationSegment. This would mean that a new linear element such as IfcAlignmentCant would also be necessary e.g. IfcAlignmentEvent maybe? To keep it generic.
We were there or in similar places once (IfcEvent/IfcLinearEvent - ISO19148) and arrived where we are now after several discussions in Stockholm, Munich, Zürich etc. Even though i agree with you, I think now is not the time.