PropertySets of IfcSpace

The IfcSpace entity contains numerous PropertySets which are either defined on the entity itself or which it inherits. In the field of thermal load there are 5 PropertySets defined at the space and two more inherited from IfcSpatialElement. These PropertySets are partly redundant, but at some points they are incomplete. They do not follow a consistent naming convention and it is sometimes not clear from their descriptions how the application is intended.
Can this also be the subject of the revision of the IFC schema? In that case, I can work up the problems once and make a consolidation proposal.


Dear @ElisEck ,

thank you raising this question. You made a great point. Yeah, Building Room is open for improvement proposals, that was a main purpose of this call.

Feel free to suggest those changes here. You may upload it here. We will forward all comments it to IFC4.3 Team.

There are 8 Psets at IfcSpace focussing on HVAC domain:

  • Pset_ThermalLoadAggregate (inherited from IfcSpatialElement)
  • Pset_ThermalLoadDesignCriteria (inherited from IfcSpatialElement)
  • Pset_AirSideSystemInformation
  • Pset_SpaceThermalDesign
  • Pset_SpaceThermalLoad
  • Pset_SpaceThermalRequirements
  • Pset_SpaceThermalLoadPHistory
  • Pset_SpaceThermalPHistory
    And 4 more Psets that touch HVAC domain:
  • Pset_SpaceCommon
  • Pset_SpaceCoveringRequirements
  • Pset_SpaceLightingRequirements
  • Pset_SpaceOccupancyRequirements

Sometimes these Psets overlap, sometimes they are incomplete. Therefore I analyzed all of them on a property level.

I suggest to not have any properties / psets cluttering the ifc schema, that are only valid in a very well defined context, such as energy balances and TimeSeries of results. Although I have some experience in heating load calculation and building simulation, I don’t understand how to use the energy balances in the Pset

  • IfcSpace:Pset_SpaceThermalLoadPHistory
  • IfcSpace:Pset_SpaceThermalLoad

I’m afraid others feel the same way and users are put off by a mess of psets. I suggest to transfer these into a well defined use case within the UCM. Alternatively, these would need to be better documented to show how the use is intended.
As the time series within IfcSpace:Pset_SpaceThermalPHistory cannot be interpreted without knowledge how they were calculated they should be moved to a use case, too.

All properties in the above mentioned psets, can be classified into

  • requirements
  • constraints
  • assumptions (should be removed)
  • intermediate results (should be removed)
  • results
  • Design decisions

I suggest not to mix properties from different classes in one pset.

Furthermore I suggest to not clutter the IFC schema with properties containing intermediate results and assumption that the engineer made during his work. People have different work processes and most importantly: they usually will not use an exchange format such as IFC to document an “arbitrary” choice of intermediate results of their work.

I propose a significant stripping of the properties at IfcSpace, as well as a merging of the remaining propertysets. As there are 146 properties now, I leave the details to the attached file.

I suggest to have a consistent naming of the Psets and the Properties themselves. Is there a naming convention that all Psets-Names start with the Respective entity e.g. Pset_SpaceThermalRequirements or can that be shortened to Pset_ThermalRequirements?

Furthermore I suggest to move most of the Pset definitions to IfcSpatialElement instead of IfcSpace. They can be used more flexible then (but maybe naming of the Pset has to be changed then?)

The properties focus very much on air-based heating and cooling, which is usually not the only conditioning system (in Germany it is usually accompanied with water based systems. As a counterpart to Pset_SpaceAirHandlingDimensioning (previously: Pset_AirSideSystemInformation) a Pset_SpaceXXXDimensioning would be necessary.

I attach an excel sheet with the mapping of the old and new properties.

Maybe people involved in the history of these Psets can comment on the original purpose and intended use. Especially concerning the properties I proposed to “kick”. I am particularly interested in what is meant by all these “diversity”-properties (IfcPositiveRatioMeasure). Maybe @TLiebich?

The goal of my proposal is to make Properties clearer and hopefully convince more people to use it for data exchange. I intentionally propose to reduce the number significantly (146->44) to the properties that are almost always needed, regardless of the project context.


Unfortunately I cannot attach any documents. @mirbek.bekboliev I send it to you via mail and ask you to upload it.

1 Like

Dear @ElisEck,

thank you so much for your invaluable input!

Like requested I’m uploading you documents in one buddle. Here is a Link to Download (PDF and Excel-Table).
@TLiebich and @berlotti please see attached files for further review and consideration.

Kind regards

1 Like

Very valuable review, @ElisEck .
I think @agron also dealt with this topic
Regarding →

Could you expand a bit more on this idea about “intermediate” results? I am not sure to understand what you mean. Is it something related to WIP tasks? Do you mean not using IFC as the exchange format when sharing intermediate results within energy analysis information exchange scenarios?

I think this:

would be very very valuable as well, not just regarding IfcSpace properties, but for the whole of them. Probably UCM will help to get that necessary context, but at least it would be nice to have a resource where to check the initial purpose in a clear and explicit format, nowadays.