Proposal to describe parametric counting in cost quantities

[Moult]

An IfcCostItem's CostQuantities may be either:

1. Arbitrarily defined as an IfcPhysicalQuantity
2. Parametrically defined as an IfcPhysicalQuantity that is both referenced by the CostQuantities and a related thing.

The "thing" may be:

1. An IfcProduct, IfcProcess, or IfcResource related using IfcRelAssignsToControl
2. An IfcProcess related using IfcRelAssignsToProcess or IfcRelAssignsToProduct to an IfcProduct described in number (1)
3. An IfcResource related using IfcRelAssignsToProcess to an IfcProcess described in number (1) or (2)

Note: the docs mention a directed flow from Cost->Product->Process->Resource, and it is not clear whether you are allowed to go from Cost->Process->Product, for example.

Notably missing is the ability to parametrically "count" objects.

I propose to add a description that an IfcCostItem's CostQuantity may contain an IfcQuantityCount. If the IfcCostItem controls "things", the IfcQuantityCount may be calculated from the total count of things counted.

Because "things" can be many direct or indirectly assigned things, I believe this should be restricted to only direct assignments. Therefore, only a "thing" defined by definition (1) out of the three possibilities shall be allowed.

Potentially, the Formula attribute of IfcQuantityCount may be used to distinguish between different counting mechanisms.

[Andrej730]

Met this issue too, so currently there is no reliable way to tell whether IfcCostItem is counting controlled objects or not, only by having a local convention for a model, e.g. mentioning in IfcCostItem.IfcQuantityCount's formula/description/name that it should reflect the count of controled elements and it should be updated manually each time elements assigned/unassigned to/from IfcCostItem.

Currently in IfcOpenShell API we assume that if IfcCostItem has 1 quantity and it's IfcQuantityCount then we assume it's used for counting controlled elements. Which is indeed very bold assumption that doesn't account for two cases I mention below.

I propose to add a description that an IfcCostItem's CostQuantity may contain an IfcQuantityCount. If the IfcCostItem controls "things", the IfcQuantityCount may be calculated from the total count of things counted.

It's probably possible that:

• IfcCostItem may not have controlled elements at all and still counting something.
• IfcCostItem may mix in the count controlled elements and some other count value (e.g. external elements that may not be present in the model), so value would be greater than count of the controlled elements.
• IfcCostItem controls more elements than it counts, so some controlled elements shouldn't be counted.

To accomodate that we would need some new way to explicitly declare the items it should count (IfcCostItem attribute?). Though maybe there are similar cases in IFC when you need to count elements existing in IFC, so it's not just IfcCostItem's problem.

There is also a weird solution that would work even in the current schema - create some custom quantity set that will have a Q_COUNT prop "CountProp" that will always be equal to 1 and it will be possible to add that IfcQuantityCount to CostQuantities. That way cost item's quantity will become procedural.