Revit IFC Export #2: Category Mapping

by | Oct 16, 2023 | BIM

Export Classes

When converting to IFC, Revit categories need to be converted into IFC entities. This is controlled at the top level by the mapping table found in File > Export > Options > IFC Options.

The principle is that, for each Revit category, an IFC Class Name is provided and, if necessary, an IFC Type. Think of these in the same kind of way as Categories and Family Types work in Revit: the class is a generic grouping, the type is more specific.

The example below shows that Pipe Insulations are mapped to IfcCovering, which includes ceilings, wall and floor finishes, or anything else “which covers some part of another element and is fully dependent on that other element”*. Insulation defines the specific type of covering that Pipe Insulation will become.

You can only use classes and types that are allowed in the IFC schema. Making something up will not work. So knowing what to enter can sometimes be tricky, especially when you are not familiar with IFC.

You can find IFC definitions online, but it does take some searching to find exactly what you’re looking for.

Not Exported can be used to stop that category exporting at all. This can be very useful to remove unwanted annotations. An example can be seen for Plan Region in the image above.

Correcting the defaults

The default mapping table is stored in C:\ProgramData\Autodesk\RVT [version]\exportlayers-ifc-IAI.txt. It is a simple tab-delimited text file that can be edited directly if needed.

This default gives a good place to start from, but it is important that certain mappings are corrected prior to exporting to IFC.

One of these that will cause problems with IFC structures is the Site category. Site is used in Revit to denote elements that exist on a site. This is very different to an IfcSite, which is the definition of the area where the building or facility is located. The IFC structure follows the basic hierarchy:

IfcSite > IfcBuilding > IfcBuildingStorey

To have these elements mapping to multiple IfcSite elements would be totally incorrect.

Instead it is better to map the Site elements as shown below:

An IfcBuildingElementProxy is a generic entity, used where IFC does not include a specific definition for that element.

Note that Utilities cannot be mapped to a single IFC Entity correctly, as it might include cables (IfcCableSegment), pipes (IfcPipeSegment) and other elements. It is far better to specify each of these individually using the Export Type to IFC As parameter explained briefly last time. The same is true of Landscape.

Note also that the coordinate points have been left as IfcSite. As they are not physical elements it does not matter how they are mapped. They will be used to convert the whole model to the correct location.

Other considerations:

  • Where IfcBuildingElementProxy is used consider using the Export Type to IFC As parameter to give more flexibility. Examples include Communication Devices, Generic Models, Lighting Devices (IfcLightingFixtureType or , Mechanical Equipment (which would certainly not be correct as IfcBuildingElementProxy), Structural Connections (much of which should be IfcDiscreteAccessory e.g. anchors or IfcFastener e.g. welds), Structural Framing (IfcMember), etc.
  • When modelling bridges and using IFC 4, the default mappings can be changed to use the IfcBridge entity and predefined types including DECK, PIER, SUBSTRUCTURE, etc.
  • Map Finishes to IfcCovering to split them out from floors or walls.

    If this is done, a floor will convert as separate entities for the slab and the finish.
  • Check whether Areas are needed as well as Rooms. By default these both convert to IfcSpace, which can get messy, especially when generating COBie from the IFCs. Areas overlap spaces and can cause confusion. If they are not needed, set these to Not Exported.

Next time: A couple of warnings about the COBie Extension.