How to handle/model construction phases in IFC4

Developers
1

A participant in the Norwegian technical room asked how construction phases are supposed to be handled in IFC4 add2. He finds something in ifcContext, but he struggle to understand how it is supposed to be used.

Anyone that can help?

2

Do you mean “NEW / EXISTING / DEMOLISH” designations?

If so, this happens on an element-by-element basis. If you look at the “Pset_xxxxCommon” for each element class, like IfcColumn > Pset_ColumnCommon, you will see the attribute “STATUS”. There is a PEnum_ElementStatus which formalize the different phases.

1 Like
3

Thanks - I believe this cover the question from the developer - I’ll come back to you if he has more questions.

4

Hello, I understood the systematic for Building Elements. But can you explain how to put the status information to let’s say the IfcFurnishingElement or to the IfcFlowTerminal?

This would be very helpful for me.

5

Sorry, now i found the location to put the „status“ Information. It is now under for example „Pset_TerminalTypeCommon“. But now my question is: is this a „Typ Info“? Should it not be a occurence Information?

Thanks for helping me!

6

@Brunner, the IfcFurnishingElement documentation page does not mention which Psets apply to it. I believe this means that theoretically if you have elements of this type, you cannot set its status. But this is OK, because this type is set to be deprecated and will be made abstract in the future.

Therefore, if you look at the documentation for the child class IfcFurniture, you can see you can set a Pset_FurnitureTypeCommon which has a Status property. If you look at IfcSystemFurnitureElement, it does not have a common pset with a status property, but this is fine, as the purpose of system furniture elements are to be a subset of a furniture.

It is a similar story with IfcFlowTerminal - you should not use it as it will be marked abstract in a future release. You will notice that its instantiable subtypes do have a related pset with a status property. For example Pset_AirTerminalTypeCommon.

You should note that despite the word “Type” in Pset_AirTerminalTypeCommon, it is part of the concept “Property Sets for Objects”, not “Property Sets for Types”. Therefore it is indeed an “occurrence information” and not a “type info”. If you further check the manual for IfcAirTerminalType you will find that there are no property sets associated with the type object.

I hope this answers your questions :slight_smile:

7

@Moult, Thanks, this is very helpful for me!

8

Is Status in IfcWallCommon and Status in IfcSlabCommon the same property? Or a different one? They are defined in separate PropertySets and in the bSDD links they refer to a different IFD GUID.

<Name>Pset_WallCommon</Name>
...
<PropertyDef ifdguid="b0ca0000d21511e1800000215ad4efdf">
<Name>Status</Name>

versus

<Name>Pset_SlabCommon</Name>
...
<PropertyDef ifdguid="00093400d20811e1800000215ad4efdf">
<Name>Status</Name>
9

Hi @stefkeB, this is a known deficiency and we are about to fix it with the next update, IFC4.0.2.2. @jonm and @klaus.aengenvoort already did most of the ground work. Also ifcDoc has been updated to enable it. Identical properties, used in several property sets, shall have the same guid and be defined only once.

3 Likes
10

Any update on this? I have the impression that the “ifdguid” for each property remain unique, even if the same property is found in different property sets. I checked 4.3.rc.2

2 Likes