General Family Issues
There are common areas of concern relating to existing Revit family content that needs to be addressed within the
UK Localisation. Some general protocols have been defined here that are considered good practice and these
conventions should be applied to all Revit content.
Family Folder Structure
Families are generally located within a folder structure that represents the appropriate defined Revit Family
Category. To aid with the finding of specific families further folder sub groups have been also been created. Only
Component Families of the appropriate Family Category should exist within the Library folders provided. Revit
Families that are presently defined with either the wrong family category or “Generic Models” should have the
Family Category redefined or the family files moved to the appropriate folder.
Shared Parameters
In order that specific family parameters can be included within schedules, families should be created using
predefined shared parameters. These should all be created from a common standardised shared parameter file
using the same GUIDs. The appendix at the back provides a list of the proposed shared parameters that should be
used.
Family Templates
UK Family Templates should include standard shared parameters to aid with family construction, ensure standard
parameter naming conventions and aid the use of parameters in tags and schedules.
Shared Geometry Parameters of Length, Width, Height and Depth where appropriate, should be included along
with reference planes in family templates to aid the creation of family data that can be scheduled.
Geometry parameters names should be standardised and included within the common shared parameter table and
also family templates. At present content uses parameter name such as Depth, Length and Breadth to all represent
the same geometric parameter requirement.
It is recommended that only the terms Width, Length and Height should be included as the standard overall
geometry parameters applied to dimension in families to control the parametric sizes. In family items such as
Furniture the term Depth is substituted for Length where the value is less than the width.. Therefore an additional
Depth shared parameter could be added and the value is assigned as a formula (=Length).
As a definition of usage the Width dimension is generally defined as the dimension in normal use which is hosted
along a wall. The Length (or Depth) is the dimension of the family away from the wall. The term Depth is commonly
used when this value is less than the width, whilst the term length is used when it is greater. Normal industry usage
of dimension terminology should be applied to all created families.
The purpose of this methodology is to allow the overall size of families to be created and scheduled in a consistent
manner.
To aid with the identification of geometry it is common practice to use geometry parameters in the naming of objects such as family name = Dresser, family type = 1200x1500x600. However, there are often discrepancies in the order that the dimensions are used within the naming conventions within different families. Geometry order within names should be standardised as follows:-
| Element Types | Geometry Formatting |
| Doors | Width x Height |
| Windows | Width x Height |
| Casework (Kitchen / Bathroom Units) | Width x Length x Height |
| Furniture | Width x Length x Height |
| Other elements | Width x Length x Height |
If the Family is created using geometry parameters then this information should be included in the Family Type name in using the geometry formatting defined above.
Example Geometry Information
| Family Name | Family Type Name | Geometry Parameters |
| OCSL_KitchenUnits_BaseDouble_Shaker | 1000x600x870 | Width x Length x Height |
| OCSL_KitchenUnits_BaseDouble_Shaker | 1200x600x870 | Width x Length x Height |
Family Naming Conventions
Within the Revit UK content there is no consistent naming convention presently under use. It is therefore proposed that the following naming conventions should be adopted for all UK Localisation content and this framework adopted for all Users created content. Revit families include both parametric and non-parametric families. The naming convention should aid the distinction between the two.
Special Characters
To ensure compatibility and interoperability between Revit and other CAD software, as well as data formats sources such as databases field names and XML schemas etc. the use of special characters and spaces MUST NOT be used in any naming conventions.
Therefore the following best practice should be followed:-
Only the letters (A to Z), hyphen (-), underscore () and numbers (0-9) shall be used in the naming of families, family types or parameters. • Spaces MUST NOT be used. • The use of an underscore () to separate between fields shall be adopted.
• The use of a hyphen (-) to separate between components in a field shall be adopted.
The following characters MUST NOT be used in any circumstances:-
• ,.◦ ! “ £ $ % ^ & * ( ) { }[ ] + = < > ? | \ / @ ’ ~ #¬ ` ‘
Family Naming General Considerations
Naming conventions must be consistent across all software to be used and not just Revit. The purpose of many of these conventions is to aid the interoperability between Revit and other data formats. Whilst many characters can be used in Revit and other software the consequences of using special characters may not be obvious until data is passed to other software. Therefore the following best practice should be followed:-
• Each Revit Family must be created with a unique name that identifies the object using real world terminology. The name ‘Wall 1’ is not acceptable.
• The use of commonly used UK construction abbreviations for common terms is recommended to reduce the length of the name and aid the viewing of the family names within the software.
• For families where the family category is obvious the family category does not need to be included within the family name, unless the functional type is different. E.g. Door family Categories would not need to include the word ‘Door’ in the names
• Revit is Case sensitive so consistent use of ‘Title_Case’ is recommended.
• Consistent definitions of the Description field must be used within the naming convention to ensure that families are displayed in a logical order.
Types of Revit Families
There are three fundamental types of Revit families in use and the naming convention needs to facilitate the different types. The types are:
- System Families
- Non Parametric component Family
- Parametric component Family
Revit System families exist only in either a project or a template file and are derived via Revit dialogue boxes where the families’ assembly structure and family construction rules are defined. Examples of these include
- Walls
- Roofs
- Ceilings
- Floors
- Ramps
- Stairs
- Railings
Component families are created with a Revit Family Template and exist in their own Revit Family File (RFT) from which they can be loaded into a Revit Template or Project. Components Families can either be created with or without parameters which can control the size of geometry or materials used etc.
For families where no parameters are used, information regarding the family should be provided through the family name. This naming convention would also apply to ‘In Place’ families, which are bespoke families modelled within the project environment. Families that include Parameters should also include at least one family type, providing information about the default implementation of the parameters. Typical Parameters that may affect the type name are size and material.
Revit Family Naming Convention
Revit Family Names and Type names must follow the following Naming conventions to enable an interoperable BIM process. The naming conventions cannot be consistent for every family due the demands and requirements of each different family category, but rather provide a framework.
This family naming convention is specifically aimed at the naming of Revit families and types, but the principles can apply to any AEC object. For data to move between software packages (interoperability) a common naming convention needs to be applied to these objects.
The family names are divided into three main fields and these are:
| Field 1 (Optional) | Field 2 | Field 3 (optional) |
| Owner | Description | Unique Identifier |
Field 1 – Owner
Revit Families often requires definition of its ownership. This could take the form of either Manufacturers specific content, or content developed by a specific company or group that wish to identify that they are the owners of that content. In this situation an Owner identifier should be included as the first field within the name. It is recommended that this is abbreviated to a maximum of 5 Characters to reduce the length of the name where possible. Industry established Developer symbols could be used where these exist.
Wall Family Example:-
Description: Oakley CAD Services Ltd External Wall 300mm thick for Generic use.
Name: “OCSL_Wall_Ext_300Gen”
Where no ownership is required then this field should be left blank.
Field 2 – Descriptions
The description normally refers to real world names that are understandable by all members of the AEC industry. Descriptions with names may be derived from the descriptions in a classification system; however they are not classification codes. The types of descriptions in use depend upon the type of Revit family to be created. The different types are:
- System Families – Description by Construction Type
- Non Parametric component Family – Description by purpose and Unique Information
- Parametric component Family – Description by purpose and Unique Information not included within the parameters.
Field 3 – Unique Identifier
Whilst the description should normally provide a unique name there may be occasions where additional information is required. Therefore additional information can be included as part of the unique identifier. A typical Revit implementation would be hosting. Here the same family description for a light fitting may be that it is ceiling or wall hosted.
System Families – Descriptions by Construction Types
Revit system families such as walls etc. should be described using first the system and then the usage, which may be derived from the descriptions in a classification system (E.g. Wall External) and then the width and component type. The Usage and component lists should be considered as separate fields within the names and separated by an Underscore. Multiple widths and materials are defined as components and can be identified this way and each component should be separated by the use of a hyphen (-). Standard acronyms representing components should be used and these should be documented
Example Single Component Wall
Description: Oakley CAD Services Ltd External 300mm Generic Wall
| Field 1 | Field 2a | Field 2b | Field 2c, 2d, 2e, etc… | Field 3 (optional) |
| (Optional) | System | Description by Construction Types | ||
| Owner | Family Category | Usage | Width-Component | Unique Identifier |
| OCSL | Wall | Ext | 300GEN |
Example Multiple Component Wall
Description: Oakley CAD Services Ltd Partition Wall 25mm Gypsum Wallboard, 50 mm Metal stud 25mm Gypsum Wallboard.
Name: OCSL_Wall_Part_25GWB-50MStud-25GWB
| Field 1 | Field 2a | Field 2b | Field 2c | Field 3 (optional) |
| (Optional) | System | Description by Construction Types | ||
| Owner | Family Category | Usage | Width-Component | Unique Identifier |
| OCSL | Wall | Part | 25GWB-50MStud-25GWB |
Where components are used in the description Fields in the Family Name the order in which the descriptors are listed is important. This is different for each family system type, but should generally follow the conventions of for walls external to internal and for slabs or roofs the convention is top to bottom.
Non Parametric component Family – Descriptions by Purpose
Many Revit Families are generic models and therefore the naming of these may need to include the Object Group and its purpose. This may also include sub fields such as style definition, size and materials and still may require another unique identifier. The following table shows examples of how the description field may be broken down for a non-parametric family.
Example Name for OCSL-KitchenUnits-BaseDouble-Shaker-600X500x870-BeeachPanel_Glazed
| Field 1 (Optional) | Field 2 | Field 3 (optional) | ||||
| Owner | Description by Purpose | Unique Identifier | ||||
| Field 2a | Field 2b | Field 2c | 2d | 2e | ||
| Owner | Family Category Group | Purpose | Style | Size | Materials | |
| OCSL | Kitchen Units | Base Double | Shaker | 600 x 600 x 870 | Beech Glazed Panel |
Parametric component Family – Descriptions by Purpose
Where parametric families are used family names would not include parameter information, but this information should be provided within the Family Type name to provide a full understanding of the description of the family.
Taking a parametric Kitchen Unit which has Geometry parameters for Width, Length and Height plus also has parameters to control the materials to be used, as well as parameters controlling the door infill panel type, the following naming convention should be adopted:
| Field 1 (Optional) | Field 2 | Field 3 (optional) | ||
| Owner | Description by Purpose | Unique Identifier | ||
| Field 2a | Field 2b | Field 2c | ||
| Owner | Family Category / Group | Purpose | Style | |
| OCSL | Kitchen Units | Base Double | Shaker |
Type Name Example
The Type names would then provide information regarding the values of specific parameters that control the Family types. In the following example this includes geometry parameters of Width, Depth and Height, material and specific material usage to create panel types.
Family Type Name = 1000x600x870_Beech_GlazedPanel
Family Type Name = 1000x600x870_Beech_SolidPanel
Family Types = 1200x600x870_Beech
Family Types = 1200x600x870_Oak