-
Notifications
You must be signed in to change notification settings - Fork 82
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 make the description of IfcColumn less self-contradictory #47
Comments
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
or
|
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: Proposal 1 by @agronid
Proposal 2 by Lighthart
Proposal 3 by @MoultA small amendment to @agronid's already modest proposal:
|
@Moult 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'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:
(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
The text was updated successfully, but these errors were encountered: