Revit

Standards
Foundation

BENELUX 1.0.0 1
 This publication has been developed in collaboration with BuildingSMART Benelux
as the administrator of BIM Basis Afspraken (Basic BIM Agreements).

BENELUX

The Following people have contributed to the release of this publication:

Orginal authors: Erwin Pijffers – Dura Vermeer
Translation: Emiel Ham – Dura Vermeer
Editor: Martijn de Riet – buildingSMART Benelux
Jaco Prins – BAM

The use of the information in this document is at your own risk. There is no guarantee that the given
information is correct. For questions and/or comments please contact the Revit Standards Technical
Committee via email: tc@revitstandards.org.

Neither the Revit Standards Foundation (RSF), any Revit Standards Foundation committee nor its
contributors shall be held liable for any improper or incorrect use of the information described,
advice given in this document, any communication regarding this document and/or contained herein
and assumes no responsibility for anyone’s use of the information.
In no event shall the Revit Standards Foundation, any Revit Standards Foundation committee or its
contributors be liable for any direct, indirect, incidental, special, exemplary, or consequential
damages(including, but not limited to: procurement of substitute goods or services; loss of use,
data, or profits; or business interruption).
It’s the Revit Standards Foundation Technical Committee’s responsibility that this document will be
included in the NLRS release cycle. As a part of this release cycle it will be enriched, adjusted and
managed. This will be achieved with a close collaboration between the Revit Standards Foundation
stakeholders, expert groups and the RSF board.

Version 1.0.0
Release date 23 september 2016
Commissioned by Revit Standards Foundation
Postbus 358,
5201 AJ ‘s-Hertogenbosch
Author Erwin Pijffers – Dura Vermeer
Editorial office Martijn de Riet – buildingSMART Benelux
Jaco Prins – BAM
Translation Emiel Ham – RSF Technical Committee

2
 14 Dutch companies, active in the construction
PREFACE
industry, accepted an invitation from BuildingSmart
to collaborate and create a set of basic agreements
regarding the output and structure of Information
Models based on these 14 companies’ best practices.
This set of agreements is necessary for an improving
performance of BIM within the Dutch construction
industry. The goal of this set of basic agreements,
that are widely supported, is to exchange consistent
and reliable information efficiently and effectively
within the chain. It is not a new initiative, but a
collective underscore of the existing agreements.
To create a less fragmented and more efficient
construction industry it is of great importance to
exchange information more effectively than as it
is today. Today, every client, every contractor and
every project have their own specific agreements
and arrangements in relation to communication of
information models. The current agreements have
the baseline set, already resulting in simplifying
the process. The first step has been taken by the
14 companies through capturing the experience
and knowledge in a structure that all can agree on.
The basic agreements contribute to delivering the
information in an unambiguous way by every party
involved. Through this the information models are
ready for use by others.
UNITING THE FORCES
The group initiators includes: BuildingSmart BeNeLux,
Dura Vermeer, VolkerWessels, De Nijs, Heijmans,
Klok Groep, Hurks, Waal, Trebbe, J.P. van Eesteren, TBI,
van Wijnen, Hendriks Bouw en Ontwikkeling, Smit’s
Bouwbedrijf and the BAM. Together they emphasize
that this is nothing new being created, but using what
is already there. Part of these basic agreements are
the file exchange format, the structure to be used
and securing the object information. Now the time
has come to join these forces. Every company that is
operating in the field of construction is hereby invited
to add their knowledge and experience to the basic
agreements and jointly take the next step.
IT STARTS AT THE FRONT
The occurrence of clients and contractors working
with different types of information is too high. By
making agreements of the definition of certain
information and what would be the best exchange
method of this information, the collaboration
gets more efficient. This can be expressed in time
and costs. Converting delivered information to a
format that the client can use is thereby prevented.
Therefore communicating in the same language
starts at the front.
JOINING MEANS TAKING THE LEAD
The group of contractors embracing this initiative is
just the beginning. It is a fact that other contractors
and construction companies struggle with the same
challenges. The more parties join and are willing to
think along about possible next steps, the faster the
widely acknowledged and shared frustrations will
belong to the past. This is the reason why the previous
named companies put their signature beneath these
basic agreements.
CLARITY AND OVERVIEW
Also for subcontractors and suppliers managing the
information will be clearer through the basic
agreements. The benefits of these agreements
will increase when more clients and construction
companies work the same way with the same
information structure. As a subcontractor or supplier
you will not waste valuable time with sorting out
what the actual request is. Therefore it is worth it to
arrange your product catalogue this way. The sooner
subcontractors and suppliers join this way of working,
the sooner the chain will profit.
3
 BUILDINGSMART BENELUX
BuildingSmart BeNeLux is a chapter of the
BuildingSMART International, The organization that is
responsible for managing and maintaining the
IFC standard. The Primary goal of BuildingSMART
BeNeLux is increasing the use of the IFC Standard
within the Netherlands, Belgium and Luxembourg.
Mainly this is being realized by supporting end-users
with implementing and applying IFC in their daily
workflows.
CHANGE LOG
Date Correction
14-09-2016 First version
25-09-2016 Redaction MdR
26-09-2016 Redaction JPR
4
From this perspective BuildingSmart BeNeLux is one
of the initiators involved with the development of the
BIM Basis ILS (BIM Basic Information Delivery
Specification). From the first release on
BuildingSMART BeNeLux will be maintaining and
managing the BIM Basis ILS. BuildingSMART BeNeLux
considers this elaboration on the ILS (Information
Delivery Specification) for Revit users as a practical
and helpful addition because Revit users get a clear
manual of how to apply a BIM.
TABLE OF CONTENTS
3 Which structure will be applied? 6
3.1 Filename 6
3.1.1 Building Name 7
3.1.2 Project Name 7
3.1.3 Project Number 7
3.1.4 SiteName 7
3.1.5 IFC-export 8

3.2 Local Position and Orientation – Basepoint 9

3.2.1 Coordination points check 9

3.3 Buildingstory Layout and Namingconvention 11

3.3.1 Add the project parameter 11

3.4 Correct use of enitities 14

3.4.1 Mapping table 14
3.4.2 IfcExportAs 16

3.5 Build-up and namingconvention 18

3.5.1 Naming Convention Families 18

3.6 Information classification NL-SfB Code 19

3.6.1 Loading the NL-SfB classifictioncode 19

3.7 Equip objects with correct materials 20

3.8 Duplicates 20

4 How to secure other / future object information? 21

4.1 Parametermapping 21
4.2 Bearing/Non-Bearing 22
4.3 External / Internal 23
4.4 Fire Rating 24
4.5 Project Specific 24

5 Settings Open Source IFC Exporter 26

5
3 WHICH STRUCTURE
WILL BE APPLIED?
The agreements mentioned below help every involved party to have the ability to always find and deliver
the right information on the right spot. There is a brief description of which actions have to be taken to
accomplish this structure.

3.1 FILENAME
Always ensure a uniform and consistent filename for (aspect)models within a project. The naming convention can be
secured using a BIM protocol. Ensure to make a clear distinction between the disciplines.

Examples: <projectname>_<aspect/discipline>_ For a proper tree structure when exporting an IFC file
<part of the project> it is necessary to fill out some fields in the project
Example_architectural_block 1 information. The project information can be added via
Example_structural_block 1 the Project Information window that can be found in
Example_electrical_block 1 the ribbon tab ‘Manage’.
Example_mechanical_block 1

The following window appears:

6
The following properties need to be filled in:
•B
 uilding Name <CGREA-building number>
(Central Government Real Estate Agency)
Example: 123456A78
•P
 roject Name: <project number> ProjectLongName (in Revit Project Name).
Example: E250514
•P
 roject name: <project name>_
<discipline of the model>
Example: projectname_architectural
•S
 iteName: <cadastral registration number>
Example: Rotterdam AB 1234
3.1.1 BUILDING NAME
The property Building Name should be filled with the
RVB-building number (CGREA-building number). In
case of multiple building numbers, all building
numbers should be filled in, separated with a
<space>‘-’<space>.
Example: 123456A78 – 123456A79
3.1.2 PROJECT NAME
Confusing as it is, for Project Name the project
number should be filled in. When sheets within Revit
are configured the right way, it will not be noticed.
Therefore, it is important to use the right labels in
Click on the ‘Add’ button in the Project Parameters window to add a parameter.
the Sheet families (for showing a project number
on a sheet use ‘Project Name’). The reason behind
this, is that IFC doesn’t know project numbers but
only ProjectName (in Revit Project Number) and
3.1.3 PROJECT NUMBER
The Project Number in a Revit Project is being used
for the <projectname>_<aspectmodel>. The same is
applicable for Project Name.
3.1.4 SITENAME
SiteName is used for the cadastral registration
numbers. When the project is spread over multiple
plots, all the cadastral registration numbers need to
be filled in, separated by a <space>‘-’<space>.
Example: Rotterdam AB 1234 – Rotterdam AB1235
This parameter is not part of the standard Project
Properties and will have to be added manually.
This can be done by using Project Parameters. To
add a Project Parameter, navigate to the ‘Project
Parameters’ button that can be found on the ribbon
under the ‘Manage’ tab.
7
 Fill in / use the following values:
• Parameter Type: Shared Parameter
• Name: SiteName (to be found in the Autodesk IFC Shared Parameters file,
also included with the NLRSv2.5.2)
• Discipline: Common
• Type Of Parameter Text
• Group: Other
Check Project Information in the list of categories and close the window by selecting ‘Ok’.

3.1.5 IFC-EXPORT
When the values of the parameters are filled in correctly, the tree structure of the IFC export will look as
following:

8
3.2 L
 OCAL POSITION AND
ORIENTATION – BASEPOINT
The position of the building is mutually coordinated
and is close to the base point. Revit knows three
types of coordination points whereof two visible:
1. Project Base Point – used as the 0,0,0 point of the
project;
2. Survey Point – Coordinates that tell where on
earth the building is situated;
3. Startup Point – Internal Base Point of Revit. This
one is not visible within the project.
It is wise to put all three points on top of each other
and create two gridlines (x,y).

3.2.1 COORDINATION POINTS CHECK

The basepoints can be turned on within Revit through
the Visibility window. Beneath the category Site the
Project Base Point and Survey point can be checked.

9
 Two icons will appear in the workspace. The circle is
the Project Base Point, the triangle is the Survey
Point. All values have to be zero when selecting either
one of them. To check if the third coordination point
is at the same point as the other two, it is possible to
10
move the Project Base Point to the Startup Location.
This can be done by selecting the Project Base Point,
right-click and select Move to Startup Location.
When this option is grayed out, the Project Base Point
is already on top of the startup location.
3.3 B UILDINGSTORY LAYOUT EN
NAMINGCONVENTION
Within Autodesk Revit the levels can be equipped
with the property ‘Building Story’. Only the levels that
have this property checked will be exported when
exporting to the IFC file format. As known, modeling in
Revit is done by level. It is not unusual to apply
sublevels when modeling in Revit. If so, there is a
01_1st floor (top of the finished floor) and a 01_1st
floor top structural floor. Though, when exporting to
IFC there can only be one level per building storey, the
top of the finished floor. In an IFC that will be defined
as the Building Storey.
To create a correct export every level (i.e. 01_1st floor)
need to have the ‘Building Storey’ property checked.
The Project Parameters window shows all the project parameters present in the project.
To add an extra project parameter, click on the ‘Add..’ button.
All the sublevels (01_1st floor top structural floor)
have the ‘Building Storey’ property unchecked. It is
possible, with the extra shared parameters IfcName,
IfcLongName and IfcDescription (to be found in the
IFC Shared Parameters file included with the
NLRS2.5.2) to overwrite the description (“01_1st floor)
for the set naming convention for building stories,
as documented in a BIM standard (i.e. CGREA BIM
standard).
3.3.1 A
 DD THE PROJECT PARAMETER
You can add a project parameter in Revit by
navigating to the ‘Manage’ ribbon tab and select
‘Project Parameters’ . Click on the A
‘ dd’ button in the
Project Parameters window to add a parameter.
11
 Fill in / use the following values:
• Parameter Type: Shared Parameter
• Name: IfcName (to be found in the Autodesk IFC Shared Parameters file, also included
with the NLRSv2.5.2)
• Discipline: Common
• Type of Parameter Text
• Group: IFC Parameters
Make this parameter an ‘instance’ and select ‘Values can vary by group instance’
Check Levels in the list of categories and close the window by selecting ‘Ok’.

12
When a level is selected the parameter IfcName is visible among all the instance properties. Here the right
name according to the CGREA BIM standard need to be filled in.

This build up looks as following: -1 basement, 00 first floor, 01 second floor etc.
When exporting to IFC all the levels come across nicely including all the elements that belong to that storey.

13
 3.4 C ORRECT USE OF ENITITIES
All objects need to be written to the right entities in
the IFC file. For many system families in Autodesk
Revit this is done automatically. Walls as IfcWall and
Floors as IfcSlab. However for loadable families,
exporting to the right entities come with an extra step
to export the objects to the right entity. Mainly this
can be done in two ways:
1. The IFC Export Mapping table combined with the
use of subcategories;
2. A
 dding the IfcExportAs parameter and defining its
value.
3.4.1 MAPPING TABLE
A loadable family can be built up by categories and
multiple subcategories. A Revit Subcategory is a
When the Object Styles window is opened, you
will notice that the Generic Model only has one
subcategory by default, called Hidden Lines.
14
subdivision within the Object Styles. They can be
present by default or defined by the user. Revit
Subcategories can be used for the following
purposes:
• Configuration of the visual properties (or parts) of
families
• Defining Import and Export of exchange file types
like .dwg and .ifc in advance. A subcategory needs
to be created when creating a family. By default
Autodesk Revit has some subcategories available,
but can also be created by the user. This can be
done by selecting ‘Object Styles’ within the ‘Manage’
ribbon tab.
With the ‘New’ button subcategories can be added. In
this image these are called ‘cilinder’,’kegel’ and ‘kubus’.
The newly added subcategories can be associated with the objects by selecting them in the workspace,
then picking the subcategory (part of the Identity Data group) of choice. The available categories are shown
in the dropdown menu.

When a Family is loaded into a project in Revit the mapping table for IFC needs to be customized. Objects
which have a subcategory that is not adjusted in the mapping table will automatically not be exported. This
is because new loaded/created subcategories are automatically mapped to ‘Not Exported’ and will not be
visible with the IFC export. This mapping table can be opened and edited by using the Application button ➞
Export ➞ Options ➞ IFC Options.

15
 In this example the objects are being exported to the following IFC entities:
• Cilinder: IfcStair
• Kegel: IfcFooting
• Kubus: IfcRailing
Within NLRS2.5.2 agreements have been made
regarding the use of subcategories that can be used
in Revit. The advantage is the use of default mapping
tables for these subcategories. The standard
mapping tables can be found in the NLRS2.5.2 release
in the folder Support Files > Mapping Tables.
3.4.2 IFCEXPORTAS
An alternative way of exporting is using the
IfcExportAs parameter. This parameter will overrule
the mapping table. Therefore, adding this parameter
is an excellent way to secure the correct information
within the families.
16
The IfcExportAs parameter can be used for System
Families and Loadable Families. For the System
Families this can be done by adding the IfcExportAs
parameter as a Project Parameter. However, a lot of
export categories are included in the software lines
and they are not editable. For Loadable Families the
IfcExportAs parameter can be added to the family
properties. To include this parameter to the
properties open the Family, followed by the Family
Types menu and select the button A
‘ dd..,’ part of the
Parameters group.
In the Parameter Properties menu the ‘Shared Parameter’ can be selected. This Shared Parameter list is
included in the release of the NLRS2.5.2, called ‘160114_NLRSv2.5.2_Shared Parameters – Algemeen’
and can be found in the parameter group ‘Common_Text’.

The IfcExportAs parameter is a type parameter and belongs to the IFC Parameter group. By filling in the
IfcExportAs parameter the values that are mentioned in the Mappingtable will be overwritten. Using the
IfcExportType it is possible to configure the so-called Type Enumerations. This way, it’s possible for the
supported IfcClasses to define to subtypes. The IfcExportType can be found in the Shared Parameter list
that is included with the NLRS2.5.2.

17
 3.5 BUILD-UP AND NAMINGCONVENTION
The naming of the object within a project needs to be
consistent and built up in the same way. In the NLRS
there has been made a proposition of this naming
convention for objects in Revit. In the following
paragraphs this will be further elaborated.
When necessary, all objects can be renamed to a
different structure when exporting to IFC.
For this, the following three Shared Parameters need
to be added to all objects: IfcName, IfcLongName
and IfcDescription. These parameters will be added as
instances and belong to the IFC Parameter group.
This is done the same way as described previously.
With these parameters it’s possible to rename all
objects and provide them with a description.

3.5.1 NAMING CONVENTION FAMILIES

The buildup for Revit families (System and Loadable) is seven positions:
<CCRSlc>_<classificiationcode>_<family category> _<placement>_<family description>_
<gen or manufacturer>_<content creator>

CCRSlc: This combination of codes was added due to the big international interest in the Revit Standards. With
this prefix suppliers of content can create libraries for different countries that are easily recognizable
for users. It’s not uncommon for parameter values to be country-specific. The country code consists of
a two-letter combination as stipulated in ISO 3166-1, see http://en.wikipedia.org/wiki/ISO_3166-1 for
more information. The abbreviation “RS” is added to inform Revit users that a localized version of the
Revit Standards is being used. In some cases the language code can be added, following ISO 639 (only if
the library is created for a multi-lingual country).
Classificiation Code: Families should be classified using a classification method. A uniform classification is important for
the efficiency of collaborating between partners, subcontractors, manufacturers. Working with the
same classifications makes it possible for all involved parties to use their own template (including
filters and schedules that are using the Assembly Code in Revit).
Family Category: Each Family Category has its own unique code/abbreviation that should be reflected in the Family
name. This is necessary for recognizing the purpose of the Family without having to open the Family.
Placement method  lacement goes is
All Revit Families can be placed in a project in a few different ways. The way this p
of a Family: decided when the Family is made and cannot be changed afterwards. The Family placement should
be visible in the Family name so you can see how it will be placed in your project.
NOTE: It is not necessary to use the placement position for system families. with system families
the placement has been taken care of by the software making it useless to use this in the naming
convention.
Family description: Text description of the Family.
Generic or supplier If the Family is Generic, position 6 should be filled with “gen”. Otherwise it should state the
name abbreviation of the supplier. Purpose of the Revit Standard Foundation is to provide a
comprehensive list, every release.
Content Distributor: When content is delivered by a commercial party or when it is made specifically for an addon position
7 should be filled with an abbreviation identifying the content distributor. Hereby we prevent
identical filenames and make the content that may have special functionality distinguishable.

With the release of the NLRS2.5.2 there are multiple documents included which can contribute to find the
right naming of the objects in a project. One of these documents is a spreadsheet that has 7 sheets with
values that you can select from. This file can be found at the following location:
NLRS2.5.2\Support Files - 160114_NLRS2.5.2_Naamgeving componenten.xlsx

18
3.6 I NFORMATION CLASSIFICATION
NL-SFB CODE
Every object in a Revit project can be provided with an
Assembly Code. The initiators of these agreements
unanimous choose for the four digit NL-SfB code.
3.6.1 L
 OADING THE NL-SFB
CLASSIFICTIONCODE
The full NL-SfB list can be loaded entirely into Revit
making it easier selecting a code from that list.
Loading an Assembly Code can be done by selecting
the A
‘ dditional Settings’ in the ‘Manage’ tab.

In the dropdown menu that appears, select the option at the bottom, called
A
‘ ssembly Code’ . With the window that opens you can load the NL-SfB file by
clicking the ‘Browse..’ function. The last version of the NL-SfB is included in the
NLRS2.5.2 and can be found at the following location:
NLRS2.5.2\Support Files\Mappingtabellen\NLRS_Assembly Codes

When the right NL-SfB list

is loaded it can be used for
classifying objects. The Assembly
code for objects can be chosen
in the Type Properties menu of
the selected object. By clicking
on the small grey block with the
three dots, a code can be selected
with the description included.
When a code is selected the
parameter Assembly Description
is automatically filled.

19
 3.7 EQUIP OBJECTS WITH CORRECT MATERIALS
Along with the NLRS2.5.2, the Revit Standards Foundations include an almost complete material library.
The naming convention for materials is based on table 3 of the NL-SfB. The materials are provided with the
correct use of the Assets and their properties. This way, it is possible to get a correct export of materials to IFC.

The materials naming convention is built up with six positions:

4
<CCRStl>_<classification code>_<material description>_<attributes>_<gen or manufacturer>_
<content creator>

DESCRIPTION

CCRSlc: 
This combination of codes was added due to the big international interest in

the Revit Standards. With this prefix suppliers of content can create libraries

for different countries that are easily recognizable for users. It’s not uncommon

for parameter values to be country-specific. The country code consists of a

two-letter combination as stipulated in ISO 3166-1, see http://en.wikipedia.

org/wiki/ISO_3166- 1 for more information. The abbreviation “RS” is added to

inform Revit users that a localized version of the Revit Standards is being used.

In some cases the language code can be added, following ISO 639 (only if the

library is created for a multi-lingual country).

Classification Code: 
Families should be classified using a classification method. A uniform

classification is important for the efficiency of collaborating between partners,

subcontractors, manufacturers. Working with the same classifications makes it

possible for all involved parties to use their own template (including filters and

schedules that are using the Assembly Code in Revit).

Attributes: 
Characteristic features of a specific material (optional). A textual description

of characterizing features of the material (concrete class etc.). The following

symbols are allowed as a hyphen: minus ‘-’, pipe symbol ‘|’, forward slash ‘/’. The

use of the spacebar is allowed.

Generic or supplier name: If the Family is Generic, position 6 should be filled with “gen”. Otherwise it

should state the abbreviation of the supplier. Purpose of the Revit Standard

Foundation is to provide a comprehensive list, every release.

Content Distributor 
When content is delivered by a commercial party or when it is made specifically

for an addon position 7 should be filled with an abbreviation identifying the

content distributor. Hereby we prevent identical filenames and make the

content that may have special functionality distinguishable.

3.8 DUPLICATES
In principle the BIM-extract does not contain any duplicates. There will be no BIM-objects within the extract
that represent the same geometry on the same location. Even though the BIM-extract might be built up by
multiple aspect models of drawings.
20
4
HOW TO SECURE OTHER /
FUTURE OBJECT INFORMATION?
Object information needs to be secured within the right properties and property sets as defined in IFC.
Every ElementClass in IFC has their own set of default properties, similar to the Built-in parameters in
Revit. These property groups are called IfcCommonPropertySets. For a full list of IfcCommonPropertySets
supported by Revit, review the following link: https://goo.gl/YsebAC.

In Revit certain built-in parameters are automatically mapped to the matching IFC parameter.
This is the case for the following Parameters:

Parameters used in specific property sets

Pset_BeamCommon, Span: INSTANCE_LENGTH_PARAM (Built-In Instance Parameter <Cut Length>)
Pset_CoveringCommon, TotalThickness: CEILING_THICKNESS (Built-In Type Parameter <Thickness>)
Pset_LightFixtureTypeCommon, TotalWattage: LIGHTING_FIXTURE_WATTAGE (Built-In Type Parameter
<Wattage Comments>)
Pset_ManufacturerTypeInformation, Manufacturer: ALL_MODEL_MANUFACTURER (Built-In Type Parameter
<Manufacturer>)
Pset_MemberCommon, Span: INSTANCE_LENGTH_PARAM (Built-In Instance Parameter <Length>,
werkt alleen voor Line Based Components)
Pset_RoofCommon, TotalArea: HOST_AREA_COMPUTED (Built-In Instance Parameter <Area>)

Pset_SpaceCommon,
CeilingCovering: ROOM_FINISH_CEILING (Built-In Instance Parameter <Ceiling Finish>)
WallCovering: ROOM_FINISH_WALL (Built-In Instance Parameter <Wall Finish>)
FloorCovering: ROOM_FINISH_FLOOR (Built-In Instance Parameter <Floor Finish>)

Parameters used in multiple property sets

FireRating: FIRE_RATING (Built-In Type Parameter <Fire Rating>)
ThermalTransmittance: ANALYTICAL_HEAT_TRANSFER_COEFFICIENT (Built-In Type Parameter <Heat
Transfer Coëfficiënt>)

4.1 PARAMETERMAPPING This method uses the template file

Besides the default mapping for the built-in Revit ParameterMappingTable. This textfile can be used to
Parameters, as referenced in paragraphs 4.2 to 4.5, create an own mapping between Revit parameters and
there is a general method to associate (custom) Revit IfcCommonProperties. You will find an example of how
Parameters to IfcCommonPropertySets. to use this textfile below.

The textfile can be

saved anywhere and
configured within
the Export settings.

21
 The NLRS2.5.2 includes a sample file based on the available Shared Parameters that come with the NLRS2.5.2.

4.2 BEARING/NON-BEARING
To indicate if a wall, floor, roof, and so on is bearing or non-bearing, the property ‘Structural’ can be used. If
this property is set to Non-bearing the element is non-bearing. In all other cases the element is bearing.

When modeling walls through the tab ‘Structure’, Revit will automatically
check that wall as a structural wall. Objects that have the property
Structural checked in Revit will also have this property in IFC. This
property can be found in the propertyset ‘Pset_xxxCommon’ (i.e. Pset_
WallCommon for walls) The property LoadBearing will be set to True.

22
4.3 EXTERNAL / INTERNAL
Most architectural elements (walls, floors, ceilings, roofs, columns) in IFC have the property IsExternal. This
property states whether an element is Internal (unchecked) or External (on the outer side of the thermal
layer). For system Families like walls and floors this can be specified by using the built-in parameter
‘Function’ that can be found in the Type Properties.

For loadable families, such as Columns the shared parameter IsExternal can be added as a project
parameter in Revit. The shared parameter is part of the Shared Parameter list that is included in the
NLRS2.5.2 (IFC Shared Parameters.txt. This parameter can be added similar to the IfcExportAs parameter
as described in paragraph 3.4.2.

23
 4.4 FIRERATING
As with the IsExternal parameter, the FireRating
parameter needs to be added manually for those families
that don’t have this asset as a default property. Notice
that the built-in Revit property called Fire Rating is a
type parameter. Sometimes this can be desirable,
sometimes it is better to make this an instance property.
In case of the latter, the ‘FireRating’ shared parameter can
be added as an instance parameter. When the
value for the built-in parameter isn’t filled, the Exporter
will automatically use the instance parameter when
exporting to IFC. For loadable families the FireRating
parameter can be associated with families.
Another option is to use a custom parameter (such as the
NLRS_C_brandwerendheid parameter) and use
the ParameterMappingTable to export this custom
parameter to the IFC Fire Rating property.
4.5 PROJECT SPECIFIC
Through the Open Source IFC Exporter project specific
properties can be exported ( this is part of the default
exporter for Revit 2017 and later versions). This can be
done by using either one of the following two methods:
1. Revit Schedules
This method is very easy to implement. Simply create
schedules with the properties that you want to
export. The Open Source IFC Exporter can be confi-
gured in a way that only schedules that contain ‘IFC’,
‘Pset’ or ‘Common’ in the title will be exported when
creating an IFC. In the image below, a schedule is created
called ‘Pset_Projectspecifiek_zeshoek’. In this example
the schedule entries have been filtered to show only all
hexagons in the project. In the schedule the properties
Mark and Comments have been added to the schedule
and subsequently exported to IFC. It is also possible to
add project parameters and shared parameters.

When setting up the IFC export, check the box in front of ‘Export schedules as property sets’ and check the
box below ‘Export only schedules containing IFC, Pset or common in the title.

The values in the schedule are exported to IFC and placed in a property set called
‘Pset_Projectspecifiek_zeshoek’.

24
2. Creating custom property sets
With the Open Source IFC Exporter there is a
possibility to create Custom Property Sets. To use
this feature, a text file needs to be created where
Revit parameters ‘get translated’ to IFC.

By applying the NLRS2.5.2, shared parameters

included in the Custom Property Set textfile can be
prepared and exported for use as project specific
properties. When using this method only relevant
information will be exported to IFC.

25
5 SETTINGS OPEN SOURCE
IFC EXPORTER
For a correct IFC export it is necessary to use the Open Source IFC Exporter . In comparison to the ‘official’
Revit IFC exporter, the Open Source IFC exporter offers a lot more possibilities and flexibility. However,
most of the improvements and updates being done in the Open Source Exporter have been adopted by the
official IFC exporter that comes with Revit. Since Revit 2017, the Open Source Exporter User Interface is
also used for the default Revit Exporter.

This ‘alternative’ exporter can be downloaded via the https://sourceforge.net/projects/ifcexporter/.

Autodesk Exchange Appstore. A direct link can to the
Exchange Apps can be found here:
https://apps.autodesk.com/RVT/en/Home/
Index?from=infocenter. Or a direct link to the
development platform Sourceforge:
This website also contains a user forum and the ne-
cessary manuals for correctly setting up and using the
Open Source Exporter. Before exporting to IFC, there are
some settings that need to be checked. The setup can be
modified when clicking on the ‘Modify setup..’ button.

The different settings within the Modify Settings window are grouped in 5 tabs. The different settings are
explained below.

26
General
1. IFC Version: Name of the setup that will be created. Most commonly used is IFC2x3 Coordination View 2.0.
The choice for a certain IFC Version should be made within the BIM Protocol.

2. File Type: Choice of filetype. Either select IFC or IFCzip.

3. Phase to Export: Which phase should be exported? By default this is the ‘Default Phase to Export’.

4. S
 pace Boundaries: In IFC the IfcSpace will contain a relationship to the bounding elements. 2nd level also
takes rooms on the other side of the wall into account. Only use this when exporting for analysis purposes.
If not, use 1st level.

5. Split Walls, Columns, Ducts by level: Splits elements that are modeled over multiple levels by level. Do not
use this feature. All objects should be modeled correctly and already be split up by level if so required.

6. F
 ile Header Information: A place to store general file and project information like the author and company.

7. Project Adress: The project address.

27
 8. Classifications: Alternative classifications can be indicated that are associated with the modelled
elements. Please review the Sourceforge Wiki, bullitpoint 6 and on https://sourceforge.net/p/ifcexporter/
wiki/New%20features%20in%20v2.8/ ofor more information about this setting.

Additional Content

1. E
 xport 2D Plan View Elements: Some 2D symbols and lines are exported (gridlines, door swing symbols and
so on.) Depending of the type of model it can be desirable to export the 2D information (i.e. for architects to
show the door swing in IFC).

2. E
 xport Linked Files as separate IFC’s: Export files that are linked in the project. This function is very useful
when the basepoints of the different linked files aren’t coordinated or when one linked file is placed multiple
times in the Host File. This option will position all the links correct and create an IFC File for all separate
linked files (and all instances of a linked file).

3. Export only elements visible in view: Only export elements that are visible in the current view. Only applicable
when necessary (when filters are used to hide elements etc.).

4. E
 xport Rooms in 3D views: Export rooms that are in the 3D views. Only applicable when needed.

28
Property Sets

1. Export Revit Property Sets: Export all Revit properties to IFC. This options exports everything, including
unvalidated and useless information. Turned off by default.

2. Export IFC Common Property Sets: Export the standard IFC properties. Turned on by default.

3. Export Base Quantities: Calculate the IFC quantities based on Revit geometry. Turned on by default. Note: it’s
a known issue that the export of these quantities are not always as reliable as wanted.

4. E
 xport Schedules as Property Sets: All Revit schedules will be converted and exported to custom IFC
Property sets. Only apply if this is a conscious choice and configured correctly in the project.

5. Export only Schedules containing IFC, Pset or Common in the title: This will only export the schedules to IFC
custom property sets when the Revit schedules contain IFC, Pset or Common in the title. Only apply if this is
a conscious choice and configured correctly in the project.

6. E
 xport User Defined Property Sets: Export Revit parameters in a custom defined property set. Only apply if
this is a conscious choice and configured correctly in the project. This is the preferred method of exporting
custom properties to IFC.

7. Export parameter mapping table: Export Revit parameters to the IfcCommon Propertysets. Only apply if this
is a conscious choice and configured correctly in the project.

29
 Level of Detail

1. L evel of detail for some element geometry: Reduce the amount of meshes when exporting to IFC with the use
of the so called BoundaryRepresentation. Set this to Low to reduce the IFC file size.

Advanced

1. E
 xport Parts as building elements: Export the Revit ‘parts’ as separate objects. Only applicable if desired. This
setting should be turned on when used for quantification purposes.

2. A
 llow use of mixed ‘Solid Model’ representation: Multiple Solids are created to define the IFC object in case
of complex geometry. This results in a lighter IFC export for complex geometry (i.e. doorframes etc.).
Turned on by default.

3. Use active view when generating geometry: Use the current view’s Detail Level settings to create the
geometric representation of the objects in IFC. Turned on by default.

4. U
 se family and type name for Reference: The Family name and Type name are used to autofill the parameter
‘Reference’ in the IfcCommon property sets. The type of export determines whether this is desirable
behavior. Turned on by default.

30
5. Use 2D room boundaries for Room Volume: Export simplified room geometry (based on 2D plan instead of the actual
shape)

6. Include IFCSITE elevation in the site local placement origin: Export the height of the IFCSITE’s local placement. Only
applicable in Norway due to local legislation requirements.

7. Store the IFC GUID in an element parameter after export: The IFC GUID of every object will be written to the
corresponding Revit objects. This is useful to check if elements were exported to IFC (there will be no GUID
parameter in Revit if an element is not exported). Turned on by default.

8. Export bounding box: Create an virtual IFC element that represents the space of the total object.
Turned on by default.

31
 INTERNATIONAL STAKEHOLDER STAKEHOLDER BELGIUM

CORPORATE SPONSORS

STAKEHOLDER NETHERLANDS

DONORS

Would your company like to support and

participate in the Revit Standards Foundation?
32 Please contact us via: board@revitstandards.org