Moult
commented
4 years ago My understanding of this issue is that after the composition type is removed, it implies that you can nest more than three levels deep of a single spatial element, e.g: IfcSite > IfcBuilding > IfcBuilding > IfcBuilding > IfcBuilding > IfcBuilding > IfcBuildingStorey becomes legal.
+1. I had a shot at filling out the fields:
Wins: more flexibility in spatial tree. No need for vendors to apply non-automated rule checking (as there are no WHERE rules) on three level deep composition type. Also less confusion about whether a building complex is an IfcSite or a IfcBuilding.COMPLEX.
Losses: Possibly some BIM authors might go crazy and create silly unnecessarily nested trees. Deep trees are baaaaaad. It also creates confusion about the currently non-abstract IfcFacility and IfcFacilityPart proposals. Also, if I wanted to know how many building complexes I have, the query becomes slightly harder to write.
Backwards compatible: No
Automatic migration: Yes
Please refer to: https://forums.buildingsmart.org/t/spatial-composition-restraints/1129
Description of the proposal: Remove legacy composition type
Describe how it contributes to the objectives set in https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC:
What do we win:
What do we loose
Schema impact:
Instance model impact:
Backwards compatible:
Automatic migration possible:
Additional implications:
- Note that not all points need to be satisfied! Backwards compatibility and file size are not concerns.