Proposal to add "BALCONY" as a predefined type for IfcSlab

[Moult]

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

[aothms]

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?

[Moult]

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.

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.

[TLiebich]

support @Moult on this - a balcony slab is differentiated from other slabs by being overarching and requires thermal isolation from the main slab. So it is often handled separately. What @aothms refers to I would call "balcony unit" that can well be represented as IfcElementAssembly.

[aothms]

If everybody agrees this is a quick win towards a real use case I wouldn't keep complaining, but:

requires thermal isolation from the main slab

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.

being overarching

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.

[Moult]

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.

[Jesusbill]

I am more with @aothms on this, I see it as a .FLOOR. element as well. And although the arguments made that differentiate balconies from the rest are valid for some or even many cases, that is not the case for all. To me it is common that an internal slab extends as a cantilever.

[agronid]

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 Balcony is not quite appropriate, because it is very precise about the function? In most cases, we are dealing with cantilever like structures, that serve as a balcony, but it could also be a part of an outside corridor like here. Or it could even be a prefab slab on the last floor as a cantilever element and not surve as a balcony, such as here. Link corrected

Maybe the TypeEnumeration for a slab would be: CANTILEVER - a horizontal extended structural element that is fixed on one side and is capable to withstand shear and bending moments. Its purpose could serve as a balcony or simply a cantilever structure connected to a slab or wall.

This could also solve the case where ugogreco was asking about this entity here.

[Moult]

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.

[agronid]

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?

[TLiebich]

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.

[aothms]

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?

[CyrilWaechter]

I don't think IsExternal is enough to make sure of what it is: Thermal break is a thing but there is also shading, rain water management etc…

Case1: balcony is part of the main slab so no thermal break. No specific predefined type Case2: balcony is not part of the main slab so you probably want to add thermal breaks. Having a specific predefined seems useful.

About definition nothing in ISO 6707-1 or another one ?

[berlotti]

ISO 6707:

3.2.2.9: balcony upper accessible platform within a storey (3.2.1.2), not fully enclosed by walls

3.2.2.10: external balcony accessible platform that projects from the external face of a building

3.2.2.11: internal balcony recessed balcony, US accessible platform recessed from the external face of a building

[Moult]

@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)?

[agronid]

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. I can see that for some this might not be necessary, hence they can use a simple slab definition. But for the ones that need a differentiation from the main slab, this new definition could be helpful. It simply offers flexibility.

[Moult]

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

[agronid]

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). I also believe that a cantilever is a more appropriate term for such structural elements.

[Moult]

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

[aothms]

I also want to reiterate my earlier comment:

is it an idea than that we somehow encode the support mechanism of a slab in a property set?

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.

@CyrilWaechter

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

[Moult]

Discussed with @aothms and @Moult and @TLiebich verbally

Summary of discussion:

• @aothms reiterates that identifying cantilever goes against the current practices of predefinedtype. PredefinedType connotes function, not form. This doesn't mean that identifying a cantilever isn't a good idea, just that it should belong elsewhere outside the PredefinedType
• @TLiebich it's good to know that a slab is a cantilever since it may be treated differently. Unsure if better to store in predefined type or better stored in Pset_SlabCommon
• @Moult kept silent

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

[Jesusbill]

would a similar property be useful for structural usecases?

I don't think it would add much value specifically a SupportType enum, or a ThermalBreak enum I'd say although not my discipline. However, knowing whether this slab is external in both sides over its entire geometry, which seems to be the original intention, can serve in some parts the "structural" and "thermal" logic of setting up the model. But not for the support system specifically as it depends on many factors, it can be an internal slab extending "as a cantilever", it could be two cantilever beams and a simply-supported slab, or an actual cantilever independent slab.

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. So we could try to find another general pset property for this case

[CyrilWaechter]

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

[aothms]

separate object

IfcRelConnectsWithRealizingElements? Or is it not always a 1-1 connection?

[CyrilWaechter]

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

[agronid]

I am kind of lost in this conversation. Can someone be some kind to clarify to me what the SupportType and ThermalBrake enums are? the potential use cases have already been presented in this post. I don't agree though that the TypeEnumeration CANTILEVER for IfcSlab defines a form and not a function. In my opinion, this cantilever that we are discussing has a specific function to fulfill, which is either access for humans (architectural and structural) or as a shading device (building physics). In some parts of the world, such as Austria and Germany, it will be used for Costing use case. By adding this type Enum, we enrich the family of the already existing Slab Enums. Such as all types of Slab (Roof, Floor, Landing, etc.) this is also part of the thick, flat shaped component that is the IfcSlab.