After looking at how I will be Bridging the Attribute Gap, I have now started to finish populating my graphical models to satisfy my graphical and information requirements. However, a practical problem has appeared which I wanted to share you with around type naming.
A while ago, I discussed good practice around 3D Modelling & Object Naming, this related to the file name (how you would find that file in a folder) using BS8541-1 to the point that I am able to use pretty effectively name all of the objects (that Revit allows me to rename). What we didn’t discuss is type naming, now Rob Jackson of Bond Bryan talks about it much more detailed in his blog here, but put simply an object’s type name also needs thorough consideration. However, as I didn’t properly consider them a problem has been brought to my attention; let me explain.
Shown above are the different door families in my home. Each family has a unique name and happen to only require a single type which I have named following Revit’s guidance for type naming through using a dimension-based type name. Meaning that the family and types names are as follows:
- BBH_Door_TwoPanel; and
Can you spot my problem yet? No, neither could I at first.
The way families & types work in Revit means that an object’s type isn’t necessarily unique. This isn’t a problem in Revit, but can be a problem when exported into other tools and systems, such as when I export into COBie.
Ideally an objects type should be unique and human readable so that it is clear which object is being referred to. To do so, I can see two solutions:
Family & Type
The term type can be a misleading one. In BS1192-4, type is defined as the named specification for components which means that using ‘Revit Speak’ both the family & type constitute the object’s type. This means that if I could export the object’s type as <<Family>>:<<Type>> I would have a unique reference for each type. However, while this isn’t supported by the IFC Exporter it is supported by the COBie Extension for Revit which solves the problem for COBie, but means that there isn’t a supported solution for any other exchange method, such as IFC.
A more practical solution then may be not to describe the size of the object but instead give it a name that is easier to understand. Both Revit’s guidance and the definitions within the IFC Schema refer to what I call the ‘<<Type>>N’ method, for example using a type name such as DoorType01 to describe each object’s type. For a scheme like mine (without any design) this can be easily applied, but for a more iterative project an issues can occur if a Type becomes redundant during the development of the graphical model.
So let’s give it a go.
This method doesn’t change how my doors are set up in my model but provides two advantages. The first is that when this information is exported into COBie there is no duplication which means that it is clear which type is which.
There is another advantage too. If a dimension-based type name is used then there is a chance for error due to the manual input as well as the need to update the name each time a change to the object occurs. Using a name such as DoorType04 mitigates these potential issues.
And there we have it, by considering how I name my types, each type now has a unique reference that doesn’t duplicate other data and is less prone to error. This means that once I have replicated this throughout my model I will be well on my way to completing PLQ2.5!
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 know how to resolve my types it’s time to explore my other attributes so that I can capture all my required metadata. But first I want to tell you about my year with Nest…
5 thoughts on “PLQ2.5 – Type Trouble”
Good read…..its a Shame that a ref voykdntvalso include clues to type such as FDFPG fire door four panelled glazed, and perhaps add PF SW or WV for Paint finished, Solid Wood, wood veneer .
Yes, that could potentially work, but I am against repeating objects properties in the name as it increases the possibility of user error.
For example, what happens if you prefix with WV but during the project value down to a painted finish (PF), you would now have to modify the object and it’s name duplicating your workload to amend your objects risking that you only alter the finish and not the name (or vice-versa)
[…] PLQ2.5 -Type Trouble […]
[…] PLQ2.5 -Type Trouble […]
I found just what I was needed, and it was entaetrining!