There is no specific relation for IfcSurfaceFeature in IFC4
What is the need to have 2 alternatives, CSG and IfcFeatureElement?
I would suggest to IFC5 a relation from IfcProduct to IfcBooleanOperand instead.
Add operation “ExtendTo” (wall to roof, wall to another wall)
- Well there is no specific one but Element Decomposition, Element Composition with IfcRelAggregates or Object Nesting IfcRelNests should work. Not sure how the community, developers etc. would respond to new relationship. The opinions on this are usually quite divided.
- Well here we are talking about different concepts. One (CSG) is pure geometry, the other (IfcFeatureElement) is semantics. Why is an IfcOpeningElement needed? For IfcFeatureElement there have been several uses where not only geometric information is assigned to it. For example in the IFC Bridge project IfcSurfaceFeature was used to model a defect (added predefined type) because in the maintenance phase the defects are monitored and information is attached to them. Another example is the usage of IfcProjectionElement (also in IFC Bridge) to model blisters and deviators (elements to accommodate prestressed cables). So, basically for elements that are part of the main construction and need certain information attached to them. These types can all be found in IFC4x2.
- Interesting proposal. Just last week I was discussing something similar with my colleagues.
Why are there specific relationships for subtraction and addition?
I am speaking about merge both concepts into one by something like this
- As a matter of fact, I was wondering the same thing but I also wanted to be constructive . Honestly, IfcRelAggregates and IfcRelNests does not really fit semantically. It is a bit thin stretched to call the relationship of an IfcElement with its IfcSurfaceFeature to be a whole - part relationship.
- I agree, that is a good way of doing things. For relative positioning in IFC4x2 the concept template also has both the semantic as well as the geometric concept applied to position elements relatively to each other. One might argue that to be redundant but if the same placement is used for two different elements the information about which element to measure from is important (might be the other is not even constructed yet when the measuring takes place).
Unfortunately (from my experience), very little software vendors actually support CSG export/import. That is probably the first issue that would have to be overcome.
That is because CV and RV does not use CSG,
I believe CSG is a critical part of DTV.
Of course the diagram is a draft idea and there is something to think, particularly mapped type geometry, QTO and ‘Reference’ representation.
The main idea is to avoid dual solution and also avoid relationships queries to get geometry for performance.
Has anybody a use-case when Projection or SurfaceFeature element is used and the sematic is different from aggregation (so IfcRelAggregates is not suitable)?