I took the liberty of creating this discussion here, in reference to Issue Improving ifc5d #6570, because I would like to talk about this without polluting the conversation there.
In addition to the list of features that @Massimo and @steverugi exposed I would add:
1 - Implementation of IfcTypeResource:
I don't think this was implemented in resource creation (the tests I've done show this, but I could be wrong). If resources were created from type instances it would solve two conditions:
1.1- Changes in the cost value of the type would be reflected in the children created when they are assigned to tasks (a problem that was mentioned before in another old post that I was unable to recover)
1.2- It could be assigned to an IfcCostItem, according to the Ifc documentation:
_"For rate-based costing (specifically for IfcCostScheduleTypeEnum.SCHEDULEOFRATES), a single
IfcTypeProduct, IfcTypeProcess, or IfcTypeResource subtype can be used to reflect rates for occurrences of
such types. This enables the possibility of generating a quantity-based cost schedule for occurrences based on
types with rate-based cost schedules."_
2 - Implementation of the (10)Components attribute of IfcCostValue for Composition/nesting/calculation of values:
2.1- In the IFC_4.2 documentation there was an image in Concept usage/Nesting that showed a way to make calculations with rates (something very necessary for SoR). This image no longer appears in the IFC_4.3 documentation, but the attribute remains, so I assume it can still be used for this purpose.
2.2- Maybe this has already been implemented and I didn't find it because I couldn't make the (9)ArithmeticOperator attribute in the interface work to, for example, multiply 2 IfcCostValue. If anyone has succeeded, please show me how to do it.
3 - Implementation of a button for resource assign (item 1.2):
I think the logic could be:
-
click on the button with the IfcTypeResource selected
-
creates an IfcCostItem with the same name as the resource
-
creates a IfcCostValue(root) in the list of the (8)CostValues attribute of the IfcCostItem
-
adds the IfcCostValue of IfcTypeResource to the list of the (10)Components attribute of IfcCostValue(root) to be used for composition (if item 2 is implemented)
-
disables the possibility of editing this IfcCostValue in SoR, to avoid user error it would only allow deletion and would need some warning that editing can only be done in the source resource.
Maybe this logic makes sense for SoR, but not for other types of cost schedules, so you need to dig deeper into this.
I would like to know what you think.
Cheers