Difference between revisions of "Revit setup for OpenBIM/Revit and IFC classes"

From Wiki.OSArch
(Created page with "It is possible to control which IFC classes map to which Revit objects when exporting and importing to some degree. Prior to reading this, it is important to first read th...")
 
Line 1: Line 1:
 
It is possible to control which [[IFC classes]] map to which Revit objects when exporting and importing to some degree. Prior to reading this, it is important to first read the resources provided in [[Revit setup]].
 
It is possible to control which [[IFC classes]] map to which Revit objects when exporting and importing to some degree. Prior to reading this, it is important to first read the resources provided in [[Revit setup]].
  
To set IFC classes and predefined types in Revit, it requires intimate knowledge of all of the IFC class names, which ones can be used (i.e. which ones are not abstract), and all of the predefined types possible. Revit does not provide any interface or drop downs or lists that aid selection. It may be useful to use the [https://blenderbim.org/search-ifc-class.html BlenderBIM Add-on IFC class search website] to discover which IFC classes should be used.
+
To set IFC classes and predefined types in Revit, it requires intimate knowledge of all of the IFC class names, which ones can be used (i.e. which ones are not abstract), and all of the predefined types possible. Revit does not provide any interface or drop downs or lists that aid selection. Therefore, if you make a spelling mistake, or accidentally type extra characters, the export will also be incorrect. It may be useful to use the [https://blenderbim.org/search-ifc-class.html BlenderBIM Add-on IFC class search website] to discover which IFC classes should be used.
  
 
=Export=
 
=Export=
  
Revit follows three rules to determine what IFC class an object is exported as. Each rule overrides the previous rule.
+
Revit follows a series of convoluted rules to determine what IFC class an object is exported as. If one rule cannot be satisfied, it moves on to the next rule until it finds a suitable IFC class.
  
# Check the IFC class mappings provided in the IFC export settings, to map the Revit family to an IFC class, unless ...
+
==Rule 1: Hardcoded IFC export classes==
# ... unless the user has manually overridden the IFC class, using the <code>IfcExportAs</code>, <code>IfcExportType</code>, <code>IfcExportAs[Type]</code>, or <code>IfcExportType[Type]</code> parameter, unless ...
+
 
# ... unless the particular Revit family is one of the series of hardcoded types that cannot be overridden no matter what.
+
Revit has a series of hardcoded IFC export classes depending on the type of Revit object. It is not possible to override this in any way, and users are required to remodel the object using another method if they wish to get correct OpenBIM output. The table below describes the ''internal'' type of Revit object, and how it is exported. If you are unsure what this ''internal'' type is, this can be checked in the [https://www.revitapidocs.com/2020/ Revit API documentation] (note: this requires some programming background knowledge to understand). If your object is not part of the table below, proceed to rule 2.
 +
 
 +
{|class="wikitable"
 +
! Revit Category
 +
! IFC Class
 +
! Notes
 +
|-
 +
| Area Scheme
 +
|
 +
|
 +
|-
 +
| Assembly Instance
 +
|
 +
|
 +
|-
 +
| Beam System
 +
|
 +
|
 +
|-
 +
| Ceiling
 +
|
 +
|
 +
|-
 +
| Ceiling and Floor
 +
|
 +
|
 +
|-
 +
| Wall Foundation
 +
|
 +
|
 +
|-
 +
| Curve Element
 +
|
 +
|
 +
|-
 +
| Curtain System
 +
|
 +
|
 +
|-
 +
| Duct Insulation
 +
|
 +
|
 +
|-
 +
| Duct Lining
 +
|
 +
|
 +
|-
 +
| Electrical System
 +
|
 +
|
 +
|-
 +
| Fabric Area
 +
|
 +
|
 +
|-
 +
| Fabric Sheet
 +
|
 +
|
 +
|-
 +
| Face Wall
 +
|
 +
|
 +
|-
 +
| Filled Region
 +
|
 +
|
 +
|-
 +
| Grid
 +
|
 +
|
 +
|-
 +
| Group
 +
|
 +
|
 +
|-
 +
| Hosted Sweep
 +
|
 +
|
 +
|-
 +
| Part
 +
|
 +
|
 +
|-
 +
| Pipe Insulation
 +
|
 +
|
 +
|-
 +
| Railing
 +
|
 +
|
 +
|-
 +
| Ramp
 +
|
 +
|
 +
|-
 +
| Rebar
 +
|
 +
|
 +
|-
 +
| Rebar Coupler
 +
|
 +
|
 +
|-
 +
| Roof Base
 +
|
 +
|
 +
|-
 +
| Spatial Element
 +
|
 +
|
 +
|-
 +
| Stairs
 +
|
 +
|
 +
|-
 +
| Text Note
 +
|
 +
|
 +
|-
 +
| Topography Surface
 +
|
 +
|
 +
|-
 +
| Truss
 +
|
 +
|
 +
|}
 +
 
 +
==Rule 2: Check for a manually overridden instance parameter ==
 +
 
 +
The IFC export class can be overridden on a per instance basis. To do this, parameters need to be created and assigned to instances. A shared parameter file with these parameters is provided in the [[Revit setup]] page.
  
OSArch provides an improved default set of IFC class mappings in the [[Revit setup]] page. You can manually access this by going to <code>File > Export > Options > IFC Options</code>. It lets you map both the IFC class and predefined type.
+
When the IFC class is overridden at an instance level, this additionally overrides the IFC type object that the IFC element is assigned to.
  
If if you wish to override the IFC class per instance or per Revit type, you can do so by assigning an instance or type parameter respectively. Shared parameter files are provided in the [[Revit setup]] page for convenience.
+
{|class="wikitable"
 +
! Parameter Name
 +
! Parameter Type
 +
! Notes
 +
|-
 +
| <code>IfcExportAs</code>
 +
| Instance
 +
| This may be filled out in two ways, either just the desired IFC export class (e.g. <code>IfcWall</code>) or the IFC export class and the predefined type joined with the dot symbol (e.g. <code>IfcWall.PLUMBINGWALL</code>). This text is case insensitive, but it is recommended for neatness to follow the conventions in the IFC documentation, where the classes use CapsCase and the predefined type uses ALLCAPS.
 +
|-
 +
| <code>IfcType</code>
 +
| Instance
 +
| '''Note: this is deprecated and should not be used.''' This may be filled out with the desired predefined type (e.g. <code>PLUMBINGWALL</code>). This text is case insensitive, but it is recommended for neatness to use ALLCAPS as per the IFC documentation. If a predefined type is specified both in the <code>IfcType</code> parameter as well as in the <code>IfcExportAs</code> parameter (via joining with the dot symbol), then the <code>IfcType</code> takes priority. Therefore, it is advised to generally not use the dot notation, and keep the two values separated.
 +
|-
 +
| <code>IfcExportType</code>
 +
| Instance
 +
| '''Note: this should be used instead of <code>IfcType</code>.''' This may be filled out with the desired predefined type (e.g. <code>PLUMBINGWALL</code>). This text is case insensitive, but it is recommended for neatness to use ALLCAPS as per the IFC documentation. If a predefined type is specified in all three possible parameters, i.e. the <code>IfcExportType</code> parameter, the <code>IfcType</code> parameter as well as in the <code>IfcExportAs</code> parameter (via joining with the dot symbol), then the <code>IfcExportType</code> takes priority over the other two. Therefore, it is advised to generally not use the dot notation, and keep the two values separated. It also advised to avoid <code>IfcType</code> completely to prevent user confusion.
 +
|}
  
If you want to override a single instance, create a new parameter called <code>IfcExportAs</code> and fill out the parameter with the name of the IFC class that you want the instance to be exported as (e.g. <code>IfcWall</code>). If you wish to override the <code>PredefinedType</code> per instance, create a new parameter called <code>IfcExportType</code> and fill out the parameter with the name of the predefined type (e.g. <code>PLUMBINGWALL</code>).
+
==Rule 3: Check for a manually overridden type parameter ==
  
Instead of overriding a single instance, it may be more advisable to override by type. All instances of that type will then be overridden too. The approach is similar, except that the parameters must be type parameters, and are called <code>IfcExportAs[Type]</code> and <code>IfcExportType[Type]</code> instead respectively.
+
Instead of overriding a single instance, it may be more advisable to override by type. All instances of that type will then be overridden too. For example, if a type is overridden to be <code>IfcWallType</code>, each instance will be overridden automatically to be <code>IfcWall</code>. The approach is similar, except that the parameters must be type parameters, and are called <code>IfcExportAs[Type]</code> and <code>IfcExportType[Type]</code> instead respectively. The parameter must be filled out with the name of the IFC type class (e.g. <code>IfcWallType</code>).
  
 
If the project is based on IFC2X3, it is advisable to override by type, as IFC2X3 contains more granular IFC classes for element types, especially in regards to MEP disciplines.
 
If the project is based on IFC2X3, it is advisable to override by type, as IFC2X3 contains more granular IFC classes for element types, especially in regards to MEP disciplines.
  
You may find that despite these efforts, it is still not possible to control which IFC class Revit will export as. The following elements are hardcoded in Revit and  
+
==Rule 2: Check IFC class mappings table==
 +
 
 +
Revit offers a mapping table from Revit category (and subcategory) to IFC class and IFC Predefined Type. You can manually access this by going to <code>File > Export > Options > IFC Options</code>. You can save and load these settings.
 +
 
 +
Out of the box, there are many shortcomings to the IFC class mappings table. OSArch provides an improved default set of IFC class mappings in the [[Revit setup]] page, and describes what the improvements are.
 +
 
 +
==Rule 3: Check if it is part of a furniture group==
 +
 
 +
If the element is contained within a Revit group that is an IfcFurniture, it is always exported into an IfcSystemFurnitureElement.
 +
 
 +
==Rule 4:
 +
# ... unless the particular Revit family is one of the series of hardcoded types that cannot be overridden no matter what.
 +
 
  
 
=Import=
 
=Import=

Revision as of 23:59, 10 September 2020

It is possible to control which IFC classes map to which Revit objects when exporting and importing to some degree. Prior to reading this, it is important to first read the resources provided in Revit setup.

To set IFC classes and predefined types in Revit, it requires intimate knowledge of all of the IFC class names, which ones can be used (i.e. which ones are not abstract), and all of the predefined types possible. Revit does not provide any interface or drop downs or lists that aid selection. Therefore, if you make a spelling mistake, or accidentally type extra characters, the export will also be incorrect. It may be useful to use the BlenderBIM Add-on IFC class search website to discover which IFC classes should be used.

Export

Revit follows a series of convoluted rules to determine what IFC class an object is exported as. If one rule cannot be satisfied, it moves on to the next rule until it finds a suitable IFC class.

Rule 1: Hardcoded IFC export classes

Revit has a series of hardcoded IFC export classes depending on the type of Revit object. It is not possible to override this in any way, and users are required to remodel the object using another method if they wish to get correct OpenBIM output. The table below describes the internal type of Revit object, and how it is exported. If you are unsure what this internal type is, this can be checked in the Revit API documentation (note: this requires some programming background knowledge to understand). If your object is not part of the table below, proceed to rule 2.

Revit Category IFC Class Notes
Area Scheme
Assembly Instance
Beam System
Ceiling
Ceiling and Floor
Wall Foundation
Curve Element
Curtain System
Duct Insulation
Duct Lining
Electrical System
Fabric Area
Fabric Sheet
Face Wall
Filled Region
Grid
Group
Hosted Sweep
Part
Pipe Insulation
Railing
Ramp
Rebar
Rebar Coupler
Roof Base
Spatial Element
Stairs
Text Note
Topography Surface
Truss

Rule 2: Check for a manually overridden instance parameter

The IFC export class can be overridden on a per instance basis. To do this, parameters need to be created and assigned to instances. A shared parameter file with these parameters is provided in the Revit setup page.

When the IFC class is overridden at an instance level, this additionally overrides the IFC type object that the IFC element is assigned to.

Parameter Name Parameter Type Notes
IfcExportAs Instance This may be filled out in two ways, either just the desired IFC export class (e.g. IfcWall) or the IFC export class and the predefined type joined with the dot symbol (e.g. IfcWall.PLUMBINGWALL). This text is case insensitive, but it is recommended for neatness to follow the conventions in the IFC documentation, where the classes use CapsCase and the predefined type uses ALLCAPS.
IfcType Instance Note: this is deprecated and should not be used. This may be filled out with the desired predefined type (e.g. PLUMBINGWALL). This text is case insensitive, but it is recommended for neatness to use ALLCAPS as per the IFC documentation. If a predefined type is specified both in the IfcType parameter as well as in the IfcExportAs parameter (via joining with the dot symbol), then the IfcType takes priority. Therefore, it is advised to generally not use the dot notation, and keep the two values separated.
IfcExportType Instance Note: this should be used instead of IfcType. This may be filled out with the desired predefined type (e.g. PLUMBINGWALL). This text is case insensitive, but it is recommended for neatness to use ALLCAPS as per the IFC documentation. If a predefined type is specified in all three possible parameters, i.e. the IfcExportType parameter, the IfcType parameter as well as in the IfcExportAs parameter (via joining with the dot symbol), then the IfcExportType takes priority over the other two. Therefore, it is advised to generally not use the dot notation, and keep the two values separated. It also advised to avoid IfcType completely to prevent user confusion.

Rule 3: Check for a manually overridden type parameter

Instead of overriding a single instance, it may be more advisable to override by type. All instances of that type will then be overridden too. For example, if a type is overridden to be IfcWallType, each instance will be overridden automatically to be IfcWall. The approach is similar, except that the parameters must be type parameters, and are called IfcExportAs[Type] and IfcExportType[Type] instead respectively. The parameter must be filled out with the name of the IFC type class (e.g. IfcWallType).

If the project is based on IFC2X3, it is advisable to override by type, as IFC2X3 contains more granular IFC classes for element types, especially in regards to MEP disciplines.

Rule 2: Check IFC class mappings table

Revit offers a mapping table from Revit category (and subcategory) to IFC class and IFC Predefined Type. You can manually access this by going to File > Export > Options > IFC Options. You can save and load these settings.

Out of the box, there are many shortcomings to the IFC class mappings table. OSArch provides an improved default set of IFC class mappings in the Revit setup page, and describes what the improvements are.

Rule 3: Check if it is part of a furniture group

If the element is contained within a Revit group that is an IfcFurniture, it is always exported into an IfcSystemFurnitureElement.

==Rule 4:

  1. ... unless the particular Revit family is one of the series of hardcoded types that cannot be overridden no matter what.


Import