suggestion: new property for "additional information about location" (Lage Zusatz)

again for the model based cost estimation.

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.

Currently we have (of course) IsExternal. We’ve seen other requests as well about something like IsOutside.

What is the meaning of yes and no in your example?

It seems multiple of these values could be selected, e.g “touched by earth” AND “belongs to outdoor facility”. Is that correct?

If this can be formalized into a well structured enumeration. I think it has value also to other domains.

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?

1 Like

Sorry, I misread and my comments were not focused on your issue.

Can the team come up with a list of ideal property names, data types, and descriptions? If they come up with a list, we can:

  1. See whether or not they already exist
  2. See if they actually make sense and should be added
  3. Get other cost planners to review to make sure it has international benefit
  4. Can review data types and potential groupings

Can you please post here: Issues · buildingSMART/IFC4.3.x-development · GitHub ?

1 Like

Thank you @Moult and @daviddelven for your responses.

Like it was suggested I have created an issue over GitHub. See Link below. A New Pset "PositionSupplement" · Issue #369 · buildingSMART/IFC4.3.x-development · GitHub


1 Like