• image
  • image
13 Dec 2018

IFC (Industry Foundation Classes) – Part 04 – IFC Attributes in Autodesk Revit

In blog post 01 we described what Attributes are and listed the four core ones:

  1. GlobalId
  2. OwnerHistory
  3. Name
  4. Description

1. GlobalId

GlobalId is automatically populated on export by using ID data held in the Autodesk Revit database.

2. OwnerHistory

OwnerHistory is automatically populated and relates back to IfcPerson, I will talk about this in a later blog post.

3. Name and 4. Description

For Name and Description, we have a little bit of work to do to get these as we want them. Remember IFC is a way of transferring information from one place to another. This information can also be contained in a whole manner of deliverables from drawings to schedules to reports. This information will contain names and descriptions of elements. A great example is the humble door; typically, we have plans which show every door number, door type drawings which show what each type looks like, then both the door numbers and door type names are used in the door schedule. This is a great example of coordinated information which we do without even thinking about it. Now we want to refer to the doors in the IFC export by those same names/numbers, so we can then reference back to the other deliverables – so it all matches. By default, Revit uses its own family and type names in the IFC export, in my experience these typically aren’t used on drawings or schedules and are therefore, pretty much meaningless outside the software. Example: ABC_LightingFixtures_Spotlight_FaceBased_RecessedCircular duplicates information within the object’s properties, uses Revit based terminology and it’s too long for drawings. Referring back to the first image from blog post 02 family and type names are an example of what belongs in the Revit environment, their creation is to support the software they are created in (However they should still be named consistently). Fortunately, we can override the default setting so that we can choose what name will be exported for both IFC occurrences and IFC types. For anything IFC attribute related in Revit you must use specify parameters which have been named by Autodesk, as these have been coded into the IFC Exporter. Many people get confused and think that the custom property set mapping file (which you specify in the IFC Exporter) is the magic file which exports everything, this is however only for IFC properties. If there is one thing you should take away from this blog post it should be… To export IFC attributes = Specified Revit override parameters To export IFC properties = Any parameter + the custom property set mapping file (there is an exception to this, but we will cover properties in a future blog post) Please see blog post 01 if you need to remind yourself about the differences between IFC attributes and properties. In blog post 03 we mentioned three of these override parameters (IfcExportType, IfcElementType, IfcObjecttype), I’m now going to mention two more:

  • IfcName
  • IfcDescription

This is where it gets a little complicated as both these parameters are to be used to export to both IFC occurrence and type. Therefore, in terms of Revit they need applying to both instance and type properties. Meaning we need to add two identically name parameters for each. Some of you will now be grimacing at the screen right now and thinking Revit doesn’t allow me to add multiple shared parameters of the same name. Families no, you would have to populate one within the family and one within the project, but within the project you can add both. It’s just that they need to be created within the shared parameter text file first rather than through the dialogue box in Revit. A word of caution since directly editing shared parameter text files is a non-recommended process, always save back up files just in case. Tip: if you want to distinguish between your type and occurrence parameters use the tooltips functionality, currently this is the closet way of adding metadata to parameters. I tend to utilise this for adding the schema, parameter source and description for each of my parameters so I know where each one is from and what it is for. Image: How tooltips are shown in (Project) Parameter Properties dialogue box Following the above you should now have the following four parameters within the model: Now we need to add some values. In Revit we typically use these hardwired parameters for naming/referencing in our deliverables:

  • Mark for naming instances (like door numbers) – we use this as the IFC occurrence name
  • Type Mark for naming types (like door type names) – we use this as part of the IFC type name
  • Description to add a simple short description of the object- we use this value for the description for both IFC occurrence and IFC type

Therefore, the values may already live in Revit, so it’s a question of taking them and duplicating them into one of the new parameters. I hate having to create duplication within models but the way the process works there’s no avoiding it. You could use the override parameters directly for deliverables but to me this doesn’t feel right. Going forward I would love to be able to specify any Revit parameter for export to an IFC attribute, however we are not there yet. There are different ways of taking these values and populating the new parameters, you could use:

  • Dynamo (my preferred method)
  • A bi-directional Excel link add-in
  • …or even manually (I wouldn’t recommend this due to human error)

We mentioned that this process ensures that the IFC information is aligned to the other deliverables. It also means that if you are exporting COBie from IFC you have just completed the Name and Description fields for COBie.Type and COBie.Component, therefore this too matches the deliverables (more about COBie in a later post). IfcName and IfcDescription will populate the names and descriptions of the Element entities in IFC (see the green boxes in the image below), however for the entities highlighted in grey these have subtle variations to the rule. Image: Entities which don’t follow the standard IfcName and IfcDescription rule Each table below represents each of the entities in grey. The tables list which Revit parameters export to which IFC attributes. Think of these attributes as the entry levels ones which should always be populated if that entity exists, this is why I have included a few more. Note that some of these Revit parameters are hard-wired so we don’t have to use an additional parameter.


*Be wary of this when creating titleblocks


Note, you will have to model a small piece of Toposurface and export this to IFC to get this data to export. The new shared parameter SiteName also works for IfcSite.Name however you still have to follow the table for description, which is why I don’t tend to use this parameter.



**You can use IfcName if you want the level name to be different to the model, however I would always try and keep these the same.


IfcZone (Optional)

There are many more attributes in IFC some you may need and some you may not, it all depends on the project requirements. The table below lists some of these attributes and their corresponding Revit parameter. If anyone knows of any others let me know and I’ll add them to the list. Note that some attributes are exported by hardwired parameters so it’s always advisable to create a test file to see what exports and what doesn’t.


After reading this you can now add some basic information to the IFC entities which will be exported as IFC attributes. You should now know the difference between IFC attributes and IFC properties and that IFC attribute information can only be exported via parameters without a mapping file. You now have the option of overriding names, so you don’t have to use Revit family and type names if you do not wish to. In the next blog post we will look at exporting properties and property sets. Merry Christmas & A Happy New 2019

Emma Hooper, Associate Director, Bond Bryan Digital Ltd


Terms and conditions

All content provided on this Knowledge Hub is for informational purposes only. The owner of this Knowledge Hub 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 Digital Ltd will not be liable for any errors or omissions in this information nor for the availability of this information.
Bond Bryan Digital Ltd 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 Knowledge Hub pieces through all social media platforms. You may include links to the original blog pieces and use part of the Knowledge Hub 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 Digital Ltd.

This policy is subject to change at any time.