Predefined Types
I have noticed with Predefined Types Slab/Floor Slab, that the Types are written in ALL CAPS, ie FLOOR SLAB. Is this a legacy thing or an IFC requirement? Also noticed in many cases these also have underscore separation ie FLOOR_SLAB.
Is it a bad idea to edit these predefined values to have upper and lower case and to remove Underscores?
Comments
see this site https://bonsaibim.org/search-ifc-class.html My opinion is to stick to the standard
Predefined types are defined by the schema. IFC defines these as uppercase. Most have no separation between words but a minor few have underscores. Therefore to he valid you have to follow this.
If you have a userdefined type, its not required but I personally encourage to follow this convention.
This convention is probably inspired by enumerations and constants traditionally being uppercase in software. This is also the representation in STEP which heavily influenced IFC.
Maybe @aothms knows more.
Is this correct method? Specify 'USERDEFINED' the use 'ObjectType' Concrete Pad Footing?
Its correct but id say bad practice. Firstly, concrete is not required since you can specify that using a material assignment. Also PAD_FOOTING already exists as a standard so why invent your own? Also why classify it as an occurrence? Better classify the type, then all occurrences will inherit it. Also the capitalisation doesn't follow the standard convention.
Ahh... ok. It seems if I have an ObjectType specified it automatically updates the Predefined Type to USERDEFINED. If I use the Description field it will allow me to retain the PAD_FOOTING type and have a description.
The reason behind the lower case is that is how we label in documentation now, so I will eventually need a field that will be used in the documentation to label the object. Gone are the days of FULL CAPS FOR EVERYTHING.
Our material fields are also expanded (due to current software model authoring tool limitations), so we don't just call something Concrete, Steel or Timber, we specify 3 categories at once and concatenate , for example:-
Material Assignment (Projective Coating Systems are denoted separately)
This might mean that we need to reverse the concatenation, or just leave with the concatenation until such time as we are use Bonsai exclusively for model authoring.
For our discipline (Struct), we have several levels of labelling for objects.
Engineering Docs
Mezzanine Support Beam - 300PFC
Mild Steel - 300MPa - Black
Paint System Type 1
Fabrication Marking Level Docs
Mezzanine Support Beam
(01ASS-0101)
Fabrication Assembly Level Docs
Mezzanine Support Beam
(01ASS-0101)
Fabrication Single Part Level Docs
Mezzanine Support Beam
(01BE-0108)
I foresee a long journey to get our structural workflow pulled into shape and automated to be viable for clients.
The Predefined Type concept is for classification (i.e. filtering, categorisation). If you wish to describe your object (e.g. in a schedule or labeled in documentation) then the Description attribute (or Name, if that's how you identify it) is where you should put it.
When I say material, I'm specifically referring to the Category attribute of a material, not the name of the material. So from what you describe, you should have a material with name N32, description "Broom finish in-situ concrete", category "concrete". The categories are standardised.
Gotcha, that makes perfect sense. I will add that to my to-do-list of things to fix once I have a file into Bonsai. I am starting with getting my Spatial Structure setup correctly, then moving on from that as a foundation. I do look forward to the day that I have all my systems in place so I can use Bonsai as my design authoring and documentation tool.