suggestion: new property for place of installation (Einbauort)

Activities & Projects IFC4.3 Building Room - Building Domain Review
1

Hi
I am working in a bS Germany group where we define a MVD for model based quantity take off (for Architecture). We are working together with architects, construction companies, QTO engineers.
The goal is to define a kind of an mvdxml which contains a certain set of data at a dedicated planning stage.
We are designing this MVD based on the VDI norm which defines the degree of completion (Fertigstellungsgrad) for cost estimation. This goes from 100 up 500, whereas 300 is a finished design (Entwurf in german). We are currently working on 300.

Now after defining the needed properties we are in the mapping phase where we map the properties to the corresponding IFC properties.
And here we are coming to the point where it seems that the existing IFC properties are not sufficient.

In this design planing phase the architects need an additional description which belongs to a building element. This description contains additional information which will help the QTO engineer to calculate the price tag. We call this field “Einbauort” (in English “place of installation”). This is the location where the building element is placed. And this comes as an additional information to storey or room whoch are not enough.

Examples: Zone 3, or Section 2 etc.

This “place of installation” is a kind of additional information helping the QTO engineer understand the element. In the design phase the QTO engineers do not have the final information but need to understand as good as possible the design intension of the architect.

We have tried to find several properties in IFC but so far none of them seems to fit.

2

Did you consider IfcZone or IfcSpatialZone? Support in all software isn’t great I think, especially if you need to have additional properties on these zones. But long-term this sounds like a better alternative? Or what kind of additional values do you expect for this property?

3

It is a free entry to help the QTO engineer understanding the building element. It is a free text entry for information whoch does not come out the geometry automatically but transports important information whoch affect the price.
We took a look atIfcZone and IfcSpatialZonebut they are not the right ones.

4

I believe that the IfcSpacialZone would be the apropriate component to resolve your problem. The truth is, sadly, this entity has been left aside and never had the attention as the others.
It is currently “under construction” and should soon be available for implementation. Maybe @daviddelven could give as some insight about it.

2 Likes
5

In my understanding the IfcSpacialZone is the defintion of eg. a “thermal zone”. Meaning: a combination of rooms which have something in common.
This could be the flats in one building. They are the “residential zone”. The parking garage is the “non heated basement zone”. The stores in the basement floor are the “shopping zone”. Or a certain area belongs to a fire security zone (fire section).
The “Einbauort” is more a description than a real zone.

6

Hello, guys

Indeed. The IfcSpatialZone, added in IFC4, but not implemented in Software so far, is since July 2021 an official project within the bSI framework. Switzerland, Japan, Germany and Spain are the current chapters involved. It has been presented in the last bSI virtual Summits.

The current project roadmap will provide, probably at the last 2022 quarter, some outcomes enabling SW industry to start implementing IfcSpatialZone.

In case there is someone interested in participating in providing expertise or consulting, get in contact with your chapter and address your request.

Regarding the discussed topic here, and considering what is covered by IfcSpatialZone, it seems that the “place of installation” might be perfectly covered by one of the planned use cases of Spatial Zones. They are particularly aimed to be non-hierarchical and to have its independent placement and shape representation.

Here you can find a short summary of Spatial Zone use cases:

Zone types: construction, security, fire-safety, lighting, etc…
Zone volume: 2D, 2.5D, 3D
Simulation volumes (energy, evacuation…)
MEP reservations (holders, shafts, intermediate rooms, etc…)
Operation and management (with shape representation requirements)
GIS connection
Urban/Infra domain management (decoupling from Project Models to urban or landscape level).
…

The next IFC Schema version might include already an initial list of PredefinedTypes and, in the future, also include their own Pset structures, etc.

In the meantime, i.m.o. a custom property at an instance level is necessary for the “place of installation” and probably you should use an IfcSpace, assuming the story dependency constraint.

Greetings,

David

2 Likes
7

I am not really aware @hkreienbrink about this “Einbauort”, especially in the early design phases.

From what I understand, a custom Pset to that building element does not solve your problem. On the other hand, I wonder, how do you intend to extract the quantities if an element sits between two of these zones.
We use in projects a similar concept of Einbauort, but it is more as a “building part” or even “site part”. In this case, we generate different IFC files with two IfcBuildings or IfcSites, hence a clear definition where the element is placed.

Do you maybe have an example of what you exactly mean?

8

Holger if you don’t mind, I would like to explain a little bit more in detail what we need, and why we intend to get a property called “place of installation”.

In the early design phases (Vorentwurf = Schematic Design, Entwurf = Design Development) costs are summarized based on the DIN 276.
DIN 276 contains groups of cost called Kostengruppen (KG).

KG 300 are building construction elements. Building construction elements are divided into:

  • 310 excavation
  • 320 foundation (ground touching elements)
  • 330 exterior walls (vertical exterior elements)
  • 340 interior walls (vertical interior elements)
  • 350 slabs (horizontal elements)
  • 360 roofs (horizontal and pitched external elements)
  • 370 does not exist
  • 380 furnishing elements
  • 390 others

Whereas KG 330 ist further divided into:

  • 331 loadbering exterior wall constructions
  • 332 non-load bearing exterior wall constructions
  • 333 exterior columns
  • 334 exterior wall openings (doors, gates, windows, …)
  • 335 exterior wall covering on the exterior side
  • 336 exterior wall covering on the interior side
  • 337 Elementen exterior wall constructions
  • 338 exterior shading devices
  • 339 other exterior wall elements

Here you can see one of the first problems, as DIN 276 is mixing geometric element classifiaction with properties like IsExternal and IsLoadBearing.

351 slab constructions contains:

  • slabs (IfcSlab, PreDefindeType:FLOOR, IsExternal:false)
  • balconies (IfcSlab, PreDefindeType:FLOOR, IsExternal:true / IfcSlab, PreDefindeType:USERDEFINDE, BALCONY
  • beams (IfcBeam, IsExternal:true/false)
  • stairs (IfcStair, IsExternal:true/false)
  • landings (IfcSlab, PreDefindeType:LANDING, IsExternal:false)

361 roof constructions contains:

  • roof structures (IfcRoof Types)
  • slabs (IfcSlab, PreDefindeType:ROOF)
  • balconies (IfcSlab, PreDefindeType:FLOOR, IsExternal:true / IfcSlab, PreDefindeType:USERDEFINDE, BALCONY
  • beams (IfcBeam, IsExternal:true/false)
  • stairs (IfcStair, IsExternal:true)
  • landings (IfcSlab, PreDefindeType:LANDING, IsExternal:true)

As you can see for beams for example it needs a further information to determine if it belongs to KG 350 or KG 360. That could be done by a new PreDefinedType for beams, a UserDefinedType or a property that expresses, that the beam belongs to a slab construction (KG 350) or a roof construction (KG 360)

Another example are floorings. DIN 276 differentiates between floorings on foundations and slabs. Floorings on foundations are KG 325 and floorings on slabs are KG 352. Where KG 352 floorings could be interior or exterior (on balconies)
So here we need again a new PredefinedType for IfcCoverings, a USERDEFINED Type or a property which expresses that the flooring belongs to foundation or slab.

Another Example are wall coverings. Interior wall coverings of an exterior wall needs have to be differentiated from wall coverings of interior walls. So the property IsExternal is not enough. We would need a further PreDeifnedType for “exterior-wall coverings on the inside” and “exterior-wall coverings on the outside” or USERDEFINED Types or a Property that expresses that the wall covering belongs to an exterior wall.

You might suggest, we should use a separate classification for DIN 276, but that means more effort due to two classifications and risk of double and contradictory information.

You might suggest we should use USERDEFINED Types but as there is no way to have a predefined array of values for USERDEFINED Types, and as we doubt BSI would extend the PreDeiefnedTypes, we consider a property as better choice, as it is possible to predefine a value list for a properties.

I hope this helps understanding our approach a better.

2 Likes
9

Hi Michael, found this thread while looking just into this topic myself. Is there any progress, known to you, to tackle DIN276 structure and Ifc structure?

Best regards, Michael