Let’s look at the “Dimensions” class of BIM object property names in my proposed classification system. Like the crucial “Identification” property class, it should make it much easier to define your information needs and communicate those needs to others – with total clarity.
What you have is a standardized list of Dimensions (Class “D”) properties conveniently organized into four sub-classes: Area Dimensions, Geometry, Tolerance and Volumes.
Within each sub-class you have all the specific properties and you can simply choose what’s relevant for your BIM model (in terms of the intended use and the actor who’ll be using it).
Here are the specific “Area” and “Geometry” properties in the “Dimensions” class:
As an example, if my BIM object is a window and I want to do energy analysis, what I need is the window’s area. So I should include (or request) the DAC property (Area), but not DGH and DGW (height and width) – which are irrelevant for our intended BIM model use.
On the other hand, for 3D coordination I will (only) need the external dimensions of the window or other BIM object, basically for clash detection. So I should include the properties DGH and DGW (Dimensions-Geometry-Height/Width), but here I don’t need area (DAC).
It’s that easy to take an efficient “set-of-information” approach to doing BIM: give, get and request just the right information at every step, with clarity about exactly what’s needed and not needed.
Here are the “Tolerance” and “Volume” properties (the other two “Dimensions” sub-classes):
It’s all about the BIM model uses and the related information needs of the actors involved. For energy analysis, I need a room’s volume. A contractor needs the volume of bricks in a wall to plan masonry work, and the volume of a floor to bring the right amount of concrete to the site. A cost consultant also mainly needs the volume of materials, or number of units and so on.
What types of tolerance specifications are needed, if any, will also very much depend on the intended BIM model use. It’s nice to have a list of the possibilities, so I can just choose the one I need. And when it’s a standard list, then everyone else will also know exactly what I mean.
Forgive me for repeating myself, but it’s a crucial point: classification like this, instead of using custom properties, strengthens BIM model transparency. It means stable coding over a building’s lifecycle, across projects, and potentially across the industry. We get the same parameters everywhere, with the same names, understood the same way, and easily translated.
In short, it enables efficient information exchange.
Related posts:
It’s time to standardize BIM object properties!
BIM object property names: 1st-level classes (and their usefulness)
