Resolve the length unit scale that applies to ONE entity, correctly for a
multi-IfcProject file (a MergedExporter unitReconciliation: 'auto'
federated export: a model whose length unit differs from the first model's
keeps its own IfcProject/IfcUnitAssignment rather than being rescaled —
see that module's docs).
extractLengthUnitScale (and the dataStore.lengthUnitScale it feeds)
answers for the FIRST IfcProject only. That is exactly right for the
overwhelmingly common single-project file, but silently wrong for a
federated entity that belongs to a LATER project: e.g. a material layer's
LayerThickness is a raw literal in ITS OWN project's unit, and scaling it
by the first project's factor corrupts the value by whatever ratio
separates the two units (a millimetre federated model read back with the
metres factor turns a 300 mm layer into a fabricated "300 m" one).
Resolves the entity's owning project via resolveOwningIfcProjectId and
reads that project's units, falling back to the first project's scale when
the walk can't place the entity, OR when the owning project's own
UnitsInContext declares no LENGTHUNIT at all (UnitsInContext is
OPTIONAL on IfcContext, so a federated model can legitimately arrive
with none). extractLengthUnitScale answers an unconfirmed 1.0
for that case too - absence reading as success - which would silently
rescale a millimetre-authored value owned by such a project by 1000x
instead of taking the file-wide answer, the same safe-miss direction
extractLengthUnitScale already documents for every other ambiguous
case.
Resolve the length unit scale that applies to ONE entity, correctly for a multi-
IfcProjectfile (a MergedExporterunitReconciliation: 'auto'federated export: a model whose length unit differs from the first model's keeps its ownIfcProject/IfcUnitAssignmentrather than being rescaled — see that module's docs).extractLengthUnitScale (and the
dataStore.lengthUnitScaleit feeds) answers for the FIRSTIfcProjectonly. That is exactly right for the overwhelmingly common single-project file, but silently wrong for a federated entity that belongs to a LATER project: e.g. a material layer'sLayerThicknessis a raw literal in ITS OWN project's unit, and scaling it by the first project's factor corrupts the value by whatever ratio separates the two units (a millimetre federated model read back with the metres factor turns a 300 mm layer into a fabricated "300 m" one).Resolves the entity's owning project via resolveOwningIfcProjectId and reads that project's units, falling back to the first project's scale when the walk can't place the entity, OR when the owning project's own
UnitsInContextdeclares noLENGTHUNITat all (UnitsInContextis OPTIONAL onIfcContext, so a federated model can legitimately arrive with none). extractLengthUnitScale answers an unconfirmed1.0for that case too - absence reading as success - which would silently rescale a millimetre-authored value owned by such a project by 1000x instead of taking the file-wide answer, the same safe-miss direction extractLengthUnitScale already documents for every other ambiguous case.