After starting to author my Architectural graphical model last week. This week I have continued its development resulting in a model which while work in progress is starting to really come together!
I was very happy to see that after last week’s blog, a lively debate started on LinkedIn around object naming; as I also had some questions of my own. As you might have saw last week, when I named my walls I did not put the thickness of layers into my subtype. so for example a wall might have been called:
I did this because within BS8541-1, table 1 states that the subtype should not capture attribute data. However, while authoring my model I quickly needed to distinguish between walls with the same build up but different thicknesses.
Unfortunately, Revit doesn’t allow duplicate family names I couldn’t use ‘BBH_SolidWall_PlasterBrickwork’ for walls with the same layers at different thicknesses, so a solution was required.
Initially I described the number of brick skins to avoid recording attribute data within the name, but quickly realised that that was stupid, and I was describing the thickness of the wall, just in a very awkward way. So I was led back to using the thickness of each layer within the subtype.
Now to make sure my reasoning was sound, I decided to ask Twitter. Interestingly (but not very helpful) the majority of people who participated in my poll thought that both options were wrong.
To make matters worse, I added some new objects to my model this week that had to use BS8541-1‘s other naming convention for unclassified objects. Basically, if you are using an object without a classification field then the unclassified object naming convention is required, which is a tad more complex:
- Kitchen worktops;
- Bespoke window sills; and
- Top of small units which also acts as a shelf.
This meant I needed to find out some extra information. We already have my role, in this instance it is Architectural, classification means we need to rely on a Uniclass 2015 table (see example below), we have skillfully skipped presentation, source is my organisation (BBH) as the object creator, type relates to the corresponding IFC type, and subtype will allow me to differentiate between any other similar objects.
Meaning that I named my kitchen worktop like this:
Note: Because of the underscore ( _ ) within the classification codes I have used a hyphen (-) as a field separator which doesn’t comply with the text but does comply with the example provided within BS8541-1. This inconsistency isn’t very helpful, so I have chosen a solution that suits my situation best.
Objects such as kitchen worktops and shelves have been added for a reason. Each of these were needed to accurately reproduce my floor layout, as required to satisfy my next Plain Language Question “What is the Layout of my house?”. So now that they have been modelled, the result is a set of floor plans built into a graphical model that’ll be used for its own purposes as well as capturing what assets I have in order to answer my next Plain Language Question. Once completed I was able to set up suitable views of my floor plans, and transfer them to a title block to complete this deliverable.
And there you have it, after putting in the objects I needed I have now been able to produce a drawing containing my ground and first floor plans which has been derived directly from my graphical model. Using this information I now know the layout of my house; therefore Plain Language Question PLQ2.3 is complete!
2.1 What existing information is available?
2.2 Is there sufficient information to produce a BEP?
2.3 What is the layout of the house?
2.4 What assets are contained within?
2.5 What asset information can be linked to the graphical model?
Now that I have a pretty strong Architectural model, it’s time to start creating some of my other models to record the electrical and mechanical objects…