For those of you who know me outside of this blog, you’ll know that I have been quite busy over the last few months getting married, presenting to key stakeholders, and doing some pretty exciting standards work (#HumbleBrag). As such, I haven’t given my information model the attention it deserves. So before I get my cost my preventative maintenance schedule I decided to roll up digital sleeves and have a summer sort out.
So, what do I want to sort out? Well as you know, there are three parts to an information model. The graphical model and its associated renditions (i.e. exports like my IFC files), non-graphical information, and the PDF immutable documentation.
So, let’s see if these previous posts will help me improve any of these parts.
Following a previous post where I created a Google Home object, the electrical model has been updated to include it. In addition, I have also been tweaking each of my graphical models to remove several z-fighting issues (trust me, this is nowhere near as cool as it sounds) to improve how my models export into a VR environment.
Also, around my kitchen, I have updated the materials, altered the component names (see below) to remove a duplicate type name. I have also worked out how to get my sink to cut through the work surface and cabinet correctly (this drove me mad, I ended up having to cut a hole in my worktop to sort it). This brings my kitchen much closer to what has physically been built. Note: In a future post, I will contact Howdens and find out exactly what components were used.
In addition to revising my graphical models, I have also changed how I name my models. Previously, you may have seen on this blog IFC files with the file type ‘M3’ for 3D models. After John Ford asked the question, I agreed that ‘M3’ wasn’t the most suitable and felt that it should be ‘MR’, for model rendition. So, as always, when in doubt I turn to Twitter.
As you can see ‘MR’ was voted the most popular (phew). This makes sense because I use my IFC files to create COBie, not instead of COBie. If I was delivering these files back to a client I’d have used ‘IE’ (information exchange). However, as they are effectively filtered renditions of my native model, ‘MR’ is most appropriate.
Thanks to my previous blog posts I’ve managed to update several areas within my non-graphical information.
Following a post where I collected Naming Conventions, I have now updated the component names to suit. The convention I have chosen to follow is:
- Type.Name: <IfcType>Typenn e.g. WindowType01
- Component.Name: <<IfcTypeEnum>>nn* e.g. Thermostat01
The exception to this rule is when the IfcTypeEnum does not suggest what the component is my itself. For example, only a few people (except losers like me!) would know that ‘Water01’ is a boiler or that a ‘UnitaryControlElement’ is a Thermostat. When these instances occur, I use <IfcType>nn instead giving me ‘Boiler01’ and ‘Thermostat01’ respectively. Note: This also allows me to be pedantic and refer to my radiators as convectors, so win-win!
Following a previous post where I calculated the Return on Investment of producing my information model, I have now incorporated each component’s expected life. The service life of these components will be very useful when calculating my maintenance budget.
Also in preparation for this maintenance budget, I have added (for objects I could google…) relevant replacement costs. This was effectively done by comparing my existing components with their B&Q or Wickes equivalents, leaving those I couldn’t find as ‘n/a’. Despite a few omissions, these costs will help calculate my maintenance budget and have helped fill my COBie files with even more information.
Finally, following the changes to Component.Name, I have updated my drawings as any name changes impact on my door and window tags. While doing so, I took the opportunity to update the logo on my title blocks, as well as include a view schedule on each of my drawing sheets. Placed in the bottom left of my drawing sheets, I now know what views are included on each of my drawings.
And there we have it. These improvements to my information model not only help me achieve my Model Purposes but also help ensure the relationship between each part of my information model. As a result of this Summer Sort out, I have consistent component names across my graphical models, non-graphical information, and documentation; reinforcing the fact that I manage my home through a single source of truth.
Note: If you have any comments regarding my summer sort out, then please let me know either on Twitter, or by commenting below.
Update: Included changed to IFC file naming following a query by John Ford.
2 thoughts on “PLQ 3.3 – Summer Sort Out”
How have you dealt with inclusion of the view schedule in the bottom left-hand corner of your drawings?
Is it a simple filtered schedule (meaning manual input per sheet?), or have you adapted a label with a view name parameter?
I was hoping to add an appropriate label to my titleblock family, or at worse on the sheets on our template
Have spend far too long surfing forums to work this one out. Can you help?
I did mine though a simple view schedule at the bottom of each sheet. Have done it manually, but I’m sure it could be automated through Dynamo.