Embedding Office Knowledge in the Building Information Model

I read an interesting article by Tomislav Zigo a few weeks ago about Building Information Modeling. What intrigued me most was the idea of being able to take a firm’s accumulated knowledge and embed it into the objects in the information model, so that new hires or less experienced staff could take advantage of that knowledge. The article includes a sample file showing how property data could be used to create spaces and objects – in this case, Multi-View Blocks – that “know” whether a particular object belongs in a particular space. The sample file uses a schedule table to list the Multi-View Block objects and report whether the block is “allowed” in the space in which it was placed.

I found the sample file fascinating, but thought that in a file of “real project” size, that using a schedule table might be a little cumbersome. You would likely end up placing all of the objects, then generating the schedule and back-checking for items incorrectly placed. It occurred to me that having immediate, or near immediate feedback would improve the workflow. This seemed like just the excuse I needed to try out Display Themes, a feature added with the 2006 release.

I have posted a sample file of my own, in the Autodesk Architectural Desktop Customization Discussion Group. I chose to set up my sample file somewhat differently than the one noted above. Instead of listing all of the objects allowed in a space in the space style, I chose to list the space styles in which an object is permitted in the object’s style/definition. Either approach works – which is better for you depends upon your workflow and the number of different space styles and other objects that you would be including in your system.

Property Set Definitions
As always when dealing with schedule data, the first step is to establish the needed Property Set Definitions. I used style-based property sets – the out-of-the-box SpaceStyles Property Set Definition for the Style property and the custom LocationCheckStyles Property Set Definition – except for the location property that reads the style name from the space into the object’s property data. In Architectural Desktop 2006, the Location property could be part of the LocationCheckStyles Property Set Definition, but, for Multi-View Blocks anyway, the location grip is coincidental with the Multi-View Block insertion point grip, so it can not be moved independently of the block. I also found, when moving the Multi-View Block from room to room, that I had to use the ObjRelUpdate command to manually update the location property, so I chose to set up a separate, object-based Property Set Definition, LocationCheckObjects, to hold the location property. That does mean that you will need to attach the LocationCheckObjects property set to each object – you could set up a tool to do so, and apply it to multiple objects at once. As the goal is immediate feedback, this is not ideal, but I felt that having to attach the object-based property set once was less onerous than having to remember to run ObjRelUpdate every time a particular object was moved from one space to another. The way the formula is set up, the permission will show as “No” if the LocationCheckObjects property set is not attached, so having permission denied no matter where an object is placed should be a clue that the object-based property set is missing. Perhaps future versions of Architectural Desktop will improve the handling of style-based location properties. Remember, these did not work in style-based property sets at all in previous releases.

The LocationCheckObjects has one property, SpaceStyleName. This is a location property that reads in the name of the style of the space on which the object’s location grip is placed; the setting is shown in the image below.

LocationCheckObjects Property Set Defintion and SpaceStyleName Location Property


The LocationCheckStyles Property Set Definition is set up to apply to all styles and definitions, although in the sample file I only used it on Multi-View Block Definitions. There are two properties, PermissionGranted and PermissionList. PermissionList is a text-type manual property that will hold a list of space style names into which a particular object has permission to be placed. A large, “executive” desk, for example, might include Office_Large in its list, but not Office_Small or any of the Workstation styles, as it would not be appropriate to place a desk of that size in a smaller space. The PermissionGranted formula property is where the heavy lifting is done. The VBScript InStr function is used to search the PermissionList manual property, starting at the first character [the first “1” in the parentheses after “InStr”], for an occurrence of the string in the LocationCheckObjects:SpaceStyleName property. The second “1” in the parentheses tells the InStr function to perform a text comparison, rather than a binary comparison. What that means is that the comparison will ignore the case of the text. For example, “a” matches “A” in a text comparison, but does not in a binary comparison. The InStr function returns an integer value under most circumstances – 0 if the string is not found or a positive integer indicating the starting character position in the target string of the first occurrence of the search string. So the formula tests the result to see if it is greater than zero. If so, then the space style name was found in the permission list and the object is permitted; if not, the name was not found [or there was no style name because the object was not placed over a space], and the object is not permitted. The image below shows the properties in the LocationCheckStyles Property Set Definition, as well as the PermissionGranted formula with sample data that returns a result of “YES”.

LocationCheckStyles Property Set Definition and PermissionGranted Formula Property


By attaching the SpaceStyles property set to each space style and attaching both the LocationCheckStyles property set to each object style or definition [filling in the PermissionList for each style/definition] and the LocationCheckObjects property set to each object, we can identify whether or not a particular object has been placed correctly. Looking at the Extended Data tab of the Properties Palette to find out whether PermissionGranted for each object is “YES” or “NO” would quickly become tedious. Checking a schedule table would be better, but unless you frequently remove objects from the schedule selection set, would quickly result in a schedule table that would be too big to keep close to the items being added. Display Themes to the rescue! Display Themes allow you to override the “normal” appearance that an object would have for the current Display Configuration and view direction, based on property data attached to the object. This should have great appeal for architects, who are, by and large, a visually oriented group.

Display Theme Style
The Display Theme in the sample file keys on the value in the PermissionGranted property. When the theme is applied, objects whose PermissionGranted value is “YES” will display in color 80 [a bright green]; color 10, a bright red, indicates a “NO” value. Objects that do not have the PermissionGranted property attached will continue to display as they do when the Display Theme is disabled.

Display Themes have styles, like other Architectural Desktop objects, and can be created and edited in the Style Manager, under the Documentation Objects category. In addition to the usual “General” tab, where you can edit the style name and description, Display Themes have three other tabs: Display Rules, where you define the display overrides – “Theme Settings” – and under which conditions each is to be applied – “Theme Rules”; Legend Format, where you set parameters for the Display Theme legend; and Legend Display Properties, where you control the visibility and display of the components of the components of the Display Theme legend.

Design Rules
The main work to be done is on the Design Rules tab. For this relatively simple example, there are two Theme settings, one for when PermissionGranted is “YES”, Index 1 in the image below, and one for when PermissionGranted is “NO”, Index 2.

Theme Settings


The hatch parameters in a Theme Setting are only applied if the object has a hatch component turned on. Since Multi-View Blocks do not have a hatch component, the hatch settings have no effect in the sample file and I left them at the initial default values. Note also that I set up the sample Display Theme for on-screen purposes only. I left the Plot Style set to ByBlock, so unless the underlying object was set to plot using the object’s color, the sample file should plot the same whether or not the Display Theme was active. This appears to be the case using Plot Preview; I did not make any actual plots.

The Theme rules here are also quite simple. The LocationCheckStyles:PermissionGranted property holds the value to be shown graphically on the screen. Selecting Index 1 – “Permitted” – in the Theme Settings pane allows you to create Theme Rules for that index. Rule 1.1 states that Index 1 should be applied if the PermissionGranted property is equal to “YES”.

Theme Rules for Index 1 Theme Setting


Selecting Index 2 – “Not Permitted” – allows rules to be created for that index. Rule 2.1 states that Index 2 should be applied if the PermissionGranted property is equal to “NO”.

Theme Rules for Index 2 Theme Setting


Legend Format
Since “YES” and “NO” are the only two values that PermissionGranted can have, the Design Rules are complete. On the Legend Format tab, I set the Title to “Location Check” and the Text Style to “RomanS”, as shown below.

Legend Format


Legend Display Properties
I made no changes to the out-of-the-box settings in the sample file, as shown below.

Legend Display Properties


Adding the Display Theme
I chose to add my display theme by setting up a tool, but you can also type _AecDisplayThemeAdd at the Command: prompt, then select the desired style in the Properties Palette. There does not appear to be a command-line option to select or enter the desired style name. A generic Display Theme tool can be found in the Scheduling and Reporting Tool category of the Stock Tool Catalog. i-drop this tool onto an editable tool palette, then edit its properties to reference the desired Display Theme style. For this sample file, I did not bother creating a source file for the style, but you would want to do so for any Display Themes you expect to reuse in other drawings. Have your tool reference the style in the source file by setting the Style location property, after saving the source file to a location that will be available to all who will use the tool.

LocationCheck Display Theme Tool and Properties


When adding the Display Theme to a drawing, you will be prompted for the “Upper left corner of display theme:”. This is the upper left corner of the legend – pick an appropriate location. Similar to the prompts for a schedule table, you will then be asked to pick the “Lower right corner of display theme (or RETURN):”. If you pick a point, the legend will be scaled to fit between the two points; if you press ENTER or the space bar, the legend will be scaled according to the current drawing scale and annotation plot size as set in the Drawing Setup dialog. Assuming you have left all the display components turned on, the legend will show the title you entered on the Legend Format tab, along with a list of the Theme Settings accompanied by a square or circle showing the color and hatch pattern assigned to that setting. The Display Theme will also be applied to the current viewport. The legend in the sample file is shown below.

Display Theme Legend


By selecting the legend and right clicking, you have access to a context menu that gives access to editing commands specific to Display Themes. Of particular note is Disable Display Theme, which allows you to turn off the display theme without removing it from the drawing. If you select this, a diagonal slash will appear on the legend [if you leave that component turned on], the display changes set in the theme are deactivated, and the menu item changes to Apply Display Theme, which allows you to turn the theme back on.

Display Theme Context Menu


The Results
By activating the Location Check Display Theme, you can get immediate feedback on whether a particular object is permitted in a space when moving or copying an existing object, and nearly immediate feedback when adding a new object that already has the LocationCheckStyles property set attached and PermissionList property completed – all you need do is add the LocationCheckObjects property set. The effect is most dramatic when working live in the file, so I would encourage you to download the sample file and try it out for yourself [if you have the 2006 release of Architectural Desktop – Display Themes do not work in prior versions]. Here are two screen shots of the men’s and women’s toilet rooms, each of which has a water closet, urinal and lavatory Multi-View Block. The first shows the out-of-the-box Medium Detail display, the second shows the effect of activating the LocationCheck Display Theme. The PermissionList property for the urinal does not include any of the women’s toilet room Space Style names, and so the instance of the block in the women’s room turns red, flagging it as “Not Permitted”. The other blocks turn green, indicating that they are permitted in the space in which they are placed.

LocationCheck Display Theme Disabled


LocationCheck Display Theme Applied



Note that this is not meant to be a finished system, only a proof of concept. Using the space style name as the sole determinant may be too limiting in practice; setting up one or more manual properties in a style-based property set attached to the space style would allow you to have certain key words to identify space types without imposing burdens on the naming of the styles. The formula determining if an object is permitted could also be made more sophisticated, perhaps needing to match only part of the style name and/or splitting out the size [small, medium, large] comparison separately.