Definition of the level for the IfcBuildingStorey (opinion poll)

Users IFC
21

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.

ifcstorey
ifcstorey.JPG1456×644 50.8 KB

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
22

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
23

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
24

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

Think about the topic and vote :nerd_face:

25

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
27

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
28

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
29

…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
30

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.

31

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).

32

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
33

@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.

34

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.

35

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.

36

How’s this - let’s imagine the last two attributes of the IfcBuildingStorey store SSLElevation and FFLElevation respectively.

... in the project setup file ...
 - Notice the last two attributes are left blank: "$"
#X = IFCBUILDINGSTOREY('MYGUID', $, 'GROUND FLOOR', 'Foobar', ..., $, $)

... in the structural engineer's file ...
 - MYGUID matches
 - Notice how most attributes are "inherited/derived": "*"
 - Notice how SSL is defined, which overrides the project setup file
#X = IFCBUILDINGSTOREY('MYGUID', $, *, *, ..., 42, *)

... in the architect's file ...
 - MYGUID matches
 - Again, most are derived
 - FFL is defined, which overrides the project setup file
#X = IFCBUILDINGSTOREY('MYGUID', $, *, *, ..., *, 42.05)

... this federates to form ...
#X = IFCBUILDINGSTOREY('MYGUID', $, 'GROUND FLOOR', 'Foobar', ..., 42, 42.05)

In STEP, a ROOT file is provided to dictate order of inheritance:
#1 = project.ifc
#2 = structure.ifc
#3 = architect.ifc

In summary:

  1. BuildingStorey can store either, both, or neither SSLElevation and FFLElevation. In some projects, neither is known, in some projects one is known before the other, and in other projects, both are known. This allows maximum flexibility.
  2. GUIDs matching correlate the entities together.
  3. Inheritance and overrides are specified.

This solution also works now even though the latest STEP version isn’t implemented yet (which supports references, root files, and anchors). Simply by specifying a convention of file precedence with a little utility that merges data.

This is in contrast to the current IDM which tries to get you to import an IFC template - which doesn’t work in practice due to various reasons we mentioned in the other thread. With this solution, you just add on more IFC files, which override and inherit properties of earlier files.

1 Like
37

Thanx Dion as always for your valuable input.

I don’t quite understand what do you mean by adding more IFC files and overriding of earlier files. As far as I understood: the IFC template in my opinion should be adjustable during the development of the project, if additional stakeholders are planed to enter the process. This adjustment will make it possible for other stakeholders to enter the project at a later stage and still have the possibility to have the correct project data and choose either FFL or SSL.
Or where you talking about something else?

38

@agron - sorry, I was just trying to describe a workflow where it is possible for 3 files to have the same GUID but with a rule of whose data overrides other data. This is agnostic of whether you choose to update the original template, or just keep overriding older data with newer IFC files.

I hope I haven’t gotten muddled up with the objective. I don’t feel particularly strongly about IFC mandating a particular workflow so I’m not sure how much I can contribute further to this. My only concrete suggestion is workflow agnostic: that the IfcBuildingStorey can store either, both, or neither SSLElevation and FFLElevation.

39

I stand by you on this case @Moult.
I started this case many months ago with the same in mind. buildingSMART is offering one jar full of candy with one taste. Some kids wont be happy :slight_smile:

@jwouellette Sadly I am no expert in programing and I don’t know at which door should I knock, because I would gladly hand you a ready made product for you to discuss and maybe just copy paste it. In my last post I described a possible solution that might work. The reason why IfcBuildingStorey.Elevation and not a TypeEnumration is that the elevation needs a numerical value behind it (which a Type Enumeration cannot store). My continget has been depleted

Therefore I would kindly ask you to take it to the next instance, process, person or whomever, to further look into the development of this case and look for implementation possibilities. Let’s bring some flexibility to this case. If you need my help in any way, I will gladly help…with what I am capable :wink:

cheers to you all and thank you for your valuable input
:vulcan_salute:

40

Adding this here, because it seems fitting:

One of the quantities in Qto_BuildingStoreyBaseQuantities contain a typo (NetHeigtht instead of NetHeight). This error has been present since IFC4.0.0.0.
Can we correct this in the new, upcoming release?

1 Like