buildingSMART/IFC4.x-IF

Question to Implementers - Is there such a thing as too many IFCALIGNMENTS ?

Open

#176 opened on Mar 4, 2026

View on GitHub
 (2 comments) (0 reactions) (0 assignees) (33 forks)auto 404
help wanted

Repository metrics

Stars
 (40 stars)
PR merge metrics
 (PR metrics pending)

Description

Context I have received some IFC4X3_ADD2 files with alignments. In these files, there seems to be a prone-to-performance-issue design pattern which involves duplicating the BasisCurve used for linear placement and creating one IFCALIGNMENT per BasisCurve.

Hence depending on the number of objects linearly placed, a file can contain from ten to thousand alignments.

When checked using the validation service, these files are displayed as valid.

Yet from an industry point-of-view, I am not sure that a file containing hundreds or thousands of alignments makes much sense. Currently, to me, it seems unlikely that it would be the product of best practices or industry guidelines.

Problem At some point, whether desired or not, a high number of alignments may well lead to performance issues.

Solution In the BCF documentation for coherence and performance, the following optimization rule has been stated:

BCF is suitable for coloring a few components. A huge list of components causes poor performance. All clients should follow this rule:

If the size of colored components is huge (over 1000 components), alert the user and ask them to reduce the number of colored components.

So I guess that depending on the scenario, such optimization rules seem reasonable.

Would it make sense to add a new gherkin-rule targeting Industry Practice, to warn the validation service users of an imprudent/excessive number of IFCALIGNMENTS in their file?

Have you faced scenario where thousands IFCALIGNMENTS have been required in one single file?

Best Regards, Guillaume

Contributor guide