buildingSMART Forums

Suggestion for IfcBuildingStorey


There is a topic going on about the case on the definition of IfcBuildingStorey which you can read here.

As a result of those discussions and the few (but growing) POLL results, I would like to suggest this enhancement for the IFC4 Schema.

As @jonm suggested, the schema needs a type enumeration for the FFL and SSL. This option would offer more flexibility in choosing where the storey is defined by which use case and still being able to exchange correct data. As the poll suggests, even though the definition in the current schema is at the SSL, I believe users would like to have the possibility to define this parameter also at a different level.

@jwouellette @daviddelven @pawel_zabczynski

Hi @agron, I would amend your proposal to add a property to the property set Pset_BuildingStoreyCommon, since adding a property to a property set is an easier and faster way to enhance the IFC Specification.

Hi @TLiebich, when I started this whole story, one of my thoughts was exactly what you are saying. Btw, thanks for your reply…

…then I was trying to comprehend of how this property set would react and be compatible within big projects. As far as I understand, if you set a property to this element, it does not actually define where it is located in spatial context, but it just defines either FFL or SSL (IfcLabel). So, my question is: can the IfcLocalPlacement respectively IfcBuildingStorey.Elevation be represented by the proposed p_set? My concern is that by federating models that will have different p_sets for this definition with different values, we might get double stories (one for FFL and one for SSL) since their height values won’t correspond. In the end there is the need of a single representation of a storey from different models defined in FFL or SSL.
What is your opinion on this?