Improper order of alignment layouts - False Positive

[RickBrice]

IfcAlignment forms a whole/part relationship with its Alignment Layouts (horizontal, vertical, and cant) with an IfcRelNests relationship. Additionally, stationing is represented with an IfcReferent which also participates in an IfcRelNests relationship with IfcAlignment.

IfcRelNests.RelatedObjects is an ordered collection. The IFC specification does not specify the ordering semantics of alignment layouts and referents (at least as far as I can tell). CT 4.1.4.4.1.1 implies, through the graphic on the page, that the order is IfcAlignmentHorizontal, IfcAlignmentVertical, IfcAlignmentCant. It is unclear if IfcReferent proceeds IfcAlignmentHorizontal or follows IfcAlignmentCant.

The attached example uses the order IfcAlignmentCant, IfcReferent, IfcAlignmentHorizontal, and IfcAlignmentVertical.

This is not a proper ordering of alignment layouts.

Validation Services does not detect this and gives a false positive.

Improper_Alignment_Layout_Nesting.ifc.txt

[evandroAlfieri]

Indeed, the documentation does not specify this information (i.e., order of layouts, where do referents are placed in the list). Therefor, the Validation Service cannot enforce an already existing constraint/requirement.

Furthermore, if I read correctly, even the order or (for example) the segments in the horizontal layout is not explicitly stated. My guess is that similarly to the assumption that segments in the horizontal alignment are ordered from the first to the last, when it comes to layouts, people assume the order: horizontal, vertical, cant.

Consider the followings though:

• horizontal segments can be "disordered", but their attributes (e.g., StartPoint, StartDirection, SegmentLength) always allows to order them correctly. Still confusing, I agree.
• while a "wrong" order of segments in a layout can create confusion (inconsistency between stated order and actual, geometrical order), an alignment made of H-V-C or V-H-C is effectively the same alignment.
• I remember during the creation of 4.3 someone indeed argued that that relationship - from alignment to its layouts - could have been an aggregation (i.e., irrelevant order). But I forgot the reason why it finally was defined as IfcRelNests
• Referents follow the same logic, the assumption is that their order in a list is consistent with their actual object placement. But this assumption is not stated, hence not checked.
• Referents might be in a separated instance of IfcRelNests, one used for the alignment layouts and one for all the referents that represents stationing points. This might avoid the confusion on: do referents precede horizontal or follow cant? None, referents are just linked to the alignment.

Bottom line, the Validation Service cannot check what is not specified/clarified. If these questions on order of layouts and referents create ambiguities in implementation my suggestion is to move this issue as a 4.3 issue - to be resolved/clarified by the next release of the standard.
update: @RickBrice I just saw you did it already. Thanks and forget the above recommendation

Thoughts from other alignment experts (I'm not one)? @peterrdf @civilx64 @jmirtsch

[aothms]

CT 4.1.4.4.1.1 implies, through the graphic on the page

This is the weakness of the concept template diagrams. There is no formal guidelines on how to interpret them.

In this particular case we actually defer graph layout to graphviz, which may internally keep ordering of nodes within ranks consistent with the order in which they are defined in the source, but I wouldn't be sure about it.

Related buildingSMART/IFC4.3.x-development#984

[civilx64]

* I remember during the creation of 4.3 someone indeed argued that that relationship - from alignment to its layouts - could have been an aggregation (i.e., irrelevant order). But I forgot the reason why it finally was defined as `IfcRelNests`

When you consider the representations, it is correct to think of it as an ordered list of Horizontal - Vertical - Cant. IfcGradientCurve (represents H + V layouts) uses IfcCompositeCurve (H layout only) as the BasisCurve. IfcSegmentedReferenceCurve ( to represent H + V + C layouts) uses IfcGradientCurve as BasisCurve.

I agree that the documentation update needs to come first before a new rule in the Validation Service. I would also lean towards deferring to IFC 4.4 so that 4.3 implementations are not affected.

I would actually recommend that the ordering be:

1. IfcAlignmentHorizontal
2. IfcReferent
3. IfcAlignmentVertical
4. IfcAlignmentCant

because in practice, vertical and cant layouts are defined by an end user via stationing. And during the design process, stationing is typically edited after revisions to the horizontal layout. Sometimes you might elect to always keep the same start station; other times you might elect to revise the start station so that critical points such as PC and PT of a circular curve retain the same station.

[RickBrice]

My preference is to use multiple IfcRelNests since referents and layouts are different ideas. Referents for critical points such as PC and PT could IfcRelNests with IfcAlignmentHorizontal. Critical vertical points with IfcRelNests, etc.

Though, this is probably too specific.