Clarifies point by distance expression offsets - #1148
Conversation
PR Validation -- schema generatorsChecks:
Detected:
📋 EXPRESS schema diff (baseline vs PR head)Express schema differences0 items Missing data🎉 No issues 🎉 Type definitions🎉 No issues 🎉 Entity definitions🎉 No issues 🎉 Constraints🎉 No issues 🎉 SHACL validation reportDefinitionForEnumLiteral
DefinitionForPropertyOrQuantity
DefinitionForResource
LeafEntityHasPredefinedType
PropertyForDefinition
SHACL report truncated -- full report in the workflow artifact bundle. See workflow run for failure details. |
There was a problem hiding this comment.
These diagrams are quite helpful - thanks! I'd recommend increasing DistanceAlong so that it is at (or just short of) the PI. The purpose of OffsetLongitudinal is to reach the unreachable zone, so there's no need for it to begin outside of that area.
There was a problem hiding this comment.
Since the point is otherwise unreachable, I don't think it matters what DistanceAlong is. When I created the sketch, I was thinking that DistanceAlong may be some convenient point, such as at a full station. There isn't any technical reason why it needs to be "close" to or at the PI.
There was a problem hiding this comment.
In the XY plane, yes. Consider the case where Tangent 1 includes a vertical curve with reasonably steep gradients. If DistanceAlong is on the first gradient, then the default Axis direction of a linear placement using this PointByDistanceExpression is very different than that of the second gradient. Or even if it is a single constant vertical gradient, the elevation (Z value) at DistanceAlong would vary quite a bit from that at the PI. My assumption is that a point to be located in the unreachable zone would match the elevation and orientation of the PI, at least before OffsetVertical is applied.
There was a problem hiding this comment.
I'm not disagreeing with you, but in the end, it is up to the implementer/modeler to use the distance along and offsets to get the point they want. They can do it the "easy way" (as you've called out) or the "hard way" (maybe that's that the draft figure shows). The figure is generic enough to convey the idea. Perhaps modeling guidance documents could highlight some best practices.
There was a problem hiding this comment.
Good deal - let's leave this figure as-is.
There was a problem hiding this comment.
I would add a note somewhere, that this is the horizontal plane.
|
|
||
|  | ||
|
|
||
| ### BasisCurve |
There was a problem hiding this comment.
| ### BasisCurve | |
| ### BasisCurve | |
| Reference system for linear positioning. As such, BasisCurve must be one of the supported shape representations for __IfcAlignment__: | |
| * __IfcCompositeCurve__ | |
| * __IfcGradientCurve__ | |
| * __IfcSegmentedReferenceCurve__ | |
| * __IfcOffsetCurveByDistances__ | |
| * __IfcPolyline__ or __IfcIndexedPolyCurve__ |
There was a problem hiding this comment.
IfcOffsetCurveByDistances, IfcPolyline and IfcIndexPolyCurve do not have easy projections onto the global XY Plane.
I would limit this to IfcCompositeCurve, IfcGradientCurve, and IfcSegmentReferenceCurve.
Is this a documentation clarification or a change of the ISO spec? Can we do this in 4x3 or does it need to go to 4x4?
There was a problem hiding this comment.
The intent was to refer back to the representations already documented for IfcAlignment and therefore re-iterate existing parts of the documentation versus breaking new ground, so to speak. IfcPolyline and IfcIndexedPolyCurve can be projected to XY by just dropping Z values (if provided in the first place). These entity types are important for supporting GIS use cases. Agree that IfcOffsetCurveByDistances is not as straightforward, but there's still value in keeping it for overall consistency. A future PR specifically for IfcOffsetCurveByDistances could provide additional clarification on how a point by distance should be implemented.
I see this as an implementer agreement and therefore clarification, not change to the spec. The EXPRESS definition remains the same and this revision provides additional guidance on how linear referencing is accomplished in IFC.
There was a problem hiding this comment.
IfcIndexedPolyCurve can be projected to XY by just dropping Z values
True, however segments of type IfcArcIndex will project onto XY as an ellipse. That's not an impossible thing, but not at all common in road/rail alignments.
|
Here is an alternative figure what would replace the one for offset vertical. 
|
|
I'd recommend keeping the previous graphic since it provides a simplified 2.5D view that domain users are familiar with, and adding this new one to supplement the overall concept. |
| # IfcPointByDistanceExpression | ||
|
|
||
| An _IfcPointByDistanceExpression_ describes a point relative to a basis curve according to distance along the basis curve. The offsets default to the initial context of the curve relative to it's tangent either specified in _IfcProduct.Placement_ or in the case of a segmented curve to the _IfcCurveSegment_ _StartPlacement_ where the values correspond to the following: | ||
| An _IfcPointByDistanceExpression_ describes a point relative to a basis curve according to distance along the projection of the basis curve in the horizontal plane. The offsets are relative to the basis curve where the values correspond to the following: |
There was a problem hiding this comment.
I think the general definition of basis curve is incorrect. The basis curve provides the basis for the 3D curve derived from the 2.5D construction. IfcPointByDistanceExpression.BasisCurve should be IfcPointByDistanceExpression.Directrix and then this definition would be as
An IfcPointByDistanceExpression describes a point relative to a directrix according to a distance along the basis curve of the directrix (the projection of the directrix onto a horizontal plane). The offsets are relative to the directrix where values correspond to the following:
There was a problem hiding this comment.
I disagree. If you want to have the point explicitly on the projection, then you should reference the projection (in IfcGradientCurve.BaseCurve this would be the IfcCompositeCurve). This is or was the intent and one of the essential clarifying functions was added in IFC Tunnel: https://bsi-infraroom.github.io/IFC-Documentation-Tunnel/4_4_0_0/general/HTML/index-new.htm#schema%2Fifcproductextension%2Flexical%2Fifcalignmentrepresentation.htm
It would need a bit more to make it formal and clear also on the IfcPointByDistanceExpression side of things but bSI TD was very clear that the project cannot propose such clarifications or enhancements.
Regarding IfcGradientCurve documentation, the projection reference is not relevant anyway since:
"The parametrization of the gradient curve is based on the underlying segments of its BaseCurve. The value of the parameter equals the parameter value of BaseCurve."
Same for IfcSegmentedReferenceCurve.
The offsets, however, need to be possible on the actual 3D geometry. Tunnel design data for example needs this and was a requirement in the infra domain in the Infra projects.
This is a broader issue that comes from the IfcCurveMeasureSelect confusion which was not intended for production use but bSI chose to keep it, despite its intention being just for testing.
There was a problem hiding this comment.
@SergejMuhic it seems like you are saying the IfcPointByDistanceExpression.DistanceAlong is measured along whatever curve is assigned to IfcPointByDistanceExpression.BasisCurve. If it is an IfcGradientCurve then DistanceAlong is the distance along the 3D curve, not it’s project onto a horizontal plane.
Is this the case? If so, it seems counter to the idea of 2.5D curve geometry we are accustomed to in civil engineering and many implementations have gotten this wrong.
ISO 19148 is not specific in this regard.
A definitive answer to this simple question is crucial for consistent implementations of the IFC4x3 specification.
bSI TD was very clear that the project cannot propose such clarifications or enhancements.
At the moment bSI does not have a TD. There is an effort underway, lead by the bSI Quality and Delivery Director, to address the open issues in IFC4x3. Issues have been categorized and are being addressed in two-week sprints through the Implementers Forum. IFC4x-IF | 4.4 update. You clearly have deep and tacit understanding of the alignment geometry topics. A core group of people are volunteering many hours to move the specification and implementations forward and are getting frustrated by the lack of clarity in this space. This is the opportunity to make the necessary clarifications and enhancements.
|
|
||
| ### DistanceAlong | ||
| The distance along the basis curve measured as either a _IfcLengthMeasure_ or _IfcParameterValue_. | ||
| The distance along the horizontal projection of the basis curve measured as either a _IfcLengthMeasure_ or _IfcParameterValue_. |
There was a problem hiding this comment.
This would not need to be changed because the semantic definition establishes that the basis curve is the horizontal projection of the directrix.
|
|
||
| ### OffsetLateral | ||
| Default offset horizontally is measured perpendicular to the basis curve, where positive values indicate to the left of the basis curve as facing in the positive parametrization direction of the basis curve, and negative values indicate to the right. If DistanceAlong coincides with a point of tangential discontinuity (within precision limits), then the tangent of the previous segment governs. | ||
| Offset measured horizontally perpendicular to the basis curve, where positive values indicate to the left of the basis curve as facing in the positive parametrization direction of the basis curve, and negative values indicate to the right. If DistanceAlong coincides with a point of tangential discontinuity (within precision limits), then the tangent of the previous segment governs. |
There was a problem hiding this comment.
Offset measured horizontally perpendicular to the directrix....
| Default offset vertical to the basis curve where positive values indicate perpendicular to the tangent at DistanceAlong in the plane of the tangent perpendicular to the global XY plane. | ||
| Offset vertical to the basis curve where positive values indicate perpendicular to the tangent of the basis curve at DistanceAlong. | ||
|
|
||
|  |
There was a problem hiding this comment.
Offset vertical to the directrix....
|  | ||
|
|
||
| ### OffsetLongitudinal | ||
| Offset parallel to the basis curve after applying DistanceAlong, OffsetLateral, and OffsetVertical to reach locations for the case of a tangentially discontinuous basis curve. |
There was a problem hiding this comment.
Offset parallel to the directrix after applying...
pjanck
left a comment
pjanck
left a comment
There was a problem hiding this comment.
Increased clarity. Wording debatable - I am no native speaker.
|  | ||
|
|
||
| ### OffsetLongitudinal | ||
| Offset parallel to the basis curve after applying DistanceAlong, OffsetLateral, and OffsetVertical to reach locations for the case of a tangentially discontinuous basis curve. |
There was a problem hiding this comment.
| Offset parallel to the basis curve after applying DistanceAlong, OffsetLateral, and OffsetVertical to reach locations for the case of a tangentially discontinuous basis curve. | |
| Offset parallel to the tangent of the basis curve at DistanceAlong after applying OffsetLateral and OffsetVertical. | |
| NOTE: This may be used to reach locations for the case of a tangentially discontinuous basis curve. |
|
|
||
| ### OffsetVertical | ||
| Default offset vertical to the basis curve where positive values indicate perpendicular to the tangent at DistanceAlong in the plane of the tangent perpendicular to the global XY plane. | ||
| Offset vertical to the basis curve where positive values indicate perpendicular to the tangent of the basis curve at DistanceAlong. |
There was a problem hiding this comment.
| Offset vertical to the basis curve where positive values indicate perpendicular to the tangent of the basis curve at DistanceAlong. | |
| Offset orthogonal to the tangent of basis curve at DistanceAlong that lies in the plane spanned by the tangent of the basis curve at DistanceAlong and the vertical axis of curve's context, where positive values are in agreement with the positive values of the vertical axis of curve's context. |
|
|
||
| ### OffsetLateral | ||
| Default offset horizontally is measured perpendicular to the basis curve, where positive values indicate to the left of the basis curve as facing in the positive parametrization direction of the basis curve, and negative values indicate to the right. If DistanceAlong coincides with a point of tangential discontinuity (within precision limits), then the tangent of the previous segment governs. | ||
| Offset measured horizontally perpendicular to the basis curve, where positive values indicate to the left of the basis curve as facing in the positive parametrization direction of the basis curve, and negative values indicate to the right. If DistanceAlong coincides with a point of tangential discontinuity (within precision limits), then the tangent of the previous segment governs. |
There was a problem hiding this comment.
| Offset measured horizontally perpendicular to the basis curve, where positive values indicate to the left of the basis curve as facing in the positive parametrization direction of the basis curve, and negative values indicate to the right. If DistanceAlong coincides with a point of tangential discontinuity (within precision limits), then the tangent of the previous segment governs. | |
| Offset measured perpendicular to the tangent of basis curve at DistanceAlong in the plane parallel to the horizontal plane, where positive values indicate to the left of the basis curve as facing in the positive parametrization direction of the basis curve, and negative values indicate to the right. If DistanceAlong coincides with a point of tangential discontinuity (within precision limits), then the tangent of the previous (oncoming) segment governs. |
There was a problem hiding this comment.
I would add a note somewhere, that this is the horizontal plane.
There was a problem hiding this comment.
Elevation is never used in the definitions. While I understand what is meant - I would propose to change to vertical axis of the curve's context. (Similar wording welcome - this is at least what I used in my other suggestions.)
I would add it as the first figure in Attributes section. Not alternatively, but rather an addition. Remove global, since it could be misunderstood. Proposal: change global with curve's, so global X becomes curve's X, or similar. |
4 participants
The semantic definition discusses how the offsets default relative to IfcProduct.Placement and IfcCurveSegment.StartPlacement. Neither of these are valid attributes, offsets are relative to the basis curve, and there are no logical default values.
Phrasing of attribute definitions revised to clarify. Figures added to aid in understanding of the offsets.