PLQ2.5 – Bridging the Attribute Gap

Hello BIMfans,
After completing another Plain Language Question last week when I considered what components should be excluded from my model when I create my COBie.  This week, before properly considering two aspects:

  1. Where best to store and manage the data; and
  2. What’s missing.

By doing this, I can clearly define the data gap that’ll allow me to complete my information model; surprisingly, I am a lot closer than I had thought.

By defining my data deficit, it’ll allow me to focus on building the right data to bridge this gap

Where best to store and manage the data?

Now it is worth pointing out that I have already put a lot of consideration into what attribute data I want to capture.  I did so by defining my Model Purposes, which led to the definition of my Data Requirements.  Which helped filter down the information I want to capture.

This process has helped keep my data muscular and compact, like corned beef.

This information will be stored in a number of locations.  The files themselves will be held on my Google Drive while some information will also be transferred into Chimni.  To exchange this information out of my information model into Chimni, COBie will be my method of choice.

Now through this process I am generating three kinds of container (files holding data): Graphical data (2D & 3D models), Non-graphical data (Schedules & COBie), and Documentation (Reports, & Drawings).  When I need to amended this information however it will almost be exclusively through the graphical data.  There are two main reasons for this:

  1. Most of my non-graphical data & documentation are originated from my graphical model; and
  2. Documentation are created in a locked format (such as PDF) making their management difficult, while non-graphical data are either used as reference (such as Schedules), or for the transfer of information between applications (COBie).

Note:  There are many articles online that criticise COBie as a means to manage data; they have however misunderstood how COBie is meant to be used. COBie is the vehicle to transfer information either into a more user friendly format (everyone knows excel), or into another application where it can be managed effectively.  While you COULD use COBie to manage your data, it is just as fit for purpose as a BMX is for competing the in the Tour de France.

I’m winning!

What’s Missing?

So what attribute data am I missing?  Well, what attribute data did I ask for?  Looking back at my Data Requirements and what is written in my Employer’s Information Requirements (EIR) I asked for sufficient attribute data to comply with BS1192-4 (COBie), and a number of additional properties to suit my model purposes.  So let’s see what we have already successfully managed to capture.

Note:  I could have fixed a number of these issues before this weeks post, but I chose to highlight the current gap as opposed to present a ‘Blue Peter’ solution.


Nativity there isn’t sufficient support within Revit for ‘Contacts’.  Therefore not much of information I require is being exchanged.  Currently the following fields require attention:

Category: remains as ‘n/a’;
Phone: remains as ‘n/a’;
OrganizationCode: remains as ‘n/a’; and
Street, PostalBox, Town, StateRegion, PostalCode, and Country: remains as ‘n/a’.

From a contact point of view I need to investigate the best way to manage this information either through a plug-in, or through an external database. – Score: 10/19 = 52%

Note: It is worth noting that the COBie extension for Revit is able to capture this contact information, but is not being used due to my desire to follow a more open approach.


By completing the ‘Project Information’ settings within Revit & the IFC exporter plug-in, the majority of information I require is being exchanged.  Currently the following fields require attention:

SiteName: Cannot rename the Site system family in Revit to comply with BS8541-1;
CurrencyUnit: remains as ‘n/a’;
AreaMeasurements: remains as ‘n/a’;
Description: defaults to ‘BuildingName’;
ProjectDescription: defaults to ‘ProjectName’; and
SiteDescription: defaults to ‘SiteName’.

From a facility points of view I need to investigate why the description fields are defaulting to the ‘___Name’ properties, and look into a plug-in that’ll allow me to rename system families, as well as how to capture the house’s EPC value – Score: 16/22 = 68%


By completing the properties associated to my ‘Levels’ within Revit, the majority of information I require is being exchanged.  Currently the following fields require attention.

Height:  remains as ‘n/a’.

From a floor point of view I need to investigate what is the best property to include to exchange floor height information.  – Score:  9/10 = 90%


By completing the properties associated to ‘Rooms’ (or Spaces) within Revit, almost all of information I require is being exchanged.  Currently no fields require attention, but I do need to map an occupancy attribute to each space. – Score: 13/13 = 100%


Within my architectural model I cannot attribute ‘Rooms’ to zones; but I can with spaces. So within my mechanical model I did just that and all of the information I require has been exchanged.  – Score: 13/13 = 100%

CORRECTION: I had stated in the original post that the way xBIM had represented the data is incorrect however I have been informed that both single row and multiple row methods are accepted (Thank you Nick Nisbet for letting me know!).


I have already done a lot of work formatting my object types in previous posts, so thankfully all of information I require is being exchanged. Currently no fields require attention, but I do need to populate this data into most of my objects. – Score: 35/35 = 100%


I have also already done a lot of work formatting my components in previous posts, so thankfully almost all of information I require is being exchanged.  Currently no fields require attention, however the description issue is persisting. – Score: 17/17 = 100%

Why description; whyyyyyyyy?


While I do have a number of systems within my house, Revit will only export systems if it forms a closed loop (ie pipework between my radiators).  As I cannot access beneath the floor I have opted not to model on conjecture and have excluded my pipework, as such no systems will be included unless I can find a way to resolve this. – Score: 9/9 = 100%


We have also already done a lot of work formatting my assemblies in previous posts, so thankfully almost all of information I require is being exchanged.  Currently no fields require attention, but I do need to capture a few additional assemblies such as my kitchen cabinets & worktops. – Score: 11/11 = 100%

Connection & Issue

Connection & Issue are an optional tabs (so I’ve efficiently sidestepped them) mostly due to the fact that may of the connecting elements (such as pipework) are hidden from view and thus not being modelled.  Also from an issue point of view the products have already been selected so theses will not be recorded either. – Score: n/a

Spare, Resource, Job, & Impact

These tabs are not related to additional data attributed to my objects but to the operation of those objects, for example my Boiler documentation will recommend maintence (Job) that need to be undertaken and by whom (Resource).  If I inputted this information onto my objects directly they would appear in the attribute tab, there I will need to investigate a way to manage this information through an external database. – Score: n/a


Similar to the tabs referenced above, Revit is not capable at collecting information about related documents.  I do have a number of documents I want to capture (such as my property condition report) so I will need to find a way to manage this data through an external database too. – Score: n/a


Thankfully almost all of information I required around my attributes is being exchanged including the additional attributes I have requested when I outlined my Data Requirements. Currently the following fields require attention:

Unit: remains as ‘n/a’; and
AllowedValues: remains as ‘n/a’.

However due to Revit‘s lack of enumerated value (pick list) support, and poor support of attribute units. – Score: 11/13 = 84%


Finally, there appear to be no issues relating to coordinate information as all the information I require is being exchanged.  Currently no fields require attention however further rigour may be needed as this tab is more difficult to validate. – Score: 15/15 = 100%

So, after considering the attributes I require I am currently exporting 146 of the 164 attributes (including the optional attributes) to comply with BS1192-4, in addition to a number of additional attributes I want to satisfy my data requirements.  If I populate all of my objects following my currently methodology that results in an average compliance score of 89%.  Had my COBie gone to university this would equate to a first!

*Sob* They grow up so fast!

Fantastic, this exercise has helped show where I need to focus my efforts while I also ensure that the right data as been populated into my objects. PLQ2.5 has been successfully scoped out!

Model Generation:
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 where the issues lie, it’s time to explore how to resolve outstanding attributes as well as the best way to manage contact & document information which cannot be recorded within my graphical model. Perhaps I need some kind of external database…


One thought on “PLQ2.5 – Bridging the Attribute Gap

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s