Definition of the level for the IfcBuildingStorey (opinion poll)

Get well soon!

I think SSL should be the reference level for a storey for several reasons:

  • The position of SSL in 3D space is fixed very early in the project phase.

  • other, in particular load-bearing components, build (in the truest sense of the word) on it

  • In most cases the raw ceiling is horizontal over a large area.

  • During the construction phase, the raw ceiling is physically present very early. (It could also only be changed at great expense.)

In case there are different SSLs in one floor, in my opinion that part with the prospect of stability (in the sense of altitude) and with the largest area as reference plane is to be taken. But this is only my rough rule and should be determined by the team at the beginning of the project.

It’s true, the user of the building probably never sees the SSL, but he will rarely address an storey with the numerical value, but rather with the floor or room name.

Thank you @kurt.battisti for mentioning the cases.

Personally, I see some discrepancies that I would like to comment:

  • I don’t believe the position of the SSL of a load bearing slab is defined (in the design phase) before knowing where the FFL is. In many cases the designers work with a structural slab and finishing one as a whole, since it is not very clear in the beginning what are the exact thicknesses of the finishing layers (fire safety, acoustics, loads, etc.) and also the structural engineer comes first with a suggestion before doing a more precise calculation. In addition, there are also parameters that define the total thickness of the structural slab, meaning how is going to be built: reinforced concrete, steel construction, Cobiax, precast.
  • True, most of the vertical elements sit on the structural slab.
  • When a slab is being built in reinforced concrete, in many cases we are dealing with the lowering of the slab while drying. That is why the designer must plan the so called “the sliding connection” for walls, in order to avoid compression forces on those walls that would create unwanted cracks. Meaning the lower part of the raw ceiling is horizontal only in the virtual model, but not in reality. That is why all these discrepancies are leveled with the finishing layers that come above the structural slab an to achieve an almost ideal horizontal level of the finishing material. Tolerances in structural construction (Concrete) are in CM, whereas for the finishing layers are in MM.
  • True, the raw construction is one of the first to be seen on the construction site. But as I mentioned previously, the tolerances are 2-5cm. Talk about precision :wink:

As already mentioned by others, this is not necessarily true in the full project lifecycle. During a programming and early design stage, little is known about the thickness of the finishing layers, so only an estimate of this level is possible. The only thing that is known in advance and what matters at the end of the project is the finished floor level. So I tend to aim for that. Being trained as an architect does influence this vision, obviously.

So would it make sense to define both of them and clearly indicate which is used for what? Right now it leads to discussions when defining your stories or levels in BIM software and has an impact on the way models will be shared in IFC.

FFL is also making sense when taking into account the making of a (H)BIM of an existing building, in case you have no buildinginformation at all (no actual or accurate drawings). In that case you can only depend on what you can see (or what you can measure by for instance a 3Dscan).

Implementationwise a wellknown and broadly used BIM Authoring Tool has recently implemented a nice new feature in their IFC exporter functionality, making it possible to override the Level for export as IfcBuildingStorey, making use of a new parameter: so, the structural slab can in the BAT be referenced to a structural level (without the need of an offset), while mapping it to the preferred finished floor level.

Hello Everyone!

To clarify the question of where the IfcBuildingStorey should be in best practice located, I will continue this topic here and focus on some feedback from the participants. Therefore I have prepared a poll for all interested to take part.

The question is simple:

Depending with which stage of the building life cycle you are dealing with, what is the best scenario for YOU to develop/communicate your models concerning the level of each storey.

First case: the IfcBuidlingStorey is located at the SSL.

Second case: the IfcBuildingStorey is located at the FFL.

The voting is visible, and you are allowed multiple choices (max 5). Why that? Because some participants might cover various tasks, from design into construction phase. But if you cover just one aspect of this topic, please vote JUST ONE. Therefore, please reflect on the topic and choose the best option/s for your use case. Since I did not have the possibility to create a poll with rows and columns, I must present each use case as a separate row.

If you believe you have another use case, which has not been listed in this voting, please choose “other FFL or SSL” and be so kind to leave a comment with a short description of you case.

  • Existing documentation FFL
  • Existing documentation SSL
  • Architectural FFL
  • Architectural SSL
  • Structural FFL
  • Structural SSL
  • Mechanical design FFL
  • Mechanical design SSL
  • Construction phasing FFL
  • Construction phasing SSL
  • Building Energy Simulation and Analysis FFL
  • Building Energy Simulation and Analysis SSL
  • Facility Management FFL
  • Facility Management SSL
  • Other FFL
  • Other SSL

0 voters

1 Like

I doubt that we can get a single consensus on this issue. Seems to me that we should add an enumeration to the Building Storey ifc class that nominates use definition reference (such as FFL, SSL) for IFC5 (or an IFC4 addendum if appropriate).

2 Likes

I agree with you @jonm that reaching a single answer here is not going to be the case. I believe it will show, that the industry also cannot be attached to just one parameter such as FFL or the current SSL in IFC4. Nonetheless the poll will give an overview of what the global industry uses for its modeling purposes. That is why I find a lack of FLEXIBILITY in defining currently the IfcBuildingStorey.

If I understand your enumeration correctly: the users, depending which planning field they cover, should be able to choose the TypeEnumeration of IfcBuildingStorey (either FFL or SSL) and still be able to exchange models with others who also might use a different level (FFL or SSL). I believe this could be a way we can reach this flexibility in the IFC and allow users to choose their appropriate workaround.

1 Like

So, anyone else want to vote???
With only 6 Voters, it is difficult to get results…

Think about the topic and vote :nerd_face:

I would like to propose an alternative view that an IfcBuildingStorey may exist, but be converted into a non-compulsory spatial container.

There are buildings where the spatial organisation does not really lend itself well to a building storey, or the concept of a building storey really does not make sense. One example is a series of tunnels (which I am currently working on), or a space station (which I’d like to work on!). Other examples are Brussell’s Atomium, or a large sloping site which has many mixed use structures that open on different levels that keeps on changing SSL and FFL (which I have worked on). Indeed in that scenario the ground floor storey in nothing but a convention that confuses the builder and the architect.

I propose that IfcBuildingStorey can exist, but only optionally as a spatial container that spatial coordinates can inherit from. However, it should be allowed that the structure simply inherit from the building itself as an XYZ coordinate in whatever coordinate system (e.g. this was how the ISS was designed). There should also be other spatial containers, such as, say, IfcDatum, that are more flexible than just an elevation, and instead provide an axis, for non-vertical structures.

As for the SSL/FFL issue, IfcBuildingStorey may indeed have an enumerator to help explain to consumers the typical convention used in that particular project. As we all know, in some contexts SSL makes more sense, and in others, FFL does. Voting won’t change this.

3 Likes

I think you have some really relevant points @Moult. The current definition of a building storey is way to theoretical for real life situations. Both in normal residential and commercial situations I often comes across situations where the building have several sets of storeys that are added later or built in a scissored way due to landscape issues.

To allow for different definitions of storeys in these situations would be helpful.

2 Likes

I am reviving this old post.
Some maybe would want to vote for an option.

What is the current status od this development?

1 Like

…again going back to this old topic :face_with_hand_over_mouth: since I had last a discussion about it.

Is there any news, progress, interest in developing from buildingSMART community for this case?
So far 13 people have voted. As usual there is the division between architects and structural engineers for the definition between FFL or SSL. But according to the list, there is more of a tendency to work with FFL. The numbers are not big, but based on this, the current definition of the IFC Structure with the SSL is not quite suitable?
Can we se more votes for better results?

2 Likes

I suggest you to share it also in other networks in order to get wider results, assuming that is a general matter, non-exclusive of openBIM.

I reiterate my position.

In addition, I’d personally like to see two properties; an SSLElevation and FFLElevation, both with a cardinality of ?, therefore the user can fill it out as necessary. They can fill out both, or neither, if neither make sense (e.g. a heritage building site where neither SSL nor FFL apply, and both vary significantly).

So how does this long story find its beautiful ending? There are wishes and criterias.
Maybe @jwouellette could help clarify the next steps.

1 Like

@agron I think you need to decide on what kind of proposal you want to make. Given all the opinions and options, you should sort through all of it and make a formal proposal that includes 2 or 3 options. We can take that proposal and create an issue in GitHub for the MSG and ISG to discuss and take action on.

I may suggest that one of the options is to simply add an attribute/property to the existing IFC4 entity IfcBuildingStorey that indicates what kind of elevation is being indicated in current IFC4 IfcBuildingStorey.Elevation attribute. This could be an enumeration (choice from a list, STRUCTURAL_SLAB, FINISH_FLOOR, etc., including NOTDEFINED and USERDEFINED) or an IfcString, where the user can put the label they prefer and could standardize on at a project basis.

But I think it is also crucial to understand the dynamic between IfcBuildingStorey.Elevation and IfcBuilding.ElevationOfReferenceHeight.

https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/link/ifcbuildingstorey.htm
https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/link/ifcbuilding.htm

It may be that both concepts need to be evaluated and adjusted to operate more succinctly to end users.

In the case of the storey level definition I want also to address this topic to another discussion in the forum about the validity of the GUIDs. As suggested there, a clean way of starting a project with correct data such as GUIDs and Naming for IfcProject, IfcSite, IfcBuilding and IfcBuildingStorey would be the creation of an IFC template. This template would then be used by all involved stakeholders. In the beginning of the initiation phase of a project the number and level of storeys may not be clear, meaning it cannot be defined, but later on in the development phase things start to get more clear.

Maybe something like this might work:

Until now we were discussing how to add a type enumeration for both FFL and SSL. Offering both options is a good solution to have flexibility to all the involved stakeholders, where each chooses his own preferred workflow. In order to achieve this flexibility on all possible ranges of application, an option would be to extend the IfcBuildingStorey.Elevation into IfcBuildingStorey.FFL.Elevation and IfcBuildingStorey.SSL.Elevation. In the IFC Structure these both definitions would have the same weight, meaning that it will understand which level is what. They also must have a relation between each other to understand the logic. On the BIM Software side, the end user has the possibility to choose which is the Main level definition for him and exports IFC Data accordingly. As it currently is, also in the future the IfcBuildingStorey.FFL.Elevation would continue to have a direct reference to the IfcBuilding.ElevationOfRefHeight.

As mentioned in the earlier posts, in the beginning of a project, the FFL is more reliable source whereas the SSL is not very clear (but we are not discussing this now!). Nonetheless, based on the new concept, during the design phase, the designer has the freedom to choose with which option he wants to work. Later on, when the structural engineer steps into the game, he chooses his own weapon of choice. It would also be wise that these levels are documented (ex. BEP) to know which stakeholder is working on which level.

We should not forget that the created IFC Data is not just for the erection of a building, but to use it as a documentation for that future asset, the digital twin. Hence, having these two options, it gives you the possibility to hand over the documentation either in FFL or SSL.

Now, I come back to the IFC Template and the definition of the GUIDs. Since, in the end we are talking about federated models, no matter of how much IFC Files are created, all those spatial containers of storeys must be correctly allocated. In this case I believe the GUID should support this definition of storeys being defined either by FFL or SSL. As an example the 1.Storey which carries a GUID (XY) will be the same for the designer who works in FFL level and also for the structural engineer who works in SSL. This simply prohibits a storey from a designer to be falsely interpreted with another storey of the structural engineer.

If anyone else can contribute to this offer or maybe has other interesting suggestions, please be my guest.