You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Very often we reuse data (especially geometries) in a model where it is unclear if this is for semantic reason (the elements should be in sync) or for storage efficiency.
The IfcReference - if changed into a rooted class - could provide a way to add this additional semantic dimension to unrooted elements.
Also, its usage should be extended to not only be used in metrics and applied values.
The problem might be that it would make it more difficult to enforce the correct class for attributes, though this is also the case in the current implementation.
With such a mechanism we could reuse local placements (named user coordinate systems), points (shared between an element and a dimensioning), etc. more effectively.
The text was updated successfully, but these errors were encountered:
Very often we reuse data (especially geometries) in a model where it is unclear if this is for semantic reason (the elements should be in sync) or for storage efficiency.
The IfcReference - if changed into a rooted class - could provide a way to add this additional semantic dimension to unrooted elements.
Also, its usage should be extended to not only be used in metrics and applied values.
The problem might be that it would make it more difficult to enforce the correct class for attributes, though this is also the case in the current implementation.
With such a mechanism we could reuse local placements (named user coordinate systems), points (shared between an element and a dimensioning), etc. more effectively.
The text was updated successfully, but these errors were encountered: