Developing a standardised and automated approach to IFC data fields


Many users of BIM authoring tools are still focussed on producing the same deliverables they have always produced but in a more efficient way. This means that even if they have adopted an approach to producing data much of it will be focussed on native data fields within their chosen authoring tools. This is fine if the only output is a drawing or a schedule but if others want to use your data for other purposes in a consistent manner on every project, irrelevant of who the model author is, then we believe data needs to be built around a common open standard.

In BIM terms the obvious data standard to align with is IFC (ISO 16739:2013) which is an open international standard developed by buildingSMART International. The current release being used in practice is IFC2x3 (IFC4 is now ready for implementation by the vendors so we are likely to see this implemented fully over the next couple of years). Some other reasons though to create an approach to standardising data fields:

  • To automate data from geometry wherever possible, reducing opportunities for errors with manual input
  • To collaborate with other model authors without the need to map data between platforms or even authors using the same tool
  • To provide consistency for all tools and objects, across all project files and ultimately across all projects
  • To allow model checking to be built around a single consistent standard
  • To deliver COBie and the requirements of BS 1192-4:2014 efficiently and effectively (required for centrally funded UK government projects from April 1st 2016 for “Level 2 BIM” projects)
  • To allow consistent scheduling of data fields across a variety of modelling tools
  • To not need to rely on all imported geometry to have consistent data fields
  • To create a single approach to where data is created making training simpler for staff
  • To develop a business around “OPEN BIM” that is more than just sharing geometry and/or unstructured data
  • To divorce the silo mentality around authoring tools
  • To future proof a business approach to data around an open standard

In ARCHICAD we have the ability to focus on IFC data by using ARCHICAD’s IFC Scheme Mapping. I’ve written before on this subject in “ARCHICAD 18: Join the IFC and COBie flow – Part 2 – Data mapping“. Having implemented this mapping 18 months ago we have seen projects taking advantage of this process. This implementation has now allowed us to understand better how people use this and work out ways to further automate our approach. This means we can continue to improve on our approach to structured open data.

This blog piece starts off by showing an example with and without mapping and then examining our approach to standardising key data fields. We finish by showing some examples of this data as outputs and some thoughts about the future of standardised data fields.

Example scenario

I have selected a very simple scenario to demonstrate the need for mapping. Here we have used ARCHICAD 19’s out-of-the-box “Bar Stool 19” object.

We have placed the same size object (400 long x 400 wide x 815 high) but each with a different Style associated. There is 1 of Style 1, 2 of Style 2, 3 of Style 3, 4 of Style 4 and 5 of Style 5. This is 15 instances (or Components/Elements) in total.

Screen Shot 2015-08-12 at 09.20.41

Image: Bar Stool 19 object placed in ARCHICAD 19 [Click image to enlarge]

Without mapping

Here is an example of how the out-of-the-box objects created above work without mapping:

Screen Shot 2015-08-04 at 09.59.37

Image: ARCHICAD Component data [Click image to enlarge]

The Name in this case is unique as each one was placed. However if we duplicate any of the objects the IDs lose their uniqueness (a weakness of ARCHICAD). No Description for the object is automated with the out-of-the-box template and there are no placeholders or other linked values.

Screen Shot 2015-08-04 at 09.59.47

Image: ARCHICAD Type data [Click image to enlarge]

The 15 placed objects all appear as a single Type with the Type Name using only the Library Part Name. No other values for the object are automated with the out-of-the-box template and there are no placeholders or other linked values. On the whole the out-of-the-box template solution is pretty dumb.

So without mapping the out-of-the-box scenario is going to give us a number of issues. In the UK this approach won’t deliver COBie but setting that aside the more important thing is to realise that this won’t allow you to export your model for reliable quantification. A cost consultant or contractor would assume you have 15 of the same bar stool. The cost for each of these may be different so we need to create uniqueness for each different Type for quantification, a well structured IFC and in the UK of course for COBie.

With mapping

Taking the same objects but applying the IFC mapping we have developed we get the following results:

Screen Shot 2015-08-12 at 09.56.35

Image: ARCHICAD Component data [Click image to enlarge]

The Component Description is fully automated from the geometry selected by the user. Placeholders are also created for COBie Component data (AssetIdentifier, InstallationDate, TagNumber, WarrantyStartDate, BarCode and SerialNumber). Only the ID (mapped to the Component Name), and in some cases the Classification References (a large amount can be pre-setup in Favorites), needs to be managed by the user.

Screen Shot 2015-08-12 at 09.56.25

Image: ARCHICAD Type data [Click image to enlarge]

The crucial difference here compared to the out-of-the-box scenario is that the 5 different Types each have a unique Type Name. This means that these can be used for the COBie Type sheet but also we can use these Types to develop an approach to quantification.

Developing a mapping ‘standard’

Whilst there is a standard data structure for both IFC and COBie many of the fields don’t expressly explain how to complete these fields. This is left to the user to determine. In my opinion there are 3 key fields when it comes to building an approach around IFC. These are:

  1. Component Name
  2. Component Description
  3. Type Name

Everything else stems from these three pieces of data so if you can get these right the rest can be developed around these.

Component Name

The Component Name should be thought of as a unique number for each element/component in the model. In its simplest form in ARCHICAD this could just be the ID field (as the out-of-the-box solution provides). Our approach though for Component Name also includes information about the element type. So the mapping is as follows:

  • IfcElement (manual text except for Covering, Roof and Slab)
  • (colon as static text)
  • <Full Element ID>

So the mapping for example for an IfcDoor is “Door:” where Door is a piece of manual text. So as an output this might look something like: Door:GF01-D1

The primary reason for putting the element type in the field was to make the COBie Component sheet more straightforward to understand (all Names must be unique to be COBie compliant) and allow us to breakdown our ID management into manageable packages. This means we can use ARCHICAD’s Element ID Manager to ensure Component’s have unique IDs based on their Element Classification.

Component Description and Type Name

For the other two fields our approach is to make them similar. I say similar as they are not absolutely identical due to the fact that the element classification varies at Component (IfcElement) and Type (IfcTypeProduct) level. This creates a consistent linkage between the two fields.

We have loosely based our approach on BS 8541-1:2012. BS 8541 covers object naming standards but we have used a similar approach for Component Description and Type Name. The standard allows objects to be named in 2 ways. These are:

  1. Source_Type_Subtype/product (see BS 8541-1:2012 4.3.2 Figure 2)
  2. Role_Classification_Presentation_Source_Type_Subtype/product (see BS 8541-1:2012 4.3.3 Figure 3)

BS 8541-1:2012 does actually show an example of a Type Name (Table A.2; Page 9). This is shown as: MyCompany MC999 Basin 470w x 300d. This obviously includes spaces and no underscore separators. Unfortunately there is no further detailed explanation about the Type Name within the document.

BS 8541-1:2012 also requires that special characters are not included (i.e. • ,. ! “ £ $ % ^ & * ( ) { }[ ] + = < > ? | \ / @ ’ ~ #¬ ` ‘) so we have excluded these from our mapping, naming of library part objects and Building Materials.

Component Description

Broadly speaking our mapping for Component Description is made up of the following fields:

  1. IfcElement (static text except for Covering, Roof and Slab)
  2. (underscore as static text)
  3. Position
  4. (underscore as static text)
  5. Library Part Name ** or Building Material / Composite / Profile / Fill
  6. (underscore as static text)
  7. Style/Type (for certain Library Parts only – see section on object style/type mapping below)
  8. _ (underscore as static text)
  9. LengthxWidthxHeight or WidthxHeight or LengthxHeight or Thickness or Height (where ‘x’ is static text)

E.g. FurnishingElement_Interior_Bar Stool 19_Style 1_400x400x815

** It is not currently possible to remove spaces from out-of-the-box objects with mapping or other ARCHICAD approaches.

Type Name

Our mapping for Type Name is made up of the following fields:

  1. IfcTypeProduct (static text except for Covering, Roof and Slab)
  2. _ (underscore as static text)
  3. Position
  4. _ (underscore as static text)
  5. Library Part Name ** or Building Material / Composite / Profile / Fill
  6. (underscore as static text)
  7. Style/Type (for certain Library Parts only – see section on object style/type mapping below)
  8. _ (underscore as static text)
  9. LengthxWidthxHeight or WidthxHeight or LengthxHeight or Thickness or Height (where ‘x’ is static text)

E.g. FurnishingElementType_Interior_Bar Stool 19_Style 1_400x400x815

** It is not currently possible to remove spaces from out-of-the-box objects with mapping or other ARCHICAD approaches.

Ideally Type Naming would be fully human readable. This is particularly true for COBie. For example it would be better if the Type Names were Bar Stool Type 1, Bar Stool Type 2, Bar Stool Type 3 etc. Whilst this can be achieved manually it simply isn’t currently practical or achievable with an ARCHICAD workflow because Type data can not be preconfigured.

Excluded data from Component Description and Type Name

We have played around with various configurations but found that the above approach makes the most sense particularly when you start to schedule the data both in ARCHICAD and in other tools.

We deliberately omitted the following out of the Component Description and Type Name:

  • Role – some would suggest including A for example for Architect would be useful in the naming strategy but because we also integrate other disciplines such as Interior Designer (I) and Landscape Architect (L) into our templates the automation wouldn’t work for us.
  • Classification – we use ARCHICAD’s Predefined Rules (IfcClassificationReference) so this is not included within the naming strategy but is included within an IFC and/or COBie output.
  • Type of information – this would be for example M2 for 2D geometry and M3 for 3D geometry. For IFC exchange the only thing being exported is 3D geometry so there is little point including this in a naming strategy.
  • Source – this would be the library author or manufacturer. BS 8541-1:2012 doesn’t require this for object naming for generic objects so we have omitted this.
  • Renovation Status – at the end of the project the model will be handed over to the client and essentially everything becomes “Existing” so is not included.

Object style/type mapping

In order to create uniqueness for objects the style/type information is critical. This is clearly demonstrated in the previous example showing the bar stool objects. In ARCHICAD 19 a new feature was added to allow the user to choose one parameter from one object and then map this for all other objects using the same field. Great, i hear you say! Yes that’s what I thought too. Sadly though very few of these parameters are actually the same for any of the out-of-the-box objects.

So for example chair objects have parameters like the following: gs_chair_style, gs_chairStylegs_seat_style, iChairModelStyle or iChairType. As these vary mapping has to be done to create Component Descriptions and Type Names for every variant.

Of course before mapping the consistency of GDL parameter naming didn’t matter so much but now that data becomes more important to architects and beyond there needs to be a greater consistency to how data is created. I’m sure changing this in the out-of-the-box library is no easy task for Graphisoft but some work is definitely required in this area going forward.

So in short you have to create endless amounts of mapping in order to fully automate the Component Description and the Type Name. To say this is tiresome and liable for user error is an understatement. I almost lost the will to live with this one. Of course users won’t see this pain but even now i’m not 100% I caught everything as searching for the correct parameter was so much hard work.

Output Examples

Of course the main purpose of creating the IFC Scheme mapping is to provide a consistent and high quality data output. Here are a few examples.

This is how the information appears for quantification scheduling in Solibri Model Checker:

Screen Shot 2015-08-12 at 09.59.21

Image: Furniture Components shown as an Information Take-off in Solibri Model Checker v9.5 [Click image to enlarge] Note: the colouring shows each Component to be different

Screen Shot 2015-08-12 at 10.01.45

Image: Furniture Types shown as an Information Take-off in Solibri Model Checker v9.5 [Click image to enlarge] Note: the colouring shows each of the 5 Types placed in the original ARCHICAD model

This is how the information appears for quantification scheduling in ARCHICAD:

Screen Shot 2015-08-12 at 10.12.01

Image: Furniture Component information (COBie 2.4 data plus Classification/Category shown) shown in an Interactive Schedule in ARCHICAD 19 [Click image to enlarge]

Screen Shot 2015-08-12 at 10.13.32

Image: Furniture Type information shown in an Interactive Schedule in ARCHICAD 19 [Click image to enlarge]

This is how the output of this mapping appears in a COBie spreadsheet output:

Screen Shot 2015-08-12 at 09.49.55

Image: Component Sheet shown in Solibri Model Checker v9.5 [Click image to enlarge]

Screen Shot 2015-08-12 at 09.50.48

Image: Type Sheet shown in Solibri Model Checker v9.5 [Click image to enlarge]


I often hear from others that small companies don’t need to use this approach. They don’t see the value and would rather focus on their native authoring tool. I also hear that companies are waiting for the tools to get better before tackling this. For me this is all short sighted and really a cover story for a fundamental fear of change. If you have a genuine desire to change your business to a digital-centric business rather than an analog-centric business then why put off till tomorrow what you can do today? The ability to create automation and better information is already here. If you don’t do it, your competitors probably will!

That said, developing a mapping approach takes considerable thought and time. I’m talking days/weeks not hours. It also needs to be tested on real projects and then finessed to iron out any unforeseen issues. However mapping to IFC offers a real opportunity for standardisation, automation and the production of high quality valuable data. In my opinion the time to create the mapping is far outweighed by the benefits it will bring to all our/your projects.

Of course our approach is not an industry standard, as one doesn’t appear to exist, but we believe sharing our approach may prompt others to consider developing some form of standardisation even it differs from our own approach.

I believe an industry standard would be particularly useful when federating data from other disciplines and providing a single consistent output for handover to Facilities Managers. It would also assist others receiving data to understand the logic across disciplines particularly where 5D approaches are adopted.

We may well adapt and change our approach further over time and with more learning experiences from projects but for now this will become our ‘standard’ approach.

Rob Jackson, Associate Director, Bond Bryan Architects


Terms and conditions

All content provided on this BIM Blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. Bond Bryan Architects will not be liable for any errors or omissions in this information nor for the availability of this information. Bond Bryan Architects will not be liable for any losses, injuries, or damages from the display or use of this information. 

We are happy for others to share our blog pieces through all social media platforms. You may include links to the original blog pieces and use part of the blog to then provide a link to the original content. However we would appreciate it if the content is not reproduced in full on other sites or publications without written consent being granted by Bond Bryan Architects.

This policy is subject to change at any time.

5 thoughts on “Developing a standardised and automated approach to IFC data fields

  1. Hi Rob,

    Very useful blog piece as always. Could you please elaborate on why you have chosen to use manual text (which I presume is mapped in the scheme) and not the Element Classification for generating component names? I am just thinking of a situation when a user uses a tool (e.g. the Column tool) to model something different than a column (e.g. a table leg) or when a user uses the Morph tool to modela piece of furniture. If they change the Element Classification correctly, then this will appear correctly in schedules/COBie outputs if the Element Classification is used to generate names. How do you deal with situations like these when using manual text?

    I always meant to say thanks for sharing all these with the industry.


    • Hi Pantelis,

      The reason it is manual text (where it can be) is because of ‘ArchiCAD Type’. With the methodology I describe it means you can still use ‘ArchiCAD Type’ but also use any tool for whichever Element Classification you need. So your examples would work for naming and scheduling if a Column was simply left as ArchiCAD Type or any other element was used as a Column.

      ‘ArchiCAD Type’ is important for objects as it can drive the Element Classification at Type level. See my other blog pieces on Element Classification.


  2. Rob,
    How do you get around the individual ID issues when using repetitive modules? We are trying to set up office standards right now and the more we take things like modules into consideration, the more fields we feel compelled to add.

  3. Rob. Very interesting reading. Was wondering how you deal with models which contain repetitive modules (WCs, etc).

    We have in the past used the ID / parameter manager to include reference to individual ArchiCAD Zones (Spaces in COBie) within for example a door’s ID.

    In your experience would this be the best way to include an individual ID within the master / federated model for all elements within a repetitive module situation? In other words to ensure you don’t end up with multiple elements with the same ID within the model nd therefore COBie?

Leave a Reply

Your email address will not be published. Required fields are marked *

4 × four =