We are looking for a corresponding IFC property for addistional information of a building element, that helps the QTO engineer creating a price tag.
We figured out that in this planning phase we need an additional information which are not coming out of geometry or relation. The architects call this “Lage Zusatz” in german, translated it would be “supplement by location”.
Examples: yes, no, touched by earth, lies in the cold area, belongs to outdoor facility
This is more a textual infromation that helps the QTO engineer.
The current IFC scheme does not have a corresponding IFC property.
The possibility to specify isExternal more precisely would indeed be helpful for other domains as well. Especially interesting from the building simulation point of view would be the specification of “what lies behind” (outside air/earth/water/…).
However, such a specification presupposes that a component (wall) would be intersected at such a border, which cannot be assumed, since the IFC standard does not require that. Therefore, it might make sense to store this information in ifcRelSpaceBoundaries instead (whereby the term SpaceBoundary would then actually no longer be correct, because the outside is not a “space”).
The additional information is not a “yes/now” answer but a free textual information which will help in the bidding/tendering phase (what german architects are doing) to set a price for a building element.
With this the architects add additional information like “half of the wall is covered by earth, needs special treatment against water” or something liek this. This information will give the QTO engineer more information to understand the element. The ifcRelSpaceBoundariesdoes not seem to be the right place for it
I try to rephtrase it:
This information tells the QTO engineer that this element needs special treatment or a special action as it differs from a standard element. This tells him that it is a cost driver.
And that can have various reasons. We are looking for a cost relevant customer property.
I think what you’re actually after is the ability to specify the filtering rules from the cost item. Cost items reference quantities from elements in a quasi-parametric fashion in end-user tools, part of that selection filter identifiers elements with certain properties to see whether they belong to cost item X or Y. Then, the cost value on that cost item X or Y, which is part of the rate library, has an appropriate rate.
This has been recently recommended in the IFC 4.3 development issues and I 100% support it.
Hi Dion @Moult , yesterday we have indeed also covered ifcCostItem-> IfcCostItem but the group seems looking for a custom Property. Otherwise you could share some arguments why cost item should be used…hope got you correct. Thanks
@mirbek.bekboliev Would the “Custom property” or “Default property” provide a more flexible way for current authoring/editing tools to implement 4.3+ Schema versions within their SW architectures, rather than publishing an abstract subclass?