@Moult said:
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)
-
Insitu Concrete - N32 - Broom Finish
-
Precast Concrete - N40 - Trowel Finish
-
Mild Steel HR - 300MPa - Black
-
Mild Steel CF - 450MPa - Duragal
-
Softwood Timber - MG12 - T3 Green Plus
-
Hardwood Timber - F17 - Rough Sawn
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.