Description of the proposal:
IfcConnectionGeometry looks more like a select with no attributes of its own. The four subtypes differentiate between the type of geometry (point, curve, surface and volume) referencing relating and related geometry in all cases. It is used only by the connection relationships that optionally provide the geometry on the relating and related element. This could be replaced by discrete attributes on the relationship avoiding an intermediate instance.
Describe how it contributes to the objectives (https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC):
Geometric constraint resource simplification by removing some entities.
Is this a proposal to 'add', 'remove' of 'change' entities in the schema (pick one):
remove
What do we win:
Shorter graph for getting to the actual geometry items.
What do we lose
Constraints on which geometry has to be used on the relating and related elements. If removed, without further constraints in the schema or MVDs, the connections relationships could specify a different geometry base type on the relating and related elements.
Schema impact:
removal of items and modification of connection relationships that have optional geometry
Instance model impact:
direct relationship to geometry items from connection relationships
Backwards compatible:
yes
Automatic migration possible:
yes
Additional implications:
-
Note that not all points need to be satisfied!
Backwards compatibility and file size are not concerns.
Description of the proposal: IfcConnectionGeometry looks more like a select with no attributes of its own. The four subtypes differentiate between the type of geometry (point, curve, surface and volume) referencing relating and related geometry in all cases. It is used only by the connection relationships that optionally provide the geometry on the relating and related element. This could be replaced by discrete attributes on the relationship avoiding an intermediate instance. Describe how it contributes to the objectives (https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC): Geometric constraint resource simplification by removing some entities. Is this a proposal to 'add', 'remove' of 'change' entities in the schema (pick one): remove What do we win: Shorter graph for getting to the actual geometry items. What do we lose Constraints on which geometry has to be used on the relating and related elements. If removed, without further constraints in the schema or MVDs, the connections relationships could specify a different geometry base type on the relating and related elements. Schema impact: removal of items and modification of connection relationships that have optional geometry Instance model impact: direct relationship to geometry items from connection relationships Backwards compatible: yes Automatic migration possible: yes Additional implications:
- Note that not all points need to be satisfied! Backwards compatibility and file size are not concerns.