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.
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?
Hi @agron, just having the option to select either FFL or SSL would help us greatly. I am not versed enough on the inner workings of IFC to give meaningful advice on how to implement this, but if there is anything I can help with, please let me know. Looking forward to how this will end up.
It is good to see that we’re making progress on this issue.
As mentioned earlier, I am completely in favor of having an Enum that helps narrow down at what position a level was placed.
However, I can’t help but feel placing this in Pset_BuildingStoreyCommon might not be the correct answer. Wouldn’t it make more sense for this to be a standard PredefinedType Attribute? That way, we have the option to add images to illustrate how to properly select the right Enum. Traditionally, Pset and PEnum pages are are void of images.
I am a bit more cautious about ElevationOfSSL and ElevationOfFFL . Should we expand the Enum in the future, that would also mean we need to add a new ElevationOf... parameter for each entree.
We already have a more ‘neutral’ Elevation attribute. Perhaps we can use this one instead?
hi @Moult
thank you for waking up this old case. Hopefully this time it will reach a satisfactory state…
Personally, I have nothing against taking this discussion to GitHub. Nonetheless, if someone that is not active in GitHub, I would not mind if they express their ideas or suggestions in this post.
Absolutely - more than happy for those to reply to this original thread, however, final review should ideally happen on Github, as forums are not designed for tracking issues.
If anybody leaves comments here, I will mirror their comments on Git for convenience
Is there a systematic protocol to mirror any issue that arises here onto Github, rather than personal commitment, such as @Moult ?
I want to find in some official web section the particular step-by-step rather than asking on a random-topic thread every time there is a clear case of upgrading a conversation into a Github pull.
Would really appreciate feedback!
