New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal to add "BALCONY" as a predefined type for IfcSlab #32
Comments
For me personally, but it might be a language thing, a balcony is not so much the slab, but the entire projecting space incl. railing and all. Also I've quite typically seen prefab elements where the slab and railing are an integrated element. These things considered I'd prefer a different approach to designate elements as being a balcony. Maybe IfcGroup or IfcElementAssembly? Thoughts? |
That would be captured in IfcSpace, but doesn't solve the problem of needing to isolate the balcony slab itself. If the slab and railing is integrated, either IfcGroup or IfcElementAssembly could be used, but doesn't change the fact that there is no easy way to isolate these elements other than based on project / user-specific convention. For this reason, I think it is a good idea to add it to one of the predefined types. |
If everybody agrees this is a quick win towards a real use case I wouldn't keep complaining, but:
I'd say this is already handled by the IsExternal property I'd be careful in introducing classification labels (especially if they overlap with other labels) as they hide the actual properties and oversimplify. Not all balconies require thermal break elements, and other overarching elements not being balconies may require thermal break elements. For me a balcony slab is also a .FLOOR. slab, so if I want to do quantity take off on floor slabs I now need to include balcony in my predefined type selection, but only for 4.3.
Plus you get more interpretation issues (the same as we're having in the other topic on IfcColumn). Like what precisely is a balcony, does it include loggias for example? The balcony in my previous apartment was 4-point supported, it was just the exterior wall that went 'inwards' a bit. It's definitely not the case that all balconies are a cantilever. |
Pinging @agronid as one of the original authors to provide feedback to help add to the debate. Also pinging @Jesusbill @jmirtsch and @Krande who may have thoughts from a structural usecase perspective. |
I am more with @aothms on this, I see it as a .FLOOR. element as well. |
Why I made the proposal has to do with the situation that such a slab does not necessarily need to be the same as the slab of the main floor. In my experience these Balconies are mostly made from prefab slabs, whereas the main slab is made InSitu. Furthermore, we are currently working on a project where the main slab is concrete, whereas the balconies in wood. The differentiation between main and balcony slab will offer more flexibility for QTO definitions, because in the market they have different cost indexes. If some declares their balcony as a main slab, I don't see that as a problem since the enumeration already exists. The additional enumeration would just extend the flexibility of definition for those who don't come along with just the slab. Maybe the term Maybe the TypeEnumeration for a slab would be: This could also solve the case where ugogreco was asking about this entity here. |
Btw second link is broken. I just checked in Sydney, according to the cost planning team here they are the same cost category - the differences like falls and waterproofing are covered in different trades. I guess if this is important for costing, a requirement can be made to model balcony slabs separately from internal slabs. Or, we need a virtual "splitting" element similar for how modelers model the entire slab, but construction sequencers need to segment pour breaks. I'd also like to ping @CyrilWaechter - since some of the discussion is about a thermal break. I'm questioning whether adding a "BALCONY" predefined type adds value for energy analysis, as there is already space boundaries and likely a separate balcony space. |
Balconies, as such, are always modeled separately from the main floor slab, whether it is thermally disconnected or not. In my experience, at least in the German-speaking countries, balconies are calculated separately from the main slabs. In Germany, they have even published a guideline for costing "BKI IFC Bildkommentar nach DIN 276", where they have specifically defined IfcSlab USERDEFINED: BALKON for the IFC4. @TLiebich do you also find it to be daily practice in your experience? But how is the case with a cantilever slab that don't have a function of a main slab nor balcony??? I have repaired the second link where it is visible. The uppermost slab (above the balcony), would that still be a main floor slab? |
yes, balcony slabs are usually considered separately from other floor slabs. But I could also agree with the more general proposal to add a cantilevel. One additional note: building classification systems (and the IFC hierarchy of subtypes -> predefined types is a de-facto classification system) are never "scientific" - i.e. following a single strict criterium for subdividing the hierarchical structure - therefore we have so many of them. They ususally reflect the interests of stakeholders to tread certain things differently. Very unfortunate but a matter of facts. |
So, I'm not at all familiar with the structural subschema of IFC, but is it an idea than that we somehow encode the support mechanism of a slab in a property set? |
ISO 6707: 3.2.2.9: balcony 3.2.2.10: external balcony 3.2.2.11: internal balcony |
@agronid so from what I read in this thread, it seems as though calling a slab a balcony does not have any implication on cost nor any implication on thermal break. Do you still believe there is value in calling particular slabs a balcony? If so, can you explain the usecase? Also if so, can you confirm which of the three possible ISO6707 definitions apply? All three? Should they be separate (i.e. BALCONY, EXTERNAL_BALCONY, INTERNAL_BALCONY) or lumped into one (BALCONY)? |
Accounting the amount of people in this topic and regulations of how such components are necessary for data exchange, it seems that this is somewhat a central European definition or requirement. As I have mentioned earlier, the definition of a balcony might not be the appropriate one. That is why my suggestion to this matter would rather be a "cantilever" since it generalizes the topic for more use cases. As mentioned earlier, this definition would be applicable to many cases, whether is a single balcony of an apartment, an external corridor for apartments or even a slab that is above a balcony and serves just as a weather protection. |
@agronid sorry if I misunderstand, are you saying that you are changing the proposal to instead use the term "CANTILEVER"? Can you clarify what exactly is the added value of introducing this new type? |
Yes! In my opinion, it is a more generalized term for this use case. Referring to a "balcony", one has a clear understanding about functionality of this element, which also narrows the usability of it. Therefore, offering a "cantilever" would offer an option for a wider usability, either as a balcony or simply a slab that is mounted on a facade for some other reason (maybe just decoration). |
@agronid yes, but I guess the question is what exactly is the added value of this new predefined type? What usecase does it help? Often slabs partially cantilever, so doesn't that add confusion? |
I also want to reiterate my earlier comment:
It seems that this Cantilever is an orthogonal concept to the set of predefined types we currently have. And perhaps there are other support types that can somehow serve a usecase. Thanks for working out that diagram. It seems to me that the IsExternal property on the IfcSpace can be used to disambiguate the external slabs. But yeah, it really depends on the tools ability to select such cases and you need space boundaries in the model for the explicit connection between slab and space (but they're probably in the model if you're interested in this kind of analysis). |
Discussed with @aothms and @Moult and @TLiebich verbally Summary of discussion:
Ping @agronid could you propose perhaps how you might like to see it stored in a pset? Something like SupportType enum, or ThermalBreak enum? What would make sense for your usecase? Ping @Jesusbill would a similar property be useful for structural usecases? Ping @CyrilWaechter what property would be useful for you? If we can find the coinciding properties we can perhaps come to a conclusion that helps multiple disciplines without putting a blanket statement of "a balcony is X". |
I don't think it would add much value specifically a SupportType enum, or a ThermalBreak enum I'd say although not my discipline. To me, what @CyrilWaechter showed here nails the issue, there is no way to know whether IsExternal has both or a single side external, which applies also for walls. |
I think we would need a separate object to hold thermal break data. It could be a specific element (new class) or a thermal bridge element (new class) with a thermal bridge type enum (eg. LINEAR, PONCTUAL) and thermal bridge category enum (BALCONY, ACROTERION, FACADEFOOTER etc… sorry I don't know english ways to name categories but I hope the goal is understandable), attribute to related elements (eg. balcony slab and wall to which it is attached) and psets for thermal loss (W/(m.K) for linear, W/K for ponctual). |
IfcRelConnectsWithRealizingElements? Or is it not always a 1-1 connection? |
For balcony thermal break. I usually see it connected physically to floor slab but from a thermal point of view you need to know what element it weaken and it would be the facade. So maybe a more abstract connection would be required for thermal data. Also it doesn't change that we need to determine the class of the realizing element (RealizingElements). |
I am kind of lost in this conversation. Can someone be some kind to clarify to me what the SupportType and ThermalBrake enums are? |
Raised by ugogreco and agron here, and also personally experienced by myself in residential projects.
As a precedent, PredefinedType already includes "LANDING", which is quite specific.
Ping @berlotti @TLiebich @aothms
The text was updated successfully, but these errors were encountered: