Closed Moult closed 2 years ago
I think the hard rule we all agree is that a structural column is load bearing and a non load bearing column is not structural.
I am not sure, probably due to limited experience, what do we mean by architectural column in the IFC context. A column that the architect defines that may or may not have a structural function or a "decorative" element that is de facto a non load bearing element?
Depending on the response I would unite the last two phrases of @Moult 's proposal to read either
... member from an architectural point of view which may or may not represent a non load bearing element
or
... member from an architectural point of view in which case it represents a non load bearing element
I would not include the part on grid intersection. I don't think it's a necessary or sufficient condition (but I'm not a structural engineer, I could be wrong).
For the load bearing part I would more explicitly connect this to the LoadBearing property. So that it's clear how this is expressed.
In general though, the element labels are hard and can also sometimes vary based on scope, level of development and context. Things like pilasters could be IfcFeatureAdditions on a IfcWall for example, or an IfcColumn. An architectural mirror image of a structural column could be a IfcCovering or a IfcColumn. I think it may help if we build a vocabulary of these "gray zone" usage patterns and discuss those (or even include them in the docs). And once we have consensus on those, try to phrase that in the definitions.
I think the grid intersection makes sense, the column positions and grid layout are highly correlated on most projects I've come across.
I did a quick search online for non-structural columns and came up with stuff like this and this and this. I personally have never included architectural columns in a design, but I can see why it exists, and would probably belong to IfcColumn - I can't think of an alternative.
Therefore, the PredefinedType=COLUMN definition may also need changing to accommodate these standalone decorative columns.
Here are the revised proposals, considering @Jesusbill and @aothms comments:
IfcColumn is a vertical structural member which often is aligned with a structural grid intersection. In most cases it represents a vertical, or nearly vertical, structural member that transmits, through compression, the weight of the structure above to other structural elements below. It represents such a member from an architectural point of view. In other cases it might also represent a non load bearing element.
A column is an essentially linear vertical or nearly vertical member. It’s typical function is to transmit structural loads by axial compression. However, it may serve other structural or architectural purposes.
A small amendment to @agronid's already modest proposal:
IfcColumn is a vertical structural or architectural member which often is aligned with a structural grid intersection. In most cases it represents a vertical, or nearly vertical, structural member that transmits, through compression, the weight of the structure above to other structural elements below. It may also represent such a member from an architectural point of view in which case it represents a non load bearing element. Whether it is a structural load bearing element or an architectural non-load bearing element is determined by the Pset_ColumnCommon.LoadBearing property.
Change PredefinedType=COLUMN definition to read: A usually vertical member that can be required to be load bearing and requiring resistance to vertical forces by compression but also sometimes to lateral forces.
@Moult Your description makes more sense now compared to what actually the IFC structure describes.
The suggestion for the PredifinedType is also better.
Nothing more to add...
Awesome! In that case we can potentially narrow this down to two proposals :) Thoughts, @aothms @Jesusbill ?
This is potentially an easy docfix, so bump @aothms @Jesusbill @TLiebich can we get some closure on this?
@Moult Proposal 3 looks good to me
It may also represent such a member from an architectural point of view in which case it represents a non load bearing element. Whether it is a structural load bearing element or an architectural non-load bearing element is determined by the Pset_ColumnCommon.LoadBearing property.
It's definitely an improvement, but I find the direct equation of "architectural point of view" and "non load bearing" (how do you spell that) somewhat unnecessary. What are you saying in this case: is it a purely decorative element unrelated to a structural column or is it ornamentation around a structural column? In the latter case one could also argue that the structural column and the architectural finish around it represent the same element just from the viewpoint of another discipline and I find it somewhat harsh than the architectural view in your proposal cannot be enriched with the structural function.
If you don't want load bearing columns in your architectural discipline model I think that should be territory of information delivery specifications, I would try to soften the wording in the spec itself.
I would propose:
It may also represent such a member from an architectural point of view in which case it may represent a non load bearing element. Whether it is a structural load bearing element or an ~architectural~ non-load bearing element is determined by the Pset_ColumnCommon.LoadBearing property.
(may added, 2nd architectural removed)
+1 for @aothms last proposal.
as I see it in practice, in an architectural discipline model columns are included being either load bearing or not, in a structural discipline model ususally only load bearing columns are of concern.
maybe even better:
It may also represent such a member from an architectural point of view in which case it may represent a load bearing or non load bearing element. Whether it is a load bearing element or non-load bearing element is determined by the Pset_ColumnCommon.LoadBearing property.
I'm happy with @aothms 's last proposal :)
The current description is:
The first half of the paragraph talks all about structural attributes, whereas the second half talks about architectural "fake" columns.
As described by @agronid in this thread, at least 6 forum members have found this description confusing.
Here are the proposals to fix it:
Proposal 1 by @agronid
Proposal 2 by Lighthart
Proposal 3 by @Moult
A small amendment to @agronid's already modest proposal:
Thoughts? Ping @berlotti @TLiebich @aothms @Jesusbill @krande @jmirtsch