ALS007 Alignment vertical shape representation

[jmirtsch]

ALS007 restricts representation to a gradient curve.
However, in the Alignment documentation it notes that several types of curves might be used for geometric representation (refer Geometric perspective)
https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcAlignment.htm
I would request that this check also permit the vertical alignment representation be an indexed poly curve or polyline (which I'm reverting to when
an alignment has transition segments that are not supported in IFC.
I've attached a test file that presently fails. Note that the horizontal passes using the indexed polycurve.

00_LRT_BIM-Station_Platform edge_dummyNB.zip

[evandroAlfieri]

Interesting angle. And thanks for the example file. A few thoughts, but I'd like to hear from @peterrdf @civilx64 @RickBrice @JanErikHoel and others implementing alignment.

1. I've always read the documentation as "these are all possible geometries that can be used to describe the alignment (curve)", and not so much one specific layout (in this case vertical) of the alignment. But indeed, docs might be too vague here. Should we improve it? Let's see how
2. I see the current concept template for vertical explicitly talks only of IfcGradientCurve. However, the current concept template for horizontal talks only of IfcCompositeCurve, while the Validation Service rule allows for other representations. Am I right @civilx64? Which one of the two: concept template missing, or documentation of IfcAlignment to be clarified
3. I understand you're reverting to polyline/curves when vertical transitions are not supported by IFC. Out of curiosity, which are these transitions?

[aothms]

On the one hand, for consistency, sure, we've been incrementally adding indexedpoly to other parts of the schema as well, such as polygonal bounded halfspace.

But the association to segments on the business logic side scares me a bit:

• (a) Do we have to make abundantly clear than that one (indexed) poly is only intended to function as approximation within a single segment on the business logic?
• (b) Or do we also envision multiple business segments being folded into a single polyline. Or what if there is no business logic? Is a polyline then equivalent to multiple linear segments? What about polyline of a single segment, is that equivalent to an IfcLine?

I would vote for (a)

[jmirtsch]

In this particular example, it's an offset alignment. So the transition segment is an "offset clothoid". I'm not an expert in this, but it seems to me that an offset of a clothoid, is not another clothoid but would be a spline.
This causes other challenges in IFC, where we have IfcOffsetCurveByDistances but that would be for another discussion. (perhaps that should be constrained to only support specific segment types).
I personally do think that it's useful to have a footprint representation of the horizontal, and vertical. If these are associated with the alignment, I would suggest they might be explicitly associated with vertical and horizontal elements (but I could accept that it is not permitted).
I would agree that it should somehow be nominated that the alignment was approximated, even informally. There was a clear stance that IFC would only support a limited, standard set of transitions. However there is still a value to being able to exchange or visualize alignments beyond this, which I believe is why indexed polycurves are documented as a valid representation.
I don't think the suggestion of a works by Thomas, there is no userdefined enumeration possible within https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcAlignmentHorizontalSegmentTypeEnum.htm
At the moment, there is no business logic in my provided file for the horizontal for that reason. But perhaps it's better to turn a transition segment into multiple linear segments (denominating somehow that these multiple linear segments to approximate a singular transition). The length of the horizontal alignment would deviate from the original alignment, but perhaps it's within tolerance.

[civilx64]

@jmirtsch Thanks for raising this issue.
There is a lot to unpack here.
And we need to be very specific in our terminology so that there is clarity on whether we are discussing the entire overall alignment as a whole; a horizontal, vertical, or cant layout; or an individual segment within one of those layouts.
Likewise any discussion of entity type for representation needs to be specific about which semantic entity type it is representing.

That said, here goes:

I would request that this check also permit the vertical alignment representation be an indexed poly curve or polyline (which I'm reverting to when
an alignment has transition segments that are not supported in IFC.

IfcGradientCurve is the only valid class for representation of IfcAlignmentVertical.
This is because its coordinates and directions are defined in the (distance along, height) parameter space.
This information is abstract and shapeless unless these coordinates and directions are transferred onto a horizontal footprint.
IfcGradientCurve does this via the ParentCurve attribute, which is not available on indexed poly curve or polyline.

1. I've always read the documentation as "these are all possible geometries that can be used to describe the alignment (curve)", and not so much one specific layout (in this case vertical) of the alignment.

Absolutely correct: IfcIndexedPolyline and IfcIndexedPolyCurve are valid as representations of IfcAlignment but not for IfcAlignmentHorizontal, IfcAlignmentVertical, or IfcAlignmentCant.

2. However, the current concept template for horizontal talks only of IfcCompositeCurve, while the Validation Service rule allows for other representations. Am I right @civilx64? Which one of the two: concept template missing, or documentation of IfcAlignment to be clarified

I believe that ALS006 is currently incorrect and should only allow IfcCompositeCurve as representation of IfcAlignmentHorizontal. However that is not explicitly spelled out in documentation for IfcAlignmentHorizontal or any of the concept templates:

4.1.7.1.1 correctly lists polyline and indexed poly curve as valid for IfcAlignment.

The following three concepts 4.1.7.1.1.1, .2, and .3 tie IfcCompositeCurve, IfcGradientCurve, and IfcSegmentedReferenceCurve to horizontal, vertical, and cant layouts, respectively but they are denoted as representations of IfcAlignment.

What is missing are three concept templates to further clarify IfcCompositeCurve, IfcGradientCurve, and IfcSegmentedReferenceCurve as representations of IfcAlignmentHorizontal, IfcAlignmentVertical, and IfcAlignmentCant, respectively.

Associating these representations to the alignment layouts in a 1:1 manner is much cleaner (IMO) than having multiple representations on IfcAlignment - especially when there is re-use of a horizontal layout with multiple
vertical layouts.

The current state of these concept templates corresponds to what I have personally noted in practice - representations associated to IfcAlignment and to the segments, but not to the layouts.
Up until now I had no idea why this might have happened but now it seems to correspond to the documentation and not be a random coincidence.

(a) Do we have to make abundantly clear than that one (indexed) poly is only intended to function as approximation within a single segment on the business logic?

The indexed poly is required for segments that don't fit within the domain of enumerated types for transitions.
Therefore it is impossible to associate this category of segment to a single business logic segment because it would not correspond to any available values for IfcAlignmentHorizontalSegmentTypeEnum, IfcAlignmentVerticalSegmentTypeEnum, or IfcAlignmentCantSegmentTypeEnum.
So by extension, one (indexed) poly can only represent IfcAlignment - not any of the layouts and not any of the segments.

(b) Or what if there is no business logic?

These situations actually require that there is no business logic for the H, V, and C layouts - and by extension their constituent segments.
In other words, there is to be no IfcAlignmentHorizontal, IfcAlignmentVertical, or IfcAlignmentCant nested under IfcAlignment.
And that is why @jmirtsch has (correctly IMO) headed down the path of not having business logic in these cases.

However there is still a value to being able to exchange or visualize alignments beyond this, which I believe is why indexed polycurves are documented as a valid representation.

I agree on both points and re-emphasize that these classes are valid for representation of IfcAlignment only.

The length of the horizontal alignment would deviate from the original alignment, but perhaps it's within tolerance.

This could be addressed by providing IfcReferents at various intervals along the polyline or poly curve approximation that correspond to the actual distance along the original alignment.
This is a common practice in GIS where a "measure" value associated to a given point on a polyline geometry is not exactly equal to the calculated accumulated distance along the linear reference.

[civilx64]

Pausing a bit to reflect on my experience in industry - this discussion agrees with how authoring tools are used in practice where features offset from a "pure" alignment are still referred to as alignments - because they carry the concept of defining sweeps and placements based on distance along - but do not correspond to exact segmental constructs of line, circular arc, clothoid, etc. Correlating to IFC schema, these offset alignments would be exchanged as IfcAlignment with 2D or 3D polyline / polycurve geometry with no business logic or definition of individual segments.

IfcOffsetCurveByDistances would also be a valid representation - only for IfcAlignment and not for the layouts or segments. This would have the benefit of allowing the receiving software the ability to calculate precise locations at any point along the primary alignment.

Which is better? I see parallels to the discussion of BRep versus tesselated faces for solids. The former is more compact and "pure" but more difficult for a wide range of receiving tools to support. Correspondingly, greater interoperability for alignments is achieved via polyline & polycurve than IfcOffsetCurveByDistances.

[RickBrice]

I'm not an expert in this, but it seems to me that an offset of a clothoid, is not another clothoid but would be a spline.

correct - there is not a parallel clothoid in the same way there is a parallel circle.

Sorry I haven’t fully engaged in the discussion. I’ve been traveling.

[RickBrice]

@civilx64 has done a great job breaking this down. My read is that poly line is for approximations of IfcAlignment when the full detail is not available.

greater interoperability for alignments is achieved via polyline & polycurve than IfcOffsetCurveByDistances.

Why is this the case? IfcOffsetCurveByDistances Is ultimately tied to an IfcGradientCurve which should have good interoperability. I’ve been computing points on the offset curve by evaluating the BasisCurve then applying the offsets.

There are some issues with the application of IfcOffsetCurveByDistances as discussed here buildingSMART/IFC4.x-IF#139

what vertical transition curve is missing?

[civilx64]

An importing application does not need to do any calculations when importing polyline or polycurve because the (x, y, z) coordinates of the shape are explicitly provided. With IfcOffsetCurveByEdges an importing application needs to be able to calculate these points along an alignment.

This is similar to industry experience with exchanging surface data via LandXML. A surface can be defined via its SourceData or its Definition. The SourceData represents the collection of data used to generate the surface, whereas the Definition contains the faces and points that define the surface.

An Information Exchange involving LandXML surfaces containing SourceData only requires the receiving application to be able to compute the corresponding constrained Delauny triangulation. Experience has shown that each vendor implements this slightly differently, particularly when it comes to trimming triangles at the boundary. Conversely, exchanging the Definition ensures that the receiving application will load the exact same number of triangle faces with the exact same coordinates as the authoring tool.

There is certainly some of my personal opinion sneaking in here but I see it as "wider range of applications able to import the data = greater interoperability".

[peterrdf]

Good discussion. Let me first only answer the last part from @civilx64. If I understand it correctly it is the choice between SourceData (in my words design intent) and Definition (generated mesh / poly line). Really good point as I think there are different opinions in what IFC should carry. My personal opinion is that IFC should (only) carry SourceData, two main reasons: (in my perception the Definition is purely a interpretation of the used application of the essence of geometrical content, I agree this is almost always different for each individual application but I don't see an issue in this): 1. the non-geometrical semantics is also SourceData (I see this as the key purpose of IFC itself, i.e. an integrated snap-shot of the geometrical and non-geometrical source data) 2. there are many other formats that solved the problem of exchanging Definition (Collada, glTF, OBJ, OpenUSD), they can do this much better than IFC is capable of doing.

I know many poeple see this different and would like to see IFC moving into exchanging Definition data for geometry. In my perception like an bsDD + instantiation + existing 'simple' geometry exchange format. I am clearly not in favor of this road and would see IFC vanishing into more general / widespread formats this way; a pity as there is great value in domain wide agreement of a baseline of a format specification for exchanging SourceData (with highly semantical non-geometrical and geometrical definition).

[JanErikHoel]

Since Evandro asked me for feedback in the the comment far up, I pitch in a couple of comments:

1. The alignment is of course THE most important geometry element for infrastructure. For some projects, like rural roads e.g., the alignment geometry doesn't need to be 100 accurately represented in the construction software at site (could be represented as polyline consisting of small straight segments e.g.). But for other projects, like high speed railway e.g., the alignment geometry representation in the construction software need to be 100% correct everywhere, for all "three dimensions": Horizontal, vertical, Cant, including all points along transition curves. For the high accuracy use cases, we can't risk that the receiving software at site interpret the alignment source data differently than the design software. I therefore think is is important that IFC has the possibility to carry also the accurate geometry definition, including all transition curve types.

2. If map conversion is involved, we have the same situation as for offset: A clothoid is not a clothoid anymore e.g.. But this is probably handled/covered by the map conversion concepts in IFC?

[peterrdf]

Hi @JanErikHoel, sorry to dive into details directly :-) Just triggering on your comment 'we can't risk that the receiving software at site interpret the alignment source data differently than the design software' that I of course fully agree with from a conceptual point of view.

I think there are two versions of this statement:

1. we need a polyline or other segmented solution (maybe as alternative representation) to be sure the receiving application uses exactly the same (offset) curve to cover for inconsistencies in the standard / documentation and potential issues in the different implementations (note that 'tilt' is currently not able to be carried by a polyline)
2. different software will most probably differently apply segmentation (and minor always existing inconsistencies in end / start points of segments) to semantic curve types like Clohoid's and higher order Spirals or even circle segments etc.

The second statement means that when defining semantic geometry definitions as we do now for transition curve geometry almost always will generate slightly different geometry looking at two different applications. In my perception this is not an issue, but maybe I am wrong.

The first statement is a very good point but I am not sure we are talking about this here. Maybe we should think of adding an alternative 'measured representation' or 'calculated representation'?