ANZRS V3 01-2012 Fullpack 4f1c1c896ade6

Version 3 [01-2012]
ANZRS Committee
Michelle Van Kolck (Louw)
Consultant
Project Facilitator and Co-Author
Michelle Van Kolck is known in the Revit community for her

unwavering passion for appropriate and well-made Revit content. She
has used Revit since 2003. Her favourite system development project
was for a national supermarket store, Woolworths, in 2007/8. The
brief was strongly focused on the standardization of documentation
(across 7 offices and 3 different documentation departments). The
system produced automated fit-out purchases, custom-unit layouts
and defined delivery by stages on site. Since then Michelle has
worked in other national and global roles for architectural firms;
Woods Bagot, Mirvac Design and PDT Architecture.
Michelle has been on the ANZRS project since its inception and has
been leading this industry initiative with more than 100 registered
members since June 2009.
Belinda Hodkinson
Sinclair Knight Merz (SKM)
Co-Author
Belinda is the BIM Development Manager at Sinclair Knight Merz. Her

attention is based on the development of BIM and implementing a
structured collaboration between all facets of the AEC industry. Her
experience in Revit has been on the move since Version 4.5 in 2002
with a commitment to empowering a companys delivery from the
product. Belinda is focused on the fully integrated practice and
endeavours to achieve this not only for individual firms but for the
AEC industry as a whole. She believes BIM is only the beginning of
this technology enhancement in the AEC industry and is looking
forward to exploring what is next.
Chris Needham
C3 Consulting Solutions
Co-Author
Chris Needham is the owner and director of C3 Consulting Solutions,

a consulting firm specialising in BIM systems development and
implementation.
He is committed to both strategic and technical best practice, and
enjoys creative problem solving. Hes a great communicator; fluent in
both management-speak and technobabble.
He has worked on projects in both Australia and the United Kingdom,
using his expertise to develop custom systems and processes for
numerous offices. Over the last seven years, he has helped firms
understand and implement BIM methodologies, and is passionate
about exploiting BIM technology to its limits. He acknowledges that
despite developments in technology, altering peoples behaviour is
the most crucial and often difficult part of change.
He has taught hundreds of industry professionals across Australia,
and students at both RMIT and Melbourne University. He is
Partnerships Manager for RTC Events Management, steering
AUS
committee member of BIM-MEP , and a past chairperson
of REVIC (Revit Users Group of Victoria).
ANZRS_ABOUT COMMITTEE & PROJECT, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG 2/3

About ANZRS The Australian and New Zealand Revit Standards (ANZRS) was an
initiative conceived at RTC 2009 in Melbourne in response to the
Revit user communitys frustration with lack of consistency and
quality in Revit families available from Autodesk, Content Creators
and other sources.
Its been a mammoth effort, and not without the contributions of

dozens of volunteers, but RTC 2011 marks the first public release of
the Australian and New Zealand Revit Standards for Content Creation
and Management.
The project has attracted interest globally.
Feedback was received from a number of contributors during the

recent peer review process, and this has been integrated within the
body of the work. On the basis of what was presented during this
review, several local content creation firms have already agreed to
adopt the standards. These include KarelCAD (DesignContent), Benn
Design and ProductSpec.
The document pack constitutes:
Introduction and project contextual information

Forms articulating criteria to be met in order to comply with
the standards
Reference material to assist content creators to surpass
minimum requirements
The Revit Content Model Style Guidelines produced by Autodesk

were the first widespread effort in this direction. However, we find
some of their prescriptions and guidelines lacking, so we figured wed
form part of the solution by contributing our own for public use.
ANZRS addresses content standards for Autodesk Revit only. It

does not attempt or purport to be a product or vendor-neutral
standard. This was predominantly because such efforts require
enormous amounts of effort and buy-in from so many parties, and
sometimes made more complex by proprietary limitations. We felt
that if we could help get the Revit-aligned part of the industry to agree
on something, that it might be an easier step to take to get everyone
on board to something greater.
The committee is actively in dialog with other related parties and

projects, in the interests of optimizing our alignment with them and
vice versa. Such initiatives are:
AUS
AMCAs BIM-MEP
AEC(UK) BIM Standard, and;
BuildingSmart
Acknowledgements AEC Systems, Anthony Bowden, Antony McPhee, Ben May, Benn
Design, Bo Zhen, Cadgroup, Chris Price, Flavio Yamauti, Ian
Matthews, KarelCAD, Kevin Thickett, Matthew Pettengell, Melanie
Tristram, Nubar Van Kolck, Paul Hellawell, Russell Hamblin, Stewart
Caldwell, Toby Maple, Wesley Benn
Graphics assistance : Franz Hein
ANZRS_ABOUT COMMITTEE & PROJECT, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG 3/3

REVIT FAMILY CREATION PACK - VERSION UPDATE L0
This letter provides a brief overview of what improvements have been madeto
theANZRSPack,Version3[012012]
WHATS NEW IN VERSION 3? Version 3 [01-2012]
We wanted to add a personal note to this pack to say thank you for downloading this
Countries:
version (Version3) of the ANZRS pack and for your continued support. Its hard to believe
that six months have already passed since the last release of ANZRS and we are excited to Afghanistan
share some of the improvements that we have made since the previous (Version 2) pack. Algeria
Argentina
We have kept significant changes to a minimum, as promised, but have worked hard to take
Australia
all your feedback into consideration and to present a new pack that would be easier to
navigate, more useful and hopefully more practical to implement - to whatever extent you Austria
wish to adopt. Azerbaijan
Bahrain
We wanted to take this opportunity to share with you the progress that we have made since Barbados
the public release of ANZRS Pack, Version 2. Belgium
Bolivia
Brazil
1.0 ANZRS pack Version 2, downloaded in 72 countries
Bulgaria
Weve been delighted to see the extent to which the ANZRS pack has been Canada
downloaded from countries all over the world, in just a matter of months.
Chile
This has far exceeded the expectations of the committee, and demonstrates that China
there was and is a great deal of interest in good content creation methodologies Croatia
and standards.
Cyprus
Even though these standards were originally designed specifically with Australia
CzechRepublic
and New Zealand it is possible that this project may be able to affect the quality of
Denmark
shared and sold Revit components irrespective of country or region.
DominicanRepublic
Thank you to everyone for spreading the word and for supporting this project.
Egypt
Estonia
Finland
France
Germany
Ghana
HongKong
Hungary
Iceland
India
Indonesia
Iran
Ireland
Italy
Kuwait
Lebanon
Lithuania
Malaysia
The map above shows all the countries (72, shaded in blue) where the Mexico
ANZRS pack has been downloaded since July 2011, when the ANZRS
pack became available on our website. <NextPage>
ANZRS_L0_UPDATE OF ANZRS PACK, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG. 1/2

REVIT FAMILY CREATION PACK - VERSION UPDATE Version 3 [01-2012] L0
2.0 Support and industry discussions

ANZRS and AEC (UK) BIM Standards have a reciprocated endorsement agreement. Countries:

The two groups will continue to work together to improve their respective initiatives. Montenegro
ANZRS implementation statistics are soon to be established via a short survey, but
Netherlands
several key large projects and organisations have already committed to ANZRS. The
project value so far (that ANZRS is aware of) tallies more than $6billion.
NewZealand
ANZRS and AMCAs BIM-MEP
AUS
initiative continue to work together. In short, Revit Nigeria
AUS
content for BIM-MEP initiative shall, by agreement, comply with ANZRS. Norway
Pakistan
Palestine
3.0 We have listened Now you will have a more user-friendly pack Philippines
No password is required to read the PDF document pack Poland
The PDF portfolio format has been terminated in favour of a more conventional Portugal
format, making it easier to navigate and read
PuertoRico
The pack can now be viewed in PDF form on tablet computers (e.g. iPads)
Qatar
Improved graphic design and layout, including bookmarks
Romania
Additional discipline-specific checklists for compliance requirements
Russia
SaudiArabia
4.0 Improvements made in ANZRS Pack, Version 3: Serbia
Checklists available as a separate download, for easier digital input and aggregation Singapore
Additional MEP subcategories Slovenia
Some improvements to MEP Shared Parameters For a more comprehensive list of SouthAfrica
changes refer to Change Log: Version 3 (at the end of this document pack) SouthKorea
Spain
Sweden
5.0 Feedback
Taiwan
Feedback has been taken on board and responded to via email. Thailand
If you are trying to apply part or all of the ANZRS standard in your firm and you are
Togo
not from Australia or New Zealand, please dont hesitate to contact us for guidance
or to offer feedback. We are very interested to hear from Revit leaders in other Turkey
countries that are adapting the ANZRS standards to suit their firm or country specific Tuvalu
requirements. We have established dialogues with some key players in other Ukraine
countries already. UnitedArabEmirates
Please keep in mind that this initiative is currently still run by volunteers. UnitedKingdom
Consequently, at times there may be some delay in responding to your feedback. We
UnitedStates
do however endeavour to respond to all feedback in a timely manner.
As always, we value your comments and thank you for your feedback. This is a Venezuela
community-based initiative. You can contribute directly to future improvement of the Vietnam
ANZRS initiative. Keep it coming!
6.0 Do you want to become part of the ANZRS team?

If you wish to be part of this project and assist with future developments please dont hesitate to contact us
through the website feedback form.
We are looking for various new skills to add to our team which include discipline-specific Revit leaders as well as
finding assistants to work with us on marketing, possible API development and publishing opportunities.
7.0 Sponsorship and Funding

We remain open to any funding and sponsorship opportunities. We also welcome any support that could assist us
in developing these standards further.
Please contact us if you would like to sponsor this initiative.
ANZRS_L0_UPDATE OF ANZRS PACK, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG. 2/2

REVIT FAMILY CREATION PACK INTRODUCTION AND CONTEXT L1
ThisletterservesasanintroductiontotheAustralia&NewZealandRevitStandards
pack.Itexplainswhatisconsideredgoodcontent,asdefinedinthisproject,aswell
asdiscussingthebackgroundandcontextofthisindustryinitiative.
LETTER OF INTRODUCTION Version 3 [01-2012]
COPYRIGHT
This work is protected by copyright. You may download, display, print and reproduce this material in unaltered form
only (retaining this notice) for your personal, non-commercial use or use within your organisation. Apart from any
use as permitted under the Australian Copyright Act 2011 and New Zealand Copyright Act 2011, all other rights are
reserved.
Requests and inquiries concerning reproduction and rights should be addressed via email to copyright@anzrs.org.
DISCLAIMER
It is our vision these proposed standards will obtain industry support from commercial content creation companies in
Australia and New Zealand, together with the Revit user community. The criteria provided within this document pack will
then become the minimum benchmark of all shared and sold content throughout both countries. A content creator can
then claim to provide ANZRS compliant content if the compliance requirements listed are met on those specific
components that they sell.
ANZRS_L1_LETTER OF INTRODUCTION, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG. 1/5

LETTER OF INTRODUCTION VERSION 3 [01-2012] L1
1.0 INTRODUCTION
This initiative commenced following a lengthy and passionate discussion that took place at the Revit Technology
Conference in Melbourne, during June of 2009. The primary issue was the lack of quality and usefulness of the Revit
content that was available at the time, from either Autodesk (i.e. shipped with the software and/or available from the
Autodesk website), or content creators. It was suggested that content available from external sources (whether shared or
sold) had not yet provided what the industry representatives at the conference needed. While Revit content was largely
something firms were responsible for themselves, it was felt that Autodesk (or some other party) should be doing more to
solve the duplication of effort that was overwhelming many of those present.
In the absence of a defined content creation standard (or other benchmark) and its acceptance within the industry, the
interoperability advantages promised by BIM practices were not materialising at least as far as digital content creation and
exchange was concerned.
Theres an old saying: If youre not part of the solution, youre part of the problem. Taking a proactive approach, a team of
key stakeholders (already present at the conference) were assembled to formally address the issue. This team included
representatives from design firms and content creators. Following the conference, a wiki website was created that would
allow continued contribution from a broader base of stakeholders. The website was set up to facilitate a constructive debate
and eventually establish a common wish list for shared and sold Revit content across various industry disciplines.
Contribution was invited from this group, which consisted of more than 100 members, and included:
BIM Managers
CAD Managers
Architects
MEP Engineers
Structural Engineers
Interior Designers
Documentation Specialists
API software developers
Quantity surveyors
Professional Revit content creators
2.0 REVIT MODEL CONTENT STYLE GUIDELINES

Autodesk, as it turns out, had at this time already assembled a team to develop a series of guidelines that would (at least to
some extent) alleviate the issues described. Autodesk published a document called the Revit Model Content Style
Guidelines, and it was accompanied by a series of other supporting documents. It remains freely available to anyone at
http://seek.autodesk.com/revit.htm. For the purposes of this document, Autodesks publication shall be abbreviated to
RMCSG.
In response, this ANZRS initiative accepts many of these guidelines, as defined by the RMCSG. However, the contributing
team felt that in some areas, these Guidelines did not adequately address the issues, nor explain the rationale behind the
suggested practices. In other areas, it was felt that the suggested practices fell short of what the contributing team believed
was good practice. Differences between the RMCSG and the ANZRS initiative have been included and highlighted within
the body of work that follows.
Autodesk is aware of this initiative and is supportive of any feedback that results from this project.
3.0 VISION
The vision for the initiative is that these standards and best practises can be adopted by content creators throughout
Australia and New Zealand.
4.0 OBJECTIVES
The primary objectives of this project are to:
Establish minimum compliance requirements for Revit content shared or sold throughout Australia and New
Zealand. Compliance with these requirements should provide a measure of quality and certainty to future recipients
of this content, whether by sharing or selling of content.
Document Revit content creation best practises. These may exceed the minimum compliance requirements.

Establish a more extensive collection of Shared Parameters that, where used, will offer:
o improved consistency of content and associated parameters
o simpler, more consistent scheduling of object data
o greater interoperability of content between subscribing parties
Establish a list of object subcategories that, where used, will offer:
o improved consistency of content and associated parameters
o simpler, more familiar control over display properties of the included subcategories
o greater interoperability of content between subscribing parties
Discipline-specific requirements for Revit Content (where not already included in the general documentation).
These have been developed for:
o Architecture and Interiors
o Structural
o Mechanical, Electrical and Plumbing (MEP)
5.0 DEFINITIONS
In the context of this initiative, Content is defined as:
Digital representations of building products, components or assemblies, created using Autodesk Revit software.
The pursuit of good Content also requires a definition. For the purposes of this initiative, and in its most succinct form,
good Content is:
[Content as described above]... that is fit for its intended purpose by its end users.
Due to the developing level of maturity of BIM (as practised within the ANZ AEC industry), further definitions of intended
purpose and end users are also required. As such, the following generalized characteristics for good Content are offered,
while the remainder of the documents from this initiative attempts to offer more detailed definitions in practical terms.
Good content is content that:

Subscribes to basic principles and performance criteria of Building Information Modelling (BIM) that is, the use of
consistent, clear, logical, useful and re-usable parametric data by various design and construction-related
disciplines and end users
Is robust and stable, while allowing sufficient flexibility for reasonable uses and applications
Provides evidence of a consistent, standard methodology to its creation
Provides for its intended use by its intended end users i.e. function properly (this requires some in-depth analysis
of who its users are and what its intended use is. This is partially addressed in document L3).
6.0 STAKEHOLDERS
The stakeholders of this initiative are those that stand to benefit from this work and its adoption by content creators (whether
designers, manufacturers or others). They include, but are not limited to:
Architects Interior Designers
Building Owners Quantity Surveyors
Building Developers Real Estate Agents
Building Product Manufacturers Services Engineers
Construction Firms Structural Engineers
Facility Managers Subcontractors/Specialty Contractors
7.0 MEASURES OF SUCCESS

There are several responses to this initiative that would constitute measures by which we can assess the success of this
effort. They include:
The information in this document serving as a platform for further discussion between key stakeholders with a view
to reaching even better outcomes in the future (i.e. that this initiative serves as a means to an end)
From Australian and New Zealand-based Revit Content Creation organisations:
o Survey feedback indicating:
A growth in sales/downloads of content that subscribes to the contents of this document
Acceptance of the standards and/or best practises included within this document, evidenced by
written indication of their intention to implement them for future content creation

Results of a feedback survey sent to all RTC delegates and/or other representatives of the firms they work for that
have implemented Autodesk Revit software:
o Indicating a level of acceptance of this document and its contents of 30% or better (more in due course)
o Indicating an intention to implement the standards and/or best practises included within this document for
future content creation (and within a nominated period)
o Indicating that content received from external authoring parties is more viable and valuable than before
that party implemented these standards. That is, that the content is useful and will be used within their
organisation with little or no firm-specific customisation.
Other responses that would be considered favourable but that indicate a measure of success beyond the defined
scope for this initiative include:
o A closer working relationship between the ANZRS group and the Autodesk team that authored the Revit
Model Content Style Guidelines.
o Incorporation of some or all of the standards and best practises included within this document by Autodesk
as part of the next iteration of the Revit Model Content Style Guidelines.
8.0 EXPRESSIONS OF VALUE

The value of this project overall can be expressed in the following terms:
o Exchange of content between multiple stakeholders that is consistently created and fit-for-purpose
o Reduced duplication of content creation within the Australian and New Zealand Revit user and Content
Creator community inclusive of Building Product Manufacturers and those creating content on their
behalf
No quantification of this value has yet been determined, but anecdotal evidence from RTC attendees supports the
notion that at least for them, the value would be substantial.
9.0 STATEMENT OF LIMITATIONS

This initiative is the result of a collaborative effort of a number of people. At various stages, a great deal of feedback has
been provided on a wide array of topics. In this first release, we acknowledge that there are limitations on the depth of
information provided for the discipline specific best practices particularly for the Structural and MEP disciplines. This is
ultimately due to an absence of more contribution from leaders in those industry sectors. While the level of discipline specific
contribution was not ideal, continued constructive criticism and feedback is actively encouraged and sought.
10.0 FUTURE SCOPE

There remains more work to be done to develop these requirements into something that can warrant widespread
acceptance. It is acknowledged that additional information may be required. Parts of the scope items below may require
additional resources to be completed.
10.01 PARAMETERS
o Grouping of parameters beyond what is listed in the Shared Parameter (C5-C7) lists
o Provide a large array of a samples of family parameter names (shared parameter names are already provided
in SP lists)
o Extended list of Shared Parameters (incorporating new approved parameters as suggested through Review
processes)
10.02 MATERIALS
o Provide a large array of sample material names to better demonstrate the intended syntax and structure
o Provide a (near-)exhaustive list of Material Classifications
10.03 FAMILIES
o Provide a collection of family template files that are (in that empty state) compliant with ANZRS requirements
(i.e. line patterns, fill patterns, object styles, shared parameters, material naming, named reference planes).
o Provide a collection of sample families of various categories that are compliant with ANZRS requirements.
o Lists of organisations that are committed to adopting ANZRS standards

10.04 GRAPHICS
o Provide more illustrations and diagrams to aid explanations and descriptions
10.05 QUALITY CONTROL

o Create software-based tools that will automatically check (and in some cases, fix) various criteria mandated by
ANZRS
11.0 FEEDBACK
Feedback and other information of value to the advancement of this initiative can be provided via email, to
feedback@anzrs.org or via the feedback form(s) on the ANZRS website.
READERS NOTES:
It is our vision that these proposed standards will receive the promised support from the dominant commercial content creation
companies in Australia, New Zealand as well as the Revit user community.
It is our intent that the criteria provided within this document pack will become the minimum benchmark of all shared and sold content
throughout Australia and New Zealand. A content creator can only claim to provide ANZRS-compliant content if the compliance
requirements listed in this document are met on the respective components that they sell.

ThisletterexplainshowtousetheAustralia,&NewZealandRevitStandards(ANZRS)
pack.Itexplainsthepurposeofeachofthepackresourcesandhoweachresource
shouldbeused.
HOW TO USE THIS PACK Version

Version
Version 33 [2011]
3 [2011]
[01-2012]
1.0 BASIC CONCEPT OF PACK

It is important to note that the ANZRS Family Creation contains (a) defined standards that form part of a minimum
compliance standard and (b) additional documentation that provides additional information, tips, tricks and a checklist for
advanced family creation features. The advanced family creation features are optional and do not form part of the minimum
compliance criteria.
2.0 DIAGRAM TO EXPLAIN DOCUMENTATION SET

The following diagram graphically displays how the pack is arranged.
INTRODUCTION
& CONTEXT
LETTERS
L0 L1 L2 L3 L4
GENERAL COMPLIANCE
CHECKLIST &
ASSOCIATED SUMMARY
C1 C1s
DISCIPLINE SPECIFIC
CHECKLIST &
ASSOCIATED SUMMARY
C2 C2s C3 C3s C4 C4s
SHARED PARAMETERS
TABLE C5 C6 C7
SUBCATEGORIES
TABLE C8
ADVANCED FEATURES
CHECKLIST &
ASSOCIATED SUMMARY
R1 R1s
BEST PRACTICES
A-Z TABLE R2
ANZRS_L2_HOW TO USE THIS PACK, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG. 1/3
HOW TO USE THIS PACK VERSION 3 [01-2012] L2
3.0 DOCUMENTS CONTENT OUTLINED IN TABLE FORMAT

This pack comprises a range of material intended for a variety of purposes. Each document is described below.
FORMS INTRODUCTION L
L0 Version Update
L1 Letter of Introduction
L2 Contents & How To Use This Pack
L3 Generic vs. Building Product Manufacturer-specific content
L4 Glossary of Terms
L0 outlines the latest version updates and gives an overview of the packs development and
impact / take up within the industry.
L1 serves as an introduction to the Australia, & New Zealand Revit Standards pack. It explains
what is considered good content, as defined in this project, as well as discussing the
background and context of this industry initiative.
L2 explains how to use the Australia, & New Zealand Revit Standards (ANZRS) pack. It
explains the purpose of each of the pack resources and how each resource should be used.
L3 discusses one of the primary issues behind the need for this initiative. The major
approaches to content creation and its end use between the various stakeholders in the
AEC/FM industry vary considerably. Primarily the major types of content that are discussed
are Generic Content and Building Product Manufacturer-specific (BPM) Content.
L4 this glossary contains key words that appear frequently in the ANZRS Pack. These
acronyms will be included in areas such as the compliance checklist and its summary so it is
imperative to understand their meanings.
These are the introductory documents to this pack.
FORMS COMPLIANCE (ALL DISCIPLINES) C1

C1 Minimum Compliance - Checklist
C1s Minimum Compliance - Summary of Requirements
C1 serves as a simple, brief checklist for content authors or auditors to use to ensure quality
and performance requirements are achieved. All items in this checklist must be satisfied for
each component to be deemed compliant with ANZRS.
C1s is to be used in conjunction with C1, and includes explanatory information about each
item to be checked.
These documents must be adhered to in order to comply with the Australia and New Zealand Revit Standards (ANZRS) for
content creation.
FORMS COMPLIANCE (DISCIPLINE SPECIFIC) C2 - C4

C2 Architectural/Interiors Compliance - Checklist
C2s Architectural/Interiors Compliance - Summary of Requirements
C3 Structural Compliance - Checklist
C3s Structural Compliance - Summary of Requirements
C4 MEP Compliance - Checklist
C4s MEP Compliance - Summary of Requirements
C2, C3 and C4 each set out discipline-specific requirements for Architecture/Interiors,

Structural and MEP, respectively.
C2s, C3s and C4s is to be used in conjunction with C2, C3 and C4, and includes
explanatory information about each item to be checked.
These documents must be adhered to in order to comply with the Australia and New Zealand Revit Standards (ANZRS) for
content creation.
HOW TO USE THIS PACK VERSION 3 [01-2012] L2
FORMS SHARED PARAMETERS (DISCIPLINE SPECIFIC) C5 C7

C5 Approved Shared Parameters List Architecture/Interiors
C6 Approved Shared Parameters List Structure
C7 Approved Shared Parameters List MEP
C5, C6 and C7 are tables of Shared Parameters for Revit (again, for Architecture/Interiors,
Structural and MEP, respectively) that, when incorporated by multiple content creation
sources, will achieve a previously unmatched level of interoperability and consistency
between content and how it is scheduled.
The shared parameters within these documents must be adhered to in order to comply with the Australia and New Zealand Revit
Standards (ANZRS) for content creation.
Any additional shared parameters that have not been listed in these documents can be created by the content manufacturer and
named according to their preferred standards. Naming conventions have been recommended in R2 (Best Practices) section.
FORMS SUBCATEGORIES C8
C8 Subcategories List
C8 is a table of Object Style Subcategories that, when incorporated by multiple content

creation authors will achieve an improved level of interoperability and consistency across
such content, and its visual representation.
The subcategories within these documents must be adhered to in order to comply with the Australia and New Zealand Revit
Standards (ANZRS) for content creation.
Any additional subcategories that have not been listed in these documents can be created by the content manufacturer and named
according to their preferred standards. Naming conventions have been recommended in R2 (Best Practices) section.
FORMS CHECKLIST SUMMARY OF ADVANCED FEATURES (OPTIONAL) R1

R1 Optional Checklist
R1s Optional Checklist Summary of Advanced Features
R1 serves as a simple, brief checklist for content authors or auditors to use when design,
auditing and refining their content. All items in this checklist are optional features that content
creators or companies may choose to adopt in part or as a whole. Obviously the more of
these features a component has the more user-friendly and advanced (in terms of good
quality content) a component is considered to be.
R1s is to be used in conjunction with R1, and includes explanatory information about each
item to be checked.
These documents are optional and designed for those who require or desire a quality of content that exceeds the minimum
requirements.
FORMS SUMMARY OF GENERAL BEST PRACTICES ALL DISCIPLINES R2

R2 Summary of General Best Practices All Disciplines
R2 is a summary of general Best Practices for all disciplines. This document is intended to
be used for cross-referencing all other documents in the pack and expands on best practices
and other tips and tricks in regards to creating stable and well made Revit content.
These Reference documents include information topical and contextually relevant to this pack.
4.0 CONCLUSION
This pack has been segregated and condensed to allow easy reference to necessary information for specific tasks. Not all
of it will be required for every item of Content produced. Moreover, it is anticipated that as familiarity develops with this
information, the checking process becomes significantly faster and easier.
Thispaperdiscussestheoptionsthatcontentcreatorsshouldconsiderwhenmaking
sharedand/orsoldcontent.ShouldcontentbebuilttobegenericorBuildingProduct
Manufacturerspecific(BPM),andwhatarethebenefitsand/orlimitations?
GENERIC VS SPECIFIC Version 3 [01-2012]
1.0 UNDERSTANDING THE ISSUE

In establishing what is meant by fit for intended purpose, one key issue must be addressed: the purpose of the
Content, the needs of the user and what constitutes value all varies for each user.
A distinction must be drawn between what constitutes value to the designers within the BIM process, and to the
manufacturers of the real-world products. Much of the Content developed to date has been authored by three distinct
parties:
Design firms
Specialist Content Creators, and;
Building Product Manufacturers
Without an in-depth understanding of this issue, the objectives and even the methodology for the creation of the
Content can be conflicted. This document explains the potential conflicts that are apparent between the two Content
types at this time.
2.0 TARGET AUDIENCE

The target audience for this document is:
Design firms (i.e. architecture, interior design, structural engineering and services engineering)
Content Creation firms
While the contents of this document may be useful in educating and informing manufacturers of the needs of design
firms, the intention is not yet to cover all the requirements of a products life-cycle in detail.
3.0 THE VALUE OF INFORMATION DURING THE DESIGN LIFE-CYCLE

As a project lifecycle commences, there is often little information known relative to the quantity available during later
phases. When little information is known, it only takes a small amount to be useful that is, by reducing uncertainty.
When only a small amount of uncertainty exists, it takes considerably more information and effort to achieve a
significant amount of certainty. Typically, during the design life-cycle of a project:
Less resolution is required early; more resolution is required later

Less information is required early; more information is required later
Less detail is required early; more detail is required later
The variation in what constitutes appropriate levels of detail is central to this issue of Generic vs. Building Product
Manufacturer-specific (BPM) content. Generic Content items typically contain less detail than BPM items. As a
simple rule, less detail equates to smaller file sizes and a lesser impact on computer (hardware and software)
performance though some exceptions are possible where good content creation techniques are employed.
What represents value in Content to a designer is often quite different to what represents value to a Manufacturer.
Building Product Manufacturers typically assume a need to have the level of detail in their Content match that of the
real-world products. This is sometimes applied literally by the Content authors to the detriment of the appeal of the
Content. Content authors need to help educate Building Product Manufacturers about the balance required between
level of detail (and precision) and performance.
As an example, whether a curved surface has a 1mm radius or a 1.2mm radius or no radius at all may not make any
difference to the design or construction of the project. How this can be of value beyond construction that is,
through the remainder of the building or product lifecycle, is unclear, and quite possibly unnecessary.
Rather than actually adding value to the Content, the application of this extreme level of detail can be counter-
productive and ultimately undermine the use of the Content by designers (and others) altogether. By employing the
standards and best practices described in this document pack; Content creators can achieve better Content in
terms of performance and value, to users throughout the Project lifecycle.
ANZRS_L3_GENERIC VS SPECIFIC, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG. 1/4

GENERIC VS SPECIFIC CONTENT VERSION 3 [01-2012] L3
4.0 POTENTIAL CONFLICTS BETWEEN GENERIC CONTENT AND PRODUCT-SPECIFIC CONTENT

The following table sets out potential conflicts in needs and value to both groups:
No. Title Generic Content Product-Specific Content

1 Creation Designers Manufacturers or Content Creators acting on
typically their behalf
driven by
2 Need Products are typically not specified during early Manufacturers want their products to be
driving its design stages of a project therefore generic specified; the greater levels of detail and
creation items are used instead. They may be replaced at information are more reliable during construction
such time as more specifics are known or planning and coordination
determined, or their use may continue, with
additional data and physical constraints applied
as appropriate to allow the Content to continue to
serve as being representative of the specified
object(s).
3 Used by Designers, or others where Product-specifics are Designers, Builders, Sub-contractors, Facility
not known or required. Similarly, where product- Managers, Building Owners
specific data is required, it can be added to
generic content to improve its function and value.
4 Description A designer wants to make decisions in an A manufacturer wants Content to be an accurate
of usage iterative fashion, adding more detail building on digital representation of their real-life content
decisions made earlier. This begins with little from the moment it is first used. This includes
information, little detail and progresses towards physical properties and associated performance
much information, much detail. data. During pre-construction planning and
construction, this level of information is certainly
of value particularly for the Managing
Contractor and those subcontracted. By this
time, the design is (supposedly) fixed, and the
information value for designers has essentially
peaked.
5 Issues for It provides for a variation in the amount of In some cases, firm rules or industry law
Designers information required or used as the project precludes specification of manufacturer-specific
progresses through each project phase. Content until tender has been awarded to a
winning supplier/installer.
6 Content development costs borne by the Content developed by Manufacturers (or their
Designers, rather than the Manufacturers of the agents) does not meet the needs of Designers
end product. Generic Content is scarcely at least not during early, iterative and fluid stages
available for sale, as its development has no of design. Having each Manufacturers products
single direct sponsor, yet it potentially allows for created by a number of authoring parties only
greatest cost-benefit scenario where generic adds to the overall costs of creation and
Content is complemented by product specifics as management of the Content.
required to fulfil its purpose(s).
7 Level of precision and certainty offered by the Superior certainty of information (and value
information is limited to the extent of design intent offered by that certainty) is achieved using this
communicated through the content. Additional content whether for cost estimation, quantity
data pertaining to the actual specified products estimation, delivery scheduling,
may be added later without consequence to assembly/prefabrication, performance analysis,
construction. constructability and coordination, and clash
detection.
8 The use of Generic Content may constitute a The use of product-specific content can be used
Schematic or Detailed Design Model, which to generate Detailed Design and/or Construction
communicates Design Intent. The value of documents, and may or may not communicate
generic content can exceed this (that is, in means and methods applicable for construction
communicating construction means and methods) purposes.
but typically does not.

5.0 SOLUTIONS
1. To help bridge this gap, manufacturers, content creators and designers must communicate their needs more
definitively.
2. Manufacturers must understand that not all information that can be included with their digital models is of value
to everyone. To the contrary, extraneous data can in fact prohibit its use altogether. This volume of data
generated requires both the technology to drive it, and systems to manage it. Currently, neither is mature. The
potential of Cloud-based Computing may offer a long-term solution, but for now, these issues are real and
significant.
3. Manufacturers and other key stakeholders within the industry need to understand that Generic Content has
fewer limitations for long-term BIM benefits than widely believed. Much of the information that is applicable to a
manufacturers product can be accommodated within well-created, flexible Generic Content leaving the
difference mostly cosmetic. The extent to which Generic Content cannot be used in place of BPM-specific
Content (i.e. during late design phases, and during construction) may vary according to the specific item or
category, and how well it has been created by the author.
6.0 COMMON CHARACTERISTICS OF EACH TYPE OF CONTENT
No. Generic Content Building Product-specific Content Issues for Designers

1 Low-to-medium precision, low- High precision, high detail geometry. Additional precision and detail is low
to-medium geometric detail. on relevance and low on value for
design purposes;
Performance issues caused by
excessive detail or volume of
information can reduce the useability
or entirely prohibit the use of the
object;
Detail Levels cannot be controlled by
the end user, resulting in unreadable
graphics at coarse scales.
2 Data fields can be created for Data fields are defined and rigidly Content used is more reliable and
scheduling purposes to contain applied, in order to reflect Building consistent, given that it is only data
critical manufacturer-specific Product Manufacturer specifications. fields and critical dimensions that may
information. These can be vary between like products.
populated as and when needed,
allowing the component to
continue to be representative of
the BPM equivalent.
3 Materials are typically assigned Materials are created within the Direct control over materials (if
to the content from the project content as direct, virtual equivalents for appropriate) may not exist. Also refer
environment. the real thing to Item 7.
4 Origin point is defined Origin point is defined how/where the Inconsistent origin points between
how/where the designer (or their manufacturer (or their agent the similar components can cause major
content creator) believes is content creator) believes is hassles when one is swapped out for
appropriate. appropriate. another though this issue exists
even for Generic Content on its own.
5 Author determines object Author determines object category Since manufacturers are not end-
category with some without an intimate understanding of users of the digital content in a design
understanding of the impact of the impact of this decision on its use context, they are unfamiliar with, and
this decision on its use within the within the model by other users. often uninformed of typical design
model. workflows and related requirements.
6 Modest use of nesting; cautious Multiple instances or levels of nesting; Performance issues caused by
of producing unjustifiably often unwarranted and/or without unwarranted nesting of geometry can
obstinate or unmanageable comprehension of, or appreciation for reduce the useability or entirely
content (particularly on large the consequences on the objects use prohibit the use of the object.
projects). in large project models.

No. Generic Content Building Product-specific Content Issues for Designers

7 Flexibility required of high-value Low or poor application of parametric The components parametric
generic components requires a behaviour. Note that this is not always relationships may not be robust enough
robust model. The term avoidable or inappropriate. to warrant use within the model.
Reasonable use has a much
broader application.
8 Organization standards applied Nomenclature applied to elements and The lack of industry standards with
to modelling tend to proliferate their properties (such as object styles, respect to these items is one reason
through their own content (if parameters, filled regions, line patterns why this document was assembled.
theyre lucky!). Rogue systems and materials) is unique to the Similarly, this is why the Shared
are obvious, contrary, manufacturer, unfamiliar to the Parameter list was created to
sometimes duplicitous and designer, and inconsistently applied. overcome the scheduling issues
disruptive. Parameters required for tagging and presented by use of user-created
Consistent use of a single set of scheduling are recognized by the Shared Parameters
Shared Parameters is relatively software by unique identifiers (GUIDs).
easy to achieve. Therefore scheduling of elements from
various manufacturers is inconsistent,
problematic and prohibitive.
This can be mitigated by using
standardized Shared Parameters
within the Content (contained in this
document package).
7.0 SUMMARY
Designers must recognise that manufacturer-specific content may not be appropriate for early design applications,
and manufacturers must acknowledge that their performance criteria may not align with those of designers/end-users.
To date, techniques used to reconcile this have included:

1. Use of low-detail generic components as 'placeholders' may be used; these can then be substituted for a more
detailed version when clarity on the item exists and/or when a decision is made for specific manufacturer
content. Such components may or may not be highly parametric, while the former typically provide greater
flexibility to adapt to design changes, and thus usually represent greater value to designers, once design staff
members are accustomed to using and manipulating them in the model environment. The impact and timing of
this substitution needs to be assessed carefully as part of this workflow, and the Content creation process
needs to be defined to accommodate this.
2. Use of both low-fidelity and high-fidelity versions of manufacturer components. This can allow the manufacturer
to have their content used even during the early design stages of a project, without the excess weight of
unnecessary, low-value information.
3. Use of purpose-built, flexible Generic Content that exhibits low specificity during early design to high specificity
during late design (as more certainty exists). Manufacturer- or product-specific data is added to the content as
and when required.
This initiative should help to solve or alleviate some of these classic issues in practical terms. Moreover, it should
stimulate informed discussion and better communication between key stakeholders as end users of the Content.
READERS NOTES:

Thispaperfurtherdefinesthetermsforacronymsusedthroughoutthepack.
GLOSSARY OF TERMS Version3 3[12-2011]

Version [01-2012]
1.0 GLOSSARY OF TERMS

This glossary contains key terms that appear frequently in the ANZRS Pack. These terms are included in areas
such as the compliance checklist and its summary so it is imperative to understand their meanings. It is also
important that the key words should not be interpreted in an overly prescriptive way. We have tried to ensure that
they are not used in ways that conflict with their particular meanings, as defined below.
ACRONYM DEFINITION
#
2D Two-dimensional graphical data
3D Three-dimensional graphical data
A
(A) Architectural
AEC Architecture Engineering Construction
AEC/FM Architecture Engineering Construction/ Facility Management
ANZRS Australian and New Zealand Revit Standards
API Application Programming Interface
B
BIM Building Information Modelling
BP Best Practice
BPM Building Product Manufacturer
C
C1 Minimum Compliance - Checklist
C1s Minimum Compliance - Summary of Requirements
C2 ANZRS Discipline Specific - Architectural/Interiors - Checklist
C2s ANZRS Discipline Specific - Architectural/Interiors - Summary of Requirements
C3 ANZRS Discipline Specific - Structural - Checklist
C3s ANZRS Discipline Specific - Structural - Summary of Requirements
C4 ANZRS Discipline Specific - MEP - Checklist
C4s ANZRS Discipline Specific - MEP - Summary of Requirements
C5 ANZRS Discipline Specific - Shared Parameters - Architectural
C6 ANZRS Discipline Specific - Shared Parameters - Structural
C7 ANZRS Discipline Specific - Shared Parameters - Mechanical
C8 ANZRS List of Approved Subcategories
D
DWG AutoCAD drawing file extension
E
None
F
None
G
GUID Global Unique Identifier
H
HVAC Heating, Ventilation and Air-Conditioning
I
IES Integrated Environmental Solutions
ANZRS_L4_GLOSSARY OF TERMS, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG. 1/3

GLOSSARY OF TERMS VERSION 3 [01-2012] L4
ACRONYM DEFINITION
J
None
K
None
L
L0 ANZRS Letter of Version Update
L1 ANZRS Letter of Introduction
L2 ANZRS How to use pack
L3 ANZRS Generic vs. Specific
L4 ANZRS Glossary of Terms List
Lx Lux
M
(M) Mechanical
MEP Mechanical, Electrical, Plumbing and Piping
N
None
O
ODBC Open Database Connectivity
P
None
Q
None
R
R1 ANZRS Advanced Features - Checklist
R1s ANZRS Advanced Features - Summary of Features
R2 ANZRS Best Practices List
RFA Revit Family File extension
RMCSG Revit Model Content Style Guideline
RTC Revit Technology Conference
S
(S) Structural
SAT 3D ACIS model file
SP Shared Parameter
T
None
U
URL Universal Resource Locator
V
VG Visibility Graphics
W
None
X
None
Y
None
Z
None

GLOSSARY OF TERMS VERSION 3 [01-2012] L4
OTHER TERMS:
READERS NOTES:

REVIT FAMILY CREATION PACK - GENERAL COMPLIANCECHECKLIST C1
This checklistdefinesallrequirementsand
considerationsthatmustbeundertakenwhencreating
contentthatisANZRScompliant.
Thischecklistonlydefines genericcontentcreation
compliancerequirements.
ADD IMAGEHERE
FAMILY NAME AUTHOR
DATE OF AUDIT MODIFIED ISSUE DATE (yyyymmdd.##)
GENERAL REQUIREMENTS [APPLIES TO ALL DISCIPLINES] Version 3 [01-2012]
NO. HEADING SECTIONS COMPLY

1 FILE MANAGEMENT Y N
1.01 Family Naming
1.02 Purging
1.03 File size
1.04 Thumbnail view
1.05 Appropriate CAD use
1.06 Object Classification
2 REFERENCE PLANES Y N
2.01 Named Reference Planes
2.02 Constraints
2 03
2.03 Is Reference
2.04 Not in sketch mode
3 DIMENSIONS Y N
3.01 Dimension to Reference Elements
3.02 Outside Sketch mode
3.03 Neat & Visible
4 GEOMETRY Y N
4.01 Origin Point
4.02 Control by Reference Elements
4.03 Hosted in a Project System Family
5 SUBCATEGORIES Y N
5.01 Family category / template
5.02 Assignment of subcategories
5.03 Subcategory naming
6 PARAMETERS Y N
6.01 Parameter Naming
6.02 Manufacturers & authoring companys
details
6.03 Shared Parameters
6.04 Modified Issue (date)
6.05 Parametric Behaviour
7 NESTING Y N
7.01 Naming of nested components
7.02 Naming of parameters in nested file
ANZRS_C1_MINIMUM COMPLIANCE CHECKLIST, VERSION 3 RESERVED HTTP://WWW.ANZRS.ORG PG1/2

8 TYPES/ TYPE CATALOG Y N
8.01 Type Naming
8.02 Single Type
8.03 Multiple Types
8.04 Catalog Files
SIGNATURE
APPROVED ISSUED
ENTER DATE ENTER DATE
NOTES
SEE SEPARATE CHECKLIST PDF PACK FOR DIGITAL CHECKLIST FORMS.

(AVAILABLE FOR DOWNLOAD FROM WEBSITE AS PART OF ANZRS VERSION 3 SET.)
This form has been created to assist with internal company review procedures. It is not intended for submission to the ANZRS committee.
Refer to C1s COMPLIANCE SUMMARY FORM for definitions of the minimum compliance requirements listed above .
ANZRS_C1_MINIMUM COMPLIANCE CHECKLIST, VERSION 3 RESERVED HTTP://WWW.ANZRS.ORG PG2/2

REVIT FAMILY CREATION PACK - GENERAL COMPLIANCE SUMMARY SHEET C1s
Thisreferencelistdefinestheminimumcriteriatobemetforacomponenttobedeemed
suitableforgeneraluse(includingsellingorsharing)acrossAustralia/NewZealand.This
listonlydefines genericcontentcreationcompliancerequirements.
GENERAL REQUIREMENTS Version 3 [01-2012]
1 FILE MANAGEMENT QUESTION ANSWER

1.01 Family Naming Is the family name compliant with Defined convention:
the convention? <Functional
Type>_<Subtype>_<Manufacturer>_<Descriptor1>
The Functional Type field is designed to hold the highest
level of family information, in terms of purpose e.g. Door,
Window, Furniture, Utilities etc.
The Functional Type field has nothing to do with the Family
Category, but should be used to help web users to find a
component easily in an on-line store through a site search
browser.
For example, a door family must have a Functional Type of
'Door' even though it applies to a system component
placement tool option within the Revit Project environment
e.g. Door_Sliding_6Panel.rfa
The Subtype field holds the next logical level of information
that distinguishes this family type from another e.g. Sliding
Doors vs., Pivot Door etc.
Avoid Manufacturer name or model name if component
represents a generic object type.
Do NOT use spaces, dots or symbols within the family
name (other than underscores '_' and/or dashes '-', but use
them consistently)
All names and parameter labels must be in English.
Refer to Best Practice list (Form R2) for more
information.
E.g. Window_DoubleHung_Acme_Tilting_SashClad,
Column_Baseplate_Generic_2DPlan,
Plant_Chiller_AirCooled_Generic
1.02 Purging Has the family been purged of all Foreign CAD content (DWG/DGN/ADSK)
unused or temporary reference Unused nested families
items? Have all nested components that are used in the host
family also been purged?
(Be sure to check all nested components that are nested
into any other nested component. This is referred to as
levels of nesting. All levels of nested families must be
purged.)
1.03 File size Has the file been compressed to Purge the host and nested family files (as explained
a minimum file size? above)
Compact the file
Minimize the use of nesting, arrays and voids to minimize
file size and improve family performance.
Check that the level of detail (3D or 2D) is appropriate.
1.04 Thumbnail view Has the thumbnail preview been For 3D families: Set a 3D view as the thumbnail view and
set to a clear and appropriate set to display mode: Shaded with edges. Dimensions should
view orientation? not be visible in the 3D view. (Hide in Visibility/Graphics
dialogue)
For 2D families (Profiles, Symbols, Detail Components):
Reference Level view, with reference planes and
dimensions temporarily hidden prior to saving the file. (Do
not hide dimensions permanently through the
Visibility/Graphics dialogue in any working view.)
1.05 Appropriate CAD use Has the file had all non-Revit All ANZRS compliant families must contain only Revit
content (e.g. DWG/DGN imports) native content and not content from a non-Revit software
removed? source (e.g. DWG/DGN imports), refer to Best Practice list
(Form R2) for more information.
1.06 Object Classification Has the family been populated Appropriate classification of the family can help identify it
with appropriate Uniformat and quickly and consistently, for use in schedules, view filters
Omniclass values? and linked databases.
ANZRS_C1s_MINIMUM COMPLIANCE SUMMARY, VERSION 3 RESERVED HTTP://WWW.ANZRS.ORG PG 1/7

2 REFERENCE PLANES QUESTION ANSWER
2.01 Named Reference Planes Have critical reference planes Not every reference plane needs to be named, however
been named? important reference planes should be named to describe the
reference/functionality of the label it relates to.
E.g. 'Offset from Internal wall face' or 'Start Bay Arm - Left'
etc.
The naming of important Reference planes can aid
downstream users in understanding how the family works. It
also aids in quicker and easier editing or repairs of content
by the content creator.
2.02 Constraints Have the dimensions and labels When the dimensions are to geometry it can cause the
been constrained to reference form to react in a different manner than expected. This is
planes; and not directly to due to the sequence or hierarchy of constraints.
geometry? See C1s Section 3 (Dimensions) for compliance
requirements.
2.03 Is Reference Has the Is Reference parameter Strong reference planes are used to allow users to align or
been set appropriately for ALL dimension easily to critical references within the family. For
Reference planes? this reason, set only critical reference planes to have their Is
Reference parameter as Strong Reference.
Default Centre(Front/Back) and Centre(Left/Right)
reference planes should retain their original Is Reference
values.
Refer to Best Practices List (Form R2) for more
information on the functionality of the Is Reference value.
All the reference planes that are NOT used as a reference
in the project should be set to Not a Reference .
To prohibit 'on-screen' editing of instance based dimension
parameters, the reference planes witnessed by the
dimension(s) should have their Is Reference value set to
Not a Reference.
2.04 Not in Sketch Mode Are the Reference Planes visible Reference Planes should be placed outside sketch mode
outside of sketch mode, (where where ever possible. Reference Planes that are created
possible/practical)? within sketches (i.e. inside sketch mode) are invisible in the
'normal working environment'. This methodology does
require content creators to take more care as the family can
have many Reference planes visible in a view. The benefits
however are worth the effort.
3 DIMENSIONS QUESTION ANSWER

3.01 Dimension to Reference Are dimensions referenced Dimensions should not be referenced directly to model
Elements directly to solid/void geometry geometry. Assign dimensions/labels to reference geometry
(Includes: Reference Planes, (form) instead of being (planes/lines/points) where possible. This simple practice
Reference Lines, Reference referenced to the Reference will achieve maximum file stability and behavioural
Points) Planes used to control the form? predictability.
Refer to C1s Section 4 (Geometry) to understand why it is
best (most of the time) to lock geometry sketch linework or
symbolic linework to the associated reference geometry and
then dimension the reference geometry instead of directly to
sketch linework. See next point for more info.
3.02 Outside Sketch mode Are the dimensions placed Dimensions should be placed outside sketch mode
outside Sketch mode where wherever possible. Dimensions or labels that are created
possible? within sketches (i.e. 'inside sketch mode) are invisible in the
'normal working environment'. Where dimensions must
reside within sketches, they should not be hidden, as this
will confuse future editors of the family and make resolution
of issues an unnecessarily difficult process.
3.03 Neat & Visible Are the dimensions placed in Place dimensions beyond the extents of the model
accordance with the family geometry (2D or 3D forms).
creation compliance Change the scale of a view where more space is required
requirements? to accommodate the number of dimensions or length of their
label names.
Ensure dimension labels reside beyond the component's
extents, do not overlap each other and are easy to read.

4 GEOMETRY QUESTION ANSWER
4.01 Origin Point Does the Origin location of the Once the family has been issued into the public domain,
family suit logical placement the origin point must remain unchanged to ensure the
within the project environment? subsequent reloading of updates to the component does not
cause existing versions of the component to move within the
project environment.
If the origin location is not ideal, but the family has already
been issued, the consequences of updating the family's
origin location can outweigh the continued use of the family
with its existing origin location. There are a few exceptions
(e.g. Some Structural Beam families will not join properly if
the original origin location (from the default Revit template)
has been moved).
If it does not then this needs to be repaired in the family for
the components to work properly. This will however cause
an inconvenience to all clients who have used this
component in a project file. All beams will need to be moved
back into place.
The content creator must test the origin point usability
thoroughly before issuing the component for external use.
All content that is issued with a different origin point must
be issued with a new family name. This is required to
ensure user confidence when using and reloading ANZRS
compliant content - no exceptions! Content companies will
have to notify users if a family needs to be retracted due to
incorrect origin placement that impedes the usability of a
family.
Families of similar type or form should have matching
origin points to aid swapping in and out of the project
environment.
4.02 Control by Reference Is the parametric behaviour of the Wherever possible, all parametric geometry (i.e. that which
Elements family geometry controlled by is to be manipulated by parameters - namely dimensional
Note:The term 'Reference 'Reference Elements' (planes, parameters) should be controlled by reference geometry
Elements' includes reference lines or points)? (planes, lines or points). (Exceptions are rare, but one
planes, reference lines and example is the radius of a sketch profile's curve, which must
reference Points
Points. be controlled by a dimension label placed within the profile's
sketch).
Use Reference geometry (reference planes are most
commonly used) as a framework to which geometry is
aligned and locked. This simple practice will promote
maximum file stability and improve predictable family
behaviour.
The following Reference geometry analogy serves to explain
the concept of how Reference planes function well.
"Reference planes are the structure of the family - much like
bones within a person. Similarly, the dimensions/labels are
the 'muscles', which are attached to the bones, and make
them move. "(Described by Steve Stafford)
Dimension labels should be associated to the reference
planes, which in turn will control flexing of the geometry.
Refer to C1s Sections 2 & 3 (Reference Planes &
Dimensions respectively) for more information if required.
4.03 Hosted in Project System If the family is hosted within a By emulating variations to the host (as will occur in
Family system family in the project projects), the impact of changes to the host can be easily
environment, what is the impact tested within the family environment. E.g. Door families are
on the family when its host's hosted by walls, so the creation of an extremely thin wall,
physical parameters are altered? 'normal' wall and extremely thick wall should be tested.
(E.g. A door family in wall) Test this both in the family editor and the project
environment.
4.03 Hosted in Project System If the family is hosted within a Hosted families can only be swapped for other families that
Family system family in the project share the same host type.
(continued) environment, what is the impact Non-hosted families are more tolerant of adjacent
on the family when its host's elements, and are therefore more robust and flexible.
physical parameters are altered? E.g. Wall, floor, or ceiling-hosted families try to cut their
(E.g. A door family in wall) hosts, which is not possible where families exist in one file,
and their host elements are in a linked file. Face-based or
workplane hosted families do not rely on a specific host
type, and are therefore flexible, and do function correctly
where host elements are within linked files.

5 SUBCATEGORIES QUESTION ANSWER
5.01 Family Category / template Has the family been created It is paramount that the appropriate family template is used
using the correct family to create a family. Reassigning the family category after
template? If not, has this affected commencement does not necessarily ensure that all
the functionality of the component category-specific functionality will be available.
in any way? Refer to the Revit help menu to see the latest list of
(The family category should be cuttable and non-cuttable families to ensure that the
automatically fit for purpose). appropriate family category is selected.
Has the family been purged of items no longer required?
(See Best Practices list (Form R2) for information
regarding changing a Family category.)
5.02 Assignment of subcategories Has all the geometry and Only add additional subcategories to control specific
linework within the component functionality within the project environment. E.g. Assigning
been assigned to the relevant symbolic lines to the appropriate subcategory to allow it to
subcategories? (including those appear as appropriate (e.g. using Swing_Plan subcategory
within nested families) to show swing as a dashed line).
Ensure all nested components have matching
subcategories set for all geometry and linework.
Ensure that ANZRS subcategories are used wherever
possible and appropriate (see 'List of Compliant
Subcategories (Form C8)' for more information)
Can any subcategories (additional to those provided by
ANZRS) be simplified to improve visibility control (i.e.
through Visibility/Graphic Overrides)?
5.03 Subcategory Naming Do all the subcategories in use Underscores are used as delimiters between
comply with ANZRS either from term/descriptors. Dashes as delimiters dont work as they
the supplied list, or with the may be required by genuine hyphenated words.
naming rules provided? Spaces (single) shall be used to separate words within
single terms/descriptors.
All names should be written in plural form. This does not
mean that everything has to have an 's' on the end (e.g.
Hardware). None should have an apostrophe before an 's'.
Only nominate sub categories that require independent (a)
visibility (on/off) or (b) graphic control in a project.
Avoid usingg subcategories
g g that should
to control something
be controlled within the elements instance Visibility
parameter instead.
Subcategories typically need not be very specific they
should be more general in what they refer to.
Avoid material names in subcategories.
Ensure all spelling is correct
Case format is Title Case capitals for every word.
For more information, refer to 'List of Compliant
Subcategories (Form C8)'
6 PARAMETERS QUESTION ANSWER

6.01 Parameter Naming Is the parameter naming Syntax is CamelCase - applying a capital to every word
convention compliant? within the Parameter's Name, without spaces.
Use the compliance, pre-defined shared parameters (See
ANZRS Approved SP Lists - C5, C6 and C7) for lists for the
relevant discipline, that have been included in this package
where required, to ensure maximum interoperability between
shared and sold content that is compliant to these
guidelines.
6.01 Parameter Naming Is the parameter naming For all other custom parameters, do not use mathematical
(continued) convention compliant? operators or symbols (i.e. plus '+', minus '-', divide '/',
multiply '*', hash '#', carat '^', brackets '() <>')
information.
- Examples include:
'AwningPanelHeight', 'AwningPanelWidth', etc.
Refer to C1s, Section 7.02 - Nesting, in this document for
parameter naming of nested components.
6.02 Manufacturers & authoring Have the manufacturer's details Include Manufacturer name and URL of
companys details (if appropriate) and authoring manufacturer/product website if the family has been
(Available in the ANZRS company's details been designed to reflect a product.
Approved SP List (for each provided? If the component is intended to be generic then add
discipline) under 'Multiple 'Generic' to the Manufacturer parameter.
Categories.' Include the following compliance approved Shared
Parameters in the following format:

(1) CreatedBy_ANZRS
Value: <Company Name>
(2) CreatedByPhoneNo_ANZRS
Value: Authoring company's contact phone number
(where one exists)
(3) CreatedByURL_ANZRS
Value: Authoring company's website (if there is one,
and where it differs from that for the product).
(See ANZRS Approved SP Lists - C5, C6 and C7) for more
information and recommended grouping for these
parameters.
NOTE: These above shared parameters are available in all
three Shared Parameter files provided (irrespective of
discipline) under 'Multiple Categories'. They all have the
same GUIDs.
6.03 Shared Parameters Have the approved shared Under ANZRS, Shared Parameters can be custom-made
parameters been used, if by content creators, with the exception of any approved
required? Shared Parameters that have been included in the ANZRS
Approved SP Lists - C5, C6 and C7.
It is expected that the approved Shared Parameters (with
designated GUIDs) shall be used in all shared and sold
components across AUS/NZ to ensure these parameters
schedule seamlessly together.
Custom parameters must follow the naming conventions
outlined in this entire section of C1s, Section 6 -'Parameter
Naming' in this document.
6.04 Modified Issue (date) Has the parameter Refer to the pre-defined SP List and use
(Available in the ANZRS 'ModifiedIssue_ANZRS' field 'ModifiedIssue_ANZRS' approved shared parameter.
Approved SP List (for each been added? Group this parameter under 'Text'.
discipline) under 'Multiple The purpose of this parameter field is to record the last
Categories.' date of edit/issue of the family in question. It can be useful
to help track errors or to confirm that a family requires
reloading to repair previous issues with the updated family
version. (Using the last saved date of a family 'rfa' file
instead of this field is unreliable and prone to error).
Modified Issue (currency format) Each family requires this parameter and the date value to be
added
dd d as defined
d fi d below.
b l
Add date as a currency value in the following format:
<yyyymmdd.no>, where the 'no' suffix is equal to the
number of times the component has been issued for the
corresponding date.
E.g. 20100918.01
If the component is re-issued on the same day due to a
repair or change then the revision will be 20100918.02 etc.
6.05 Parametric Behaviour Do all the labels that control the It is a requirement that all parametric parameters are
parametric behaviour of the flexible and do not 'break' as the family is flexed or changed.
component flex properly? (Content creators are required to flex and test components
comprehensively before issuing the file. (to company
drafters or public domain.)
6.05 Parametric Behaviour Check all parametric dimensions, materials & visibility
(continued) parameters are functional, efficiently grouped and clearly
named.
NOTE: Families do not have to demonstrate a high-level use
of parametrics to be compliant with this checklist. However,
if the family is not parametric enough for its purpose, it may
be perceived by users as being low in value.
7 NESTING QUESTION ANSWER

7.01 Naming of nested Does the name of the nested Re-save and rename any nested components that were
components component need to change? once shared by other families if the changes made could
affect other hosts sharing the same original nested family.
Some content creators add a prefix of "X_" to all nested
family names to ensure users do not employ nested
components as stand-alone families in the project
environment. This is encouraged but not mandatory for
compliance.
A chair family may be used on its own or as part of a table-
and-chairs family. Therefore it is noted that renaming is not
always necessary.

7.02 Naming of parameters in Do the parameter names that are Ensure that all parameters linked between nested families
nested file linked between any nested and the host family are named clearly and logically. In
component and its host family almost every cases, this means that parameters between
match? the two families must be named identically.
EXAMPLE
'DoorFrameDepth' in the host family will be linked to a
parameter called 'DoorFrameDepth' in the nested family.
The only exception to the above mentioned compliance
requirement is if, and only if, a component is shared and it is
being used as a nested component as well as a stand-alone
family. In such circumstances only the parameters which are
required to be different, based on the context requirements
of the nested vs. stand-alone family, may be different.
EXAMPLE OF APPROVED EXCEPTION

A shelf that is nested may have a shelf parameter defined
as 'Width' whereas that same family in a stand-alone
context may have the need to have the shelf width to be
referred to as 'Length' for a specific reason. The practice of
wavering from the above mentioned principle is not
encouraged. The other option is to name the shared and
stand-alone family to be different and then it is possible to
comply to the requirement listed above.
8 TYPES/ TYPE CATALOG QUESTION ANSWER
8.01 Type Naming Is the family type name If there is only one type, name it 'Type 1'
convention compliant? Include w(width), d(depth), h(height) or t(thickness)
indicators. E.g. 1200w x 600h x 300d
Indicate sizing in millimetre units for family components.
(units are taken to be in millimetres, so the mm suffix is not
required). If, however, metres are to be the unit of
measurement (such as when creating a building mass
family), then the m suffix should be used to clarify the units.
Avoid Manufacturer name or Model names if the family
represents a generic object type.
Avoid abbreviations that are not listed in the Approved
Abbreviations section in Best Practices List (Form R2).
All names and parameter labels must be in English and in

metric units.
information on Type naming. (20.01 & 20.02)
8.02 Single Type Has a single type been created? A family that consists of a single option/type (irrespective
of whether it is parametric or not) must have at least one
type created. (If this is not done then the family type name
will inherit the family name when loaded into the project
environment.)
E.g. As displayed in the type pull-down menu of the project
file:' window with arch:window with arch'. (This is considered
poor practice.)
If there is only one type, name it 'Type 1'
E.g. This option will display in the type pull-down menu of
the project file as:' window with arch: Type 1'.
8.03 Multiple Types How many family types are there If you intend to create a component that has several
within the family and is the family variations (other than just being parametric) it may be worth
still easy to maintain or has it splitting the family into more than one component. This may
become too complex in be the case particularly where variation between types
structure? becomes difficult to achieve within a single family (e.g. for
visibility control settings and/or use of arrays).
The benefit of splitting a family, when appropriate, is that
the component will be easier to edit or repair and it is also
apparent to users that there are several options to choose
from.
E.g. A door that consists of 4 panel types may be worth
splitting into 2, 3 or even 4 families.
Remember to properly balance the complexity and
flexibility of a family against its useability.
information.
See C1s Section 8.04 (Catalog Files)

8.04 Catalog Files Is it appropriate to use a type If the family has more than two types configured then it is
catalog file? certainly worth considering creating a component that uses
a type catalog file. This allows users to selectively load only
the family types that they need.
Ensure that each type within the type catalog file has been
loaded into a project file and rigorously tested.
It is possible to have too many types within a family,
making it difficult to use or to edit. If the use of a type
catalog file will not alleviate this, consider splitting the file
into multiple families.
When creating a catalog file ensure the first type in the
actual family (not the catalog txt fie) is called 'THIS IS A
CATALOG FAMILY'. This ensures the family is not altered
and types added simply due to a person missing the catalog
txt file.
Refer to other Discipline Specific requirements to ensure that your components are created with the end users' needs in mind.
NOTES
It is our vision that these proposed standards will receive the promised support from the dominant commercial content creation companies in
Australia, New Zealand as well as the Revit user community.
throughout Australia and New Zealand. A content creator can only claim to provide ANZRS-compliant content if the compliance requirements
listed in this document are met on the respective components that they sell.

REVIT FAMILY CREATION PACK - ARCHITECTURE/INTERIORCOMPLIANCECHECKLIST C2
considerationsthatmustbeundertakenwhen
creatingcontentthatisANZRScompliant.
Thischecklistis disciplinespecific.
ADD IMAGEHERE
FAMILY NAME AUTHOR
NOTE:OnlycompliancespecificrequirementsfromtheassociatedDisciplineSpecificSummaryListarelistedinthischecklist
below.Asaresultthenumbersinthischecklistarenotalwaysinsequence.
ARCHITECTURAL / INTERIOR SPECIFIC REQUIREMENTS Version 3 [01-2012]

1 DESIGN & SETUP Y N
1.01 Nested families
1.02 Symbolic Lines
1.03 Origin
1.04 Description Information
2 MATERIALS Y N
2.01 Material Settings - Identity Data
2.02 Material Class
3 TEMPLATE FILES Y N
3.01 Curtain Panel - Windows
3.02 Curtain Panel - Doors
3.03 Furniture Templates
3.04 Nested families - Furniture Systems
3.05 Template
4 PROFILES Y N
4.01 Profile Templates
4.02 Profile Usage
4.03 Profile Settings
5 CONCEPTUAL MASS Y N
5.01 Metric Mass Template
6 OMITTED FROM CHECKLIST TIPS, TRICKS AND GOTCHAS: NOT REQUIRED FOR COMPLIANCE
SIGNATURE
APPROVED ISSUED
ANZRS_C2_ARCHITECTURE / INTERIOR CHECKLIST, VERSION 3 RESERVED HTTP://WWW.ANZRS.ORG PG 1/2

NOTES

Refer to C2s SUMMARY OF ARCHITECTURAL / INTERIOR REQUIREMENTS for definitions of the minimum compliance
requirements
q listed above.
ANZRS_C2_ARCHITECTURE / INTERIOR CHECKLIST, VERSION 3 RESERVED HTTP://WWW.ANZRS.ORG PG 2/2

REVIT FAMILY CREATION PACK - SUMMARYOFARCHITECTURAL / INTERIOR REQUIREMENTS C2s
Thislistdefinesallrequirementsandconsiderationsthatmustbeundertakenwhen
creatingcontentthatiseither(a)usedforonespecificdisciplineonly,or(b)beingcreated
toservemorethanonediscipline.ArchitecturalandInteriorsspecific
requirementsarediscussedbelow.
COMPLIANCE REQUIREMENTS - ARCHITECTURE/ INTERIOR SPECIFIC Version 3 [01-2012]
A/I DESIGN AND SETUP DESCRIPTION COMMENTS

1.01 Nested families Requirement: Nest 2D annotation symbols Impact: Ensures annotation symbols remain
into the various physical fitting families. same size regardless of drawing scale.
1.02 Symbolic Lines Requirement: Add symbolic lines to Impact: Lock the symbolic lines to the form to
represent component in view to minimise 3D ensure flex with parametric component.
regeneration in project. Example of Process: Set visibility for 3D form to
be hidden in selected view and use symbolic
lines to define or add detail instead of using the
3D form.
1.03 Origin Requirement: Ensure that the origin's Having the origin of a table in the centre, placing
position is determined carefully and it within your project then changing that location
appropriate for the family's placement within to an edge - will effect where and how that table
the project and its parametric adjustment has been placed through out your project. This
from its origin. can ultimately effect setout.
Impact: Subsequent alteration of the origin's
position will affect the location/alignment of
those families already placed within a project.
1.04 Description Information Requirement: Provide all known and Impact: Allows for better scheduling of
appropriate descriptive information about the elements.
object.
A/I MATERIALS DESCRIPTION COMMENTS

2.01 Material Settings - Requirement: Where materials are assigned For example, Description , Keywords ,
Identity Data within the family, assign values to Material Manufacturer , Keynote or Mark values.
Identity (found in the material dialog box) Impact: Especially for applications where large
parameters wherever possible. numbers of materials are used (e.g. Interiors),
these additional values enable better
identification, location and scheduling of
materials.
2.02 Material Class Requirement: Assign values for the Filter Impact: This yields better navigation of
Criteria: Material Class parameter of each extensive material lists. The naming of the
material (found in the Identity Tab of the Material Class parameter value should be
material dialog box). defined and consistently applied throughout all
materials used. This will also ensure materials
are referenced correctly by application.
A/I TEMPLATE FILES DESCRIPTION COMMENTS

3.01 Curtain Panel - Windows Requirement: Use the current release Impact: This enables windows to be hosted
Metric Window - Curtain Wall family within curtain walls, yet scheduled as windows.
template, the category of which is set to When creating families using this template,
'Window'. follow basic principles for window family
This is available in out-of-the-box Autodesk creation.
family template set.
3.02 Curtain Panel - Doors Requirement: Use Metric Door - Curtain Impact: This enables doors to be hosted within
Wall family template, the category of which is curtain walls, yet scheduled as doors. When
set to 'Door'. creating families using this template, follow
This is available in out-of-the-box Autodesk basic principles for door family creation.
family template set.
ANZRS_C2s_ARCHITECTURE / INTERIOR REQUIREMENTS, VERSION 3 RESERVED HTTP://WWW.ANZRS.ORG PG 1/3

A/I TEMPLATE FILES DESCRIPTION COMMENTS
3.03 Furniture Templates Requirement: Where individual elements For a fixed 'pod' arrangement for workstations,
are required use Furniture family template. use a Furniture Systems template in preference
If complex nesting or seating arrays are to placing one workstation and then array/copy
required the Furniture Systems family or create a group containing multiple elements.
template is to be used. Impact: Distinction between the categories
based on this methodology simplifies control of
visibility of simple vs. complex families. The use
of nesting of families usually provides for better
performance than does the creation and use of
model groups.
3.04 Nested families - Requirement: Ensure all families within a When creating a complete workstation,
Furniture System Family Furniture System family have their 'shared' containing desk, chair & computer - all items
family category setting checked. should be shared so all items can be tagged and
scheduled.
Impact: This ensures all components will be
able to be tagged and scheduled individually,
despite being part of a single family.
3.05 Template Requirement: Choose the appropriate family Impact: Selecting the wrong family
template/category from the start of the template/category will impact visibility and
creation process. The distinction between behaviour within a view or project model.
cuttable and non-cuttable categories is Refer to Best Practices List, 'Section 6.01
critical, while other behavioural and Family Category' for impacts involved in
informational differences exist between other changing categories of a family.
categories.
A/I PROFILES DESCRIPTION COMMENTS

4.01 Profile Templates Requirement: For the five primary uses of a Impact: For other profile uses (Fascia, Gutter,
profile (Hosted, Mullion, Rail, Reveal, Stair Slab Edge, Slab Metal Deck, Wall Foundation
Nosing) a specific family template is already and Wall Sweep), use the generic Metric Profile
provided with the software. family template.
4.02 Profile Usage Requirement: Set the Profile Usage family Impact: The profile can be assigned to a
parameter for designated use
use. specific use - this restricts the use of the profile
to its intended use. If in doubt, set the Profile
Usage value to <Generic>.
4.03 Profile Settings Requirement: Ensure that the Rotate with Impact: Without doing this, the profile's rotation
component family parameter is enabled if the will be relative to the project or view, rather than
profile is meant to have a direct relationship its host object (where applicable).
with a project element.
A/I CONCEPTUAL MASS DESCRIPTION COMMENTS

5.01 Metric Mass Template Requirement: It is an option to use the Impact: Once loaded into the project, the mass
Metric Mass family template to create a can form the basis for the project's form.
parametric mass form for use during Elements can be hosted and driven by the
conceptual design. mass, and rebuilt if and when the mass form is
changed.
There are definitely ramifications to using a
model that has been produced by converting
massing surfaces to solid forms. Research and
test if appropriate for your specific project use.
TIPS & TRICKS & GOTCHAS - ARCHITECTURE/ INTERIOR SPECIFIC NOT REQUIRED FOR COMPLIANCE
A/I GENERAL DESCRIPTION COMMENTS

6.01 Lighting Fixtures Use Linear Lighting family template for all Impact: The light source will then stretch and
'strip-' or 'tube-' type lighting. All custom non- react in accordance with the lighting tube and its
linear families should be created using parameters.
standard Lighting Fixture family templates.
A/I GENERAL DESCRIPTION COMMENTS

6.02 Plumbing, Lighting and When using MEP family templates add the As of RME 2011, MEP fixtures can be
Mech Components appropriate connectors within the family as copy/monitored - allowing substitution of source
per intended use and discipline requirements. fixtures for others that already contain
connectors as appropriate.
Impact: This will enhance collaboration with
services and connection to their systems within
their respective projects.

6.03 Materials (Template) A purpose-built project file (known as a Impact: While assignment of materials is often
selection file) containing all materials and applied <By Category>, assigning specific
associated data is a practical method of materials within the family to solid forms
managing and transferring material data from requires that the material first exists within the
projects to families. Copying a swatch from family. To that end, the use of a materials
the selection file of that material into your template file can keep materials and their
family adds only that material. This is properties more consistent, and reduce
particularly useful where there are large repetitive and duplicitous work. Using 'Transfer
numbers of materials that must be Project Standards' from materials template
maintained - such as in Interior Design. (project) file to family may require unnecessary
materials to be deleted from the project file in
advance, or the family afterwards.
A/I GEOMETRY DESCRIPTION COMMENTS

7.01 Sweeps Sweeps are a good design tool as they make For example, a circular profile could be used for
use of a profile that can be sourced from an both a handrail and a downpipe.
external profile family. Impact: You can create a special profile once
and re-use it in multiple families.
A/I COLUMNS DESCRIPTION COMMENTS

8.01 General All columns required to perform structurally Architectural columns have a Room Bounding
should be created using Metric Structural instance parameter which is enabled by default.
Column family template. Structural columns do not include this parameter
and therefore cannot be 'room bounding'.
Impact: Columns created using the Metric
Column family template are Architectural by
definition, and are strictly non-structural
elements, functioning as decorative elements.
A/I PARKING DESCRIPTION COMMENTS

9.01 Parking Component Disable the Always Vertical family parameter Simply setting 'Work Plane-Based' will not adjust
for parking bay families. the angle of the component.
Note that in plan representation, the dimensions
of the parking bay may not read as you expect.
Despite this, the dimensions are (more) correctly
applied relative to the (sloped) host surface.
Impact: This will allow the family to be oriented
according to the slope of its host at the family's
origin. Without this, the bays remain facing up,
irrespective of the surface they are applied to.
NOTES
REQUEST FOR INDUSTRY ASSISTANCE: We need more Industry feedback to improve this list and to better explain issues to be considered
when creating discipline sympathetic content. Please provide clear examples and explanation of issues through the feedback form on the
ANZRS website.

REVIT FAMILY CREATION PACK - STRUCTURALCOMPLIANCECHECKLIST C3
ADD IMAGEHERE
FAMILY NAME AUTHOR
NOTE:OnlycompliancespecificrequirementsfromtheassociatedDisciplineSpecificSummaryListarelistedinthischecklist
below.Asaresultthenumbersinthischecklistarenotalwaysinsequence.
STRUCTURAL SPECIFIC REQUIREMENTS Version 3 [01-2012]

1 CATEGORY Y N
1.01 Family Category
2 MATERIALS Y N
2.01 Structural Material Settings
3 GEOMETRY Y N
3.01 Sweeps vs. Extrusions
3.02 Multiple sweeps required
3.03 Profile alignment
3 04
3.04 Sweep Path
3.05 Family Category
3.06 Length Parameter
3.07 Sweep Visibility
4 ANALYTICAL MODEL Y N
4.01 Reference Level alignment
5 FRAMING Y N
5.01 Origin
5.02 Auto-joining
5.03 Reference Planes
5.04 Template
6 COLUMNS Y N
6.01 Symbolic Linework
7 FOUNDATIONS Y N
7.01 Structural Material
8 STICK SYMBOLS Y N
8.01 Reference Planes
8.02 OMITTED FROM CHECKLIST NOT REQUIRED FOR COMPLIANCE
ANZRS_C3_STRUCTURAL CHECKLIST, VERSION 3 RESERVED

COPYRIGHT HTTP://WWW.ANZRS.ORG PG 1/2
SIGNATURE
APPROVED ISSUED
NOTES

Refer to C3s SUMMARY OF STRUCTURAL REQUIREMENTS for definitions of the minimum compliance requirements listed above.
ANZRS_C3_STRUCTURAL CHECKLIST, VERSION 3 RESERVED

COPYRIGHT HTTP://WWW.ANZRS.ORG PG 2/2
REVIT FAMILY CREATION PACK - SUMMARYOFSTRUCTURAL REQUIREMENTS C3s
creatingcontentthatiseither(a)usedforonespecificdisciplineonly,or(b)being
createdtoservemorethanonediscipline.Structuralspecificrequirementsarediscussed
below.
GENERAL COMPLIANCE REQUIREMENTS - STRUCTURAL Version 3 [01-2012]
S CATEGORY DESCRIPTION COMMENTS

1.01 Family Category Requirement: Select the appropriate family Impact: Families started with incorrect template
template and category at the outset. Do not may not behave as expected, and be missing
change the family category between key items, despite the category being reset after
Structural categories. it has been started.
S MATERIALS DESCRIPTION COMMENTS

2.01 Structural Material Requirement: Set the Structural Material The Structural Material Type family parameter
Settings Type (via the Family Category and controls the structural performance of the
Parameters dialog). The material is family. Options are Steel, Concrete, Precast
dependent on the family being created. Concrete, Wood or Other.
Impact: If wanting to host reinforcement, set
the Structural Material Type parameter to
Concrete.
S GEOMETRY DESCRIPTION COMMENTS

3.01 Sweeps vs. Extrusions Requirement: It is preferential to use Impact: This will ensure a cleaner join with the
sweeps and not extrusions for framing slabs.
definitions.
3.02 Multiple sweeps required Requirement: For steel columns and Impact: Appropriate levels of geometric
framing members, two sweeps are required - precision are visible when required.
one for display at medium detail level which
has a simplified profile; the other for display
at fine detail with the exact profile.
3.03 Profile alignment Requirement: Host sweep path to Impact: This will ensure that beam is centred
appropriate reference plane (typically along the beam path and mirrors correctly within
Center(Front/Back) for beams). the project environment.
3.04 Sweep Path Requirement: Endpoints of sweep path must Impact: This will ensure that the ends of
be aligned and locked to Member Left and framing elements join properly when
Member Right reference planes, unless intersecting.
creating framing cutbacks.
3.05 Family Category Requirement: For concrete elements, keep Impact: This will ensure that framing elements
Family Category set to Structural Framing , join properly when intersecting with similar
but change Structural Material Type elements and with floors.
parameter to 'Concrete' from the pre-defined
list.
3.06 Length Parameter Requirement: Keep pre-defined Length Impact: This will ensure that framing elements
parameter and do not alter what the extend, shorten and join correctly.
dimension is referencing - i.e. Left and Right
reference planes.
3.07 Sweep Visibility Requirement: For concrete beams, set the This is to ensure the pockets are made in walls
visibility of the sweep form to be visible at all and other elements the sweeps are cutting
levels of detail (coarse/medium/fine). through. A suggestion would be to leave the
beam representation and use a void that is
visible in coarse detail level. This will then
ensure sufficient space is left for those
elements.
Impact: Beams will be visible in all detail levels
and no stick representation will be used.
ANZRS_C3s_SUMMARY OF STRUCTURAL REQUIREMENTS, VERSION 3 RESERVED HTTP://WWW.ANZRS.ORG PG 1/4

S ANALYTICAL MODEL DESCRIPTION COMMENTS
4.01 Reference Level Requirement: Model Structural framing and The alignment of the analytical model that is
alignment column families around the family origin. used to export to structural analysis packages is
determined by the reference plane that is
aligned with the Reference Level.
Impact: Analytical model may be incorrectly
placed on complex geometry.
S FRAMING DESCRIPTION COMMENTS

5.01 Origin Requirement: Framing elements need to be Impact: This is to ensure the analytical model
modelled with the origin in the centroid of the behaves as expected, and is calculated
family. correctly.
5.02 Auto-joining Requirement: Framing families have two These may be removed for insitu concrete
special built-in reference planes that control beams.
the auto-joining. They are identified by the Impact: Be sure not to delete these planes if
fact that they have no Is Reference value. you want your beam to auto-join to other
They are named Member Left and Member beams.
Right .
5.03 Reference Planes Requirement: Additional reference planes The out-of-the-box-steel framing families
must be added to the framing member to automatically cut the physical model back at a
permit greater control over cutbacks at its column junction, leaving the analytical model to
ends. project through from the beam to the centre of
the supporting column. Essential for correct
usage of the analytical model.
Impact: Greater control over end cutbacks is
possible, unlike when using the out-of-the-box
Metric Structural Framing - Beams and Braces
template.
5.04 Template Requirement: Ensure you use the correct The Complex Truss family template cannot host
family template for the behaviour required. reinforcement, and does not allow auto-joining.
Only the Metric Structural Framing - Beams and
Braces family template permits auto-joining and
hosting of rebar for structural framing.
Impact: Changing the family category between
one structural component and another may
yield unexpected or undesired results.
S COLUMNS DESCRIPTION COMMENTS

6.01 Symbolic Linework Requirement: No need for symbolic linework Symbolic linework is required for hollow section
to be added for solid geometry. Ensure that families to represent hidden faces.
the Symbolic Representation parameter is Impact: Joining of insitu concrete elements is
set to From Project and not From Family . dependent on all elements having the same
material.
S FOUNDATIONS DESCRIPTION COMMENTS

7.01 Structural Material Requirement: Set the family's Structural Impact: Rebar can only be added to families
Material Type parameter to Concrete so where the Structural Material Type is set to
reinforcement can be added. Concrete.
S STICK SYMBOLS DESCRIPTION COMMENTS

8.01 Reference Planes Requirement: Stick Symbols are, by default, Impact: Stick symbols can be deleted for
constrained to Stick Left and Stick Right concrete beams, but dont delete the default
reference planes. reference planes called Stick Left and Stick
Right.
8.02 Template Files Requirement: Stick Symbols are, by default, Impact: Dont change subcategory of stick
already in the family template file and are symbols as this is set up as a default in
used to display the member as a line template files.
representation specifically for coarse detail
display. This display convention applies only
to steel and wood (timber) members. Ensure
the line representation remains on the Stick
Symbol subcategory (as per default
template).

TIPS & TRICKS & GOTCHAS - STRUCTURAL NOT REQUIRED FOR COMPLIANCE
S FRAMING DESCRIPTION COMMENTS

9.01 Joining Framing Sometimes copy & paste (aligned to same Ensure you remove the duplicate elements
Elements place) resolves joining issues between created by copying & pasting.
framing elements. Ensure any supporting Impact: Structural members will not join
floors are assigned as Structural in their properly if their Structural Material is different.
Element Properties. Ensure that the sweep
path is aligned to the appropriate reference
planes. Ensure Structural Material Type
parameter of the framing member has been
(correctly) assigned.
9.02 Trimming Use extend and trim to adjust extents of Impact: As beams and trusses have different
structural beams, trusses and the like dont points of justification they will stretch differently.
push or pull the drag handles (at the end Extending a shape handle can result in over
extents) in project environment to extend or sizing the element completely.
shorten members.
9.03 Joining Framing- Slab Framing elements on the same surface as Impact: If solid geometry is createdusing an
slab will join better if the geometry has been extrusion form (instead of a sweep) the
created as a sweep. structural elements tend to join leaving some
linework visible. The additional linework makes
it look like elements are separate and not
joined.
9.04 Profile Alignment Alignment to, or by geometry (when viewing E.g. Placing reference planes that are aligned
the profile in section) can be difficult if the with each quadrant of a circular profile, placed
profile contains only curved edges (e.g. In a away from the Center(Left/Right) and
CHS profile), as there are no straight edges Center(Top/Bottom) or Center(Front/Back)
to reference. reference planes by a distance equal to the
radius of the circular profile.
Impact: Augmenting such families with
additional and appropriate reference planes can
overcome this.
S ANALYTICAL MODEL DESCRIPTION COMMENTS

10.01 Justification The behaviour of the physical geometry and Example: a structural column should have its
the analytical geometry can vary, often with lower physical extents aligned and locked to the
unintended and undesired consequences. Bottom reference plane, which should be locked
Fixing the extents of the physical geometry to the Lower Reference Level, while the top of
(aligning and locking extrusion start and end the column extrusion should be locked to the
faces, for example) to 'Top', 'Centre' and/or Upper Reference Plane (since there is no Top
'Bottom' reference plane (depending on what reference plane in this case). Offsets from top
exists per element function column, beam, and bottom extents of the column (within the
bracing etc.) causes that plane to control the project environment) should apply to both the
analytical geometrys extents. physical and analytical extents of the object.
The needs of each structural component vary Without this, the physical geometry of the
(column from beam, beam from bracing etc.), column may be moved independently of the
so it is important to ensure your geometry analytical geometry, leaving the models
suits the familys intended use. integrity compromised.
NOTE: Similarly, in a Beam family, the Center
This criteria improves the Revit model's (Elevation) reference plane must remain locked
integrity and it's ability to calculate loads to the Reference Level. Otherwise, the
efficiently in third party applications analytical geometry and the physical model may
be moved independently with undesirable
consequences.
NOTE:
The analytical model cannot be viewed by Revit
Architecture or Revit MEP.

Refer to other Discipline Specific requirements to ensure your components are created with the end users' needs in mind.
NOTES
ANZRS website.

REVIT FAMILY CREATION PACK - MEPCOMPLIANCECHECKLIST C4
ADD IMAGEHERE
FAMILY NAME AUTHOR
NOTE:OnlycompliancespecificrequirementsfromtheassociatedDisciplineSpecificSummaryListarelistedinthis
checklistbelow.Asaresultthenumbersinthischecklistarenotalwaysinsequence.
ALL MEP DISCIPLINES Version 3 [01-2012]

1 ANNOTATION FAMILIES Y N
1.01 Nesting of Annotation Symbols vs.
Detail Components
1.02 Keep Text Readable
MECHANICAL FAMILIES ONLY

4 CONNECTORS Y N
4.01 Mechanical Connectors
4.02 Flow Direction
4.03 Flow Configuration
4.04 Connector Description
5 DUCT ACCESSORIES Y N
5.01 Part Types
5.02 Family Templates
6 DUCTS Y N
6.01 Correct Manufacturer Sizes
ELECTRICAL FAMILIES ONLY

7 PHOTOMETRICS Y N
7.01 Manufacturer Settings
8 GENERAL INFORMATION Y N
8.01 Electrical Connectors (Load
Classification)
8.02 Electrical Connectors (Voltage)
8.03 System Types
8.04 Part Types
PLUMBING FAMILIES ONLY

10 PIPE ACCESSORIES Y N
10.01 Part Types
10.02 Family Templates
ANZRS_C4_MEP CHECKLIST,VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG 1/2

11 PIPE CONNECTORS Y N
11.01 Defining System Types
11.02 Connector Description
11.03 Flow Direction
11.04 Default Parameter Values
12 PIPE FITTINGS Y N
12.01 First Connector Location
12.02 Bend Location
12.03 Lookup Tables
12.04 System Types
12.05 Manufacturer Data
13 PIPES Y N
13.01 Correct manufacturer sizes
SIGNATURE
APPROVED ISSUED
NOTES

Refer to C4s SUMMARY OF MEP REQUIREMENTS for definitions of the minimum compliance requirements listed above.
ANZRS_C4_MEP CHECKLIST,VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG 2/2

REVIT FAMILY CREATION PACK - SUMMARYOFMEP REQUIREMENTS C4s
creatingcontentthatiseither(a)usedforonespecificdisciplineonly,or(b)beingcreated
toservemorethanonediscipline.Mechanical,Electrical&Plumbingspecific
requirementsarediscussedbelow.
GENERAL COMPLIANCE REQUIREMENTS - MEP Version 3 [01-2012]
MEP ANNOTATION FAMILIES DESCRIPTION COMMENTS

1.01 Nesting of Annotation Requirement: Where filled regions are Impact: Using a nested Generic Annotation
Symbols vs Detail required for symbolic representation: family will ensure that a 2D symbol remains the
Components Use a nested Generic Annotation family for same size on sheet regardless of view scale.
symbolic display of the family where display These annotation families can then be re-used
size is set relative to printed output (e.g. a in other families. (e.g. other single-point light
GPO or light switch), or; fixtures).
Use a nested Detail Component where the Nested geometry is often required because filled
family's size is relative to the model (e.g. a regions, which are useful for symbolic display
1200mm long linear light fixture) are not available within 3D families.
If filled regions are not required, and the
symbolic display of a family should be
determined relative to the model, symbolic
linework may be sufficient without the use of
nested families at all.
1.02 Keep Text Readable Requirement: When creating 2D symbols, Impact: If annotation is rotated beyond 90
ensure the Keep Text Readable option and/or degrees, it will remain oriented upright.
the Maintain Orientation option is selected -
found in Family Category and Parameters.
ALL MEP DISCIPLINES - TIPS & TRICKS & GOTCHAS NOT REQUIRED FOR COMPLIANCE
MEP GOTCHAS DESCRIPTION COMMENTS

2 01
2.01 Family
F il Category
C t Select
S l t the
th appropriate
i t family
f il template
t l t and
d I
Impact:t Families
F ili started
t t d with
ith incorrect
i t template
t l t
category at the outset. Do not change the may not behave as expected, and be missing
family category between MEP-related key items, despite the category being reset after
categories. it has been started.
2.02 Masking Regions Do not use masking regions inside any Prevents pipes under toilets, sinks, etc. being
3D/2D families that are to be used for MEP seen in documentation.
documentation. Impact: Masking regions will obscure
components beneath the masking region, such
as pipes and isolating valves - even when the
component is set to Transparent.
MEP TIPS & TRICKS DESCRIPTION COMMENTS

3.01 Servicing Access Some items require clear space around them A single subcategory should be used
for operation or maintenance. Modelling this consistently for each family category. ANZRS
space as a volumetric form and assigning it has provided this as Clearance Zones (refer
to a special subcategory will allow it to be Form C8: Subcategories). The use of a
hidden independently of the component's (transparent) material consistently across each
physical geometry, but revealed when instance of this subcategory will assist the end
required. users to recognize the access zones visually.
Impact: Allows for greater understanding of the
component's use and operational needs, and
can also be used for clash detection.
3.02 Connector Descriptions Requirement: The Connector Description Connectors are more useable for the Connect
parameter should be assigned in Identity Into function when they include descriptions.
Data. Impact: Distinction is required between
connectors in order to avoid confusion when
connecting into the component. Revit assigns
numbers to the connectors and reports the Type
and Size. The description increases information
available for reporting of systems.
ANZRS_C4s_SUMMARY OF MEP REQUIREMENTS, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG 1/5

MEP TIPS & TRICKS DESCRIPTION COMMENTS
3.03 Special Work Planes Lighting and Air Terminal default template Spaces can show 0 Lx for lighting levels in areas
families have special work planes that are that have light fittings. In this case check the
used for reporting data back to Spaces. special work plane location in the family.
Impact: If the special workplanes (normally
Elevation(Front/Back)) are not in the correct
location, the family will not report information
back to the Space.
3.04 Reference Planes Correct use of reference plane naming and Impact: Quicker and more logical placement of
Is Reference parameter will allow families to families within the model.
be placed in relation to nearby objects and
host elements.
3.05 Lookup Tables for Lookup tables are used to set dimensional Impact: Determines the dimensional properties
piping properties of pipe fittings and conduits. of pipe fittings and conduit fittings.
These tables should be checked against
manufacturers' catalogues to ensure validity
and availability.
3.06 Connector Hosting Connectors can be hosted by faces or Impact: Hosting Connector to a separate object
workplanes. When a face is selected as the enables the connector to be repositioned using
host, they are located in centre of that face. dimension parameters
For greater control over default positioning of
the connector, ensure the face is modelled
as a separate (though joined) form.
When hosting a connector to a workplane,
the connection direction is defined by the
direction the workplane was drawn in. If you
need to flip this, drag the extends of the
workplane over itself to reverse it.
3.07 Connector parameters Connectors should have the main values Unless values are linked to parameters then
linked to a parameter (i.e.: flow, voltage etc.) families will use the default values and will not
g
be changeable j
within a project.
Impact: Allows manipulation of data to
connectors from within a project.
3.08 Identity Data Assign appropriate Omniclass Number Useful for packages outside of the Revit
parameter value, which should determine its platform, such as Exactal CostX and Autodesk
Omniclass Title value. Navisworks.
Impact: This will allow a greater degree of
referencing of families, especially in a
collaborative environment. (such as when using
search sets in Autodesk Navisworks).
MECHANICAL ONLY - COMPLIANCE REQUIREMENTS
M CONNECTORS DESCRIPTION COMMENTS

4.01 Mechanical Connectors Requirement: Specify System Type CONNECTOR: System Type Parameter =
parameter within connectors. Supply Air
PROJECT: Create filter to highlight graphically
the Supply Air system.
Impact: This is critical to create true systems
and analyse the associated/connected elements
or components.
4.02 Flow Direction Requirement: Specify Flow Direction and Direction: In, Out or Bidirectional.
place the connector correctly. The connector arrow ALWAYS points AWAY
from the fitting (in the direction of the connecting
elements) - regardless of the actual flow
direction of the fluid.
or components.
M CONNECTORS DESCRIPTION COMMENTS

4.03 Flow Configuration Requirement: Specify the family's Flow Impact: This is important where a specific Flow
Configuration . Factor is to be assigned to the connector.

4.04 Connector Description Requirement: The Connector Description Connectors are more useable for the 'connect
parameter should be assigned in Identity into' function when they have descriptions
Data added.
Impact: Distinction is required between
connectors in order to avoid confusion when
connecting into the component. Revit assigns
numbers to the connectors and reports the Type
and Size. The description increases information
available for reporting of systems.
M DUCT ACCESSORIES DESCRIPTION COMMENTS
5.01 Part Types Requirement: Duct Accessories and Duct Part Types for Duct Accessories: Attaches To,
Fittings families must have their Part Type Break Into, Damper
family parameter assigned as appropriate. Part Types for Duct Fittings: Elbow, Tee,
Transition, Cross etc.
Impact: The Part Type parameter determines
how and what the family can connect to. Without
this being correctly assigned, the family will not
be able to connect to other components as may
be desired.
5.02 Family Templates Requirement: For any mechanical Impact: For those mechanical components
components that do not have a created this way, ensure the OmniClass Number
corresponding family template, the Generic parameter is assigned correctly.
Model family template should be used, and
the category subsequently assigned more
specifically.
M DUCTS DESCRIPTION COMMENTS
6.01 Correct manufacturer Requirement: Use correct manufacturer For example, inside and outside diameter
sizes sizes in projects. measurements for ducts.
Impact: Using real world components can lead
to a more accurate coordination with other
services in the project model.
ELECTRICAL ONLY - COMPLIANCE REQUIREMENTS
E PHOTOMETRICS DESCRIPTION COMMENTS

7.01 Manufacturer Settings Requirement: Lighting families have a few Impact: The correct IES photometric data will
extra parameters (grouped under enable accurate lighting calculation, but does
Photometrics ) that require checking against not affect other aspects of the lighting fixture
manufacturer settings (over and above the family.
use of their IES file).
GENERAL
E DESCRIPTION COMMENTS
INFORMATION
8.01 Electrical Connectors Requirement: Specify the electrical Load classification types include HVAC,
(Load Classification) connector's Load Classification parameter Lighting, Motor, Other and Power.
value. Note: where the electrical connector's Load
Classification value is set as 'Power', the
Demand factor's calculation method settings
may not suit regional regulatory standards. In
such cases, this item is exempt from ANZRS
compliance until feature changes in the software
resolve this.
Impact: Allows for calculation of maximum
demands for each Load Classification within the
project. Also incorporates Demand Factors
applied to Load Classifications.
GENERAL
E DESCRIPTION COMMENTS
INFORMATION
8.02 Electrical Connectors Requirement: Voltage parameter value of the Electrical GPOs in Australia should have a
(Voltage) connector should be 'mapped' to a type Voltage parameter set to 230V, which the
parameter of the host family, to allow the connector's Voltage parameter is 'mapped' to.
value to be seen, used and edited from the Impact: Electrical circuit connections are
project. dependent on the voltage and distribution
settings.

8.03 System Types Requirement: System types are Impact: Ensure all systems are defined
automatically specified from the connectors correctly in the connectors of the families, or
that the pipes or ducts are connected into. else systems will be poorly defined.
Note: Cable trays and conduits do not have a
System Type parameter. They can make use of
the parameter Service Type applied instead
within the project environment.
8.04 Part Types Requirement: Various categories of families Applies to various family categories, including,
must have their 'Part Type' family parameter but not limited to: Electrical Fixtures, Electrical
assigned as appropriate. Equipment, Cable Tray Fittings, Telephone
Devices, Data Devices
be desired.
ELECTRICAL ONLY - TIPS & TRICKS & GOTCHAS NOT REQUIRED FOR COMPLIANCE
E GENERAL DESCRIPTION COMMENTS

9.01 Electrical Engineering You wish to maintain annotation orientation. If you want a light to have a symbolic annotation
for plan graphics, and have that symbolic
annotation not rotate as you rotate or orient the
3D component.
Impact: Ensuring that the Maintain Annotation
Orientation parameter is checked will keep
annotations oriented upright regardless of
component or host element orientation.
9.02 Lighting Families Ensure Light Source is switched on in Impact: Light sources only exist within Lighting
Lighting Fixture family parameters. The Light Fixture families. Lighting Devices cannot
source location/element should not be produce light. If a light source is required, either
encased within solid geometry, as the light create using a Lighting Fixture family template,
they produce will not be visible when or nest a Light Fixture component (without
rendered. g
geometry)y) within a Lighting
g g Device family.
y
9.03 Family Templates For any electrical components that do not Impact: For components created this way,
have a corresponding family template, the ensure the OmniClass Number parameter is
Generic Model family template should be assigned correctly.
used, and the category subsequently
assigned more specifically.
PLUMBING ONLY - COMPLIANCE REQUIREMENTS
P PIPE ACCESSORIES DESCRIPTION COMMENTS

10.01 Part Types Requirement: Pipe Accessories and Pipe Part Types for Pipe Accessories: Normal,
Fittings families must have their Part Type Attaches To, Breaks Into etc.
family parameter assigned as appropriate. Part Types for Pipe Fittings: Elbow, Tee,
Transition, Cross etc.
be desired.
10.02 Family Templates Requirement: For any plumbing components Impact: For components created this way,
that do not have a corresponding family ensure the OmniClass Number parameter is
template, the Generic Model family template assigned correctly.
should be used, and the category
subsequently assigned more specifically.
P PIPE CONNECTORS DESCRIPTION COMMENTS

11.01 Defining System Types Requirement: Define System Type in pipe Pipe Connector's System Types: Domestic Hot
connectors families. If the default options are water, Hydronic Supply, Fire Protection Wet,
not appropriate, select Other, and provide a other, etc.
System Type name manually. Impact: If this is not done it will result in items
not being associated to the correct systems.

11.02 Connector Description Requirement: Ensure that the Connector Connectors are more useable for the Connect
Description parameter is populated for all Into function when they include descriptions.
pipe connectors. Impact: Creates a better-defined element and
model. Better information is then available for
reporting.
11.03 Flow Direction Requirement: Specify Flow Direction and Direction: In, Out or Bidirectional.
place the connector correctly. The connector arrow ALWAYS points AWAY
from the fitting (in the direction of the connecting
elements) - regardless of the actual flow
direction of the fluid.
or components.
11.04 Default Parameter Requirement: Assign correct or at least Impact: This will result in more accurate
Values reasonable default values to parameters in calculations in the project.
the family.
P PIPE FITTINGS DESCRIPTION COMMENTS

12.01 First Connector Requirement: The primary connector for a Impact: Pipe fittings will rotate on placement,
Location pipe fitting must be on the Centre(Left/Right) and system layouts will not function correctly if
plane. the primary connector is not in the correct
location.
12.02 Bend Location Requirement: The centre of a bend must Impact: Pipe angles will not be as placed if
always coincide with a family's origin bends are not centred around the family's origin.
location.
12.03 Lookup Tables Requirement: Lookup tables can only exist Impact: Lookup table must be found in the
in one location. It is best practice to locate correct folder location prior to creating a
them in a common library location, and component that uses it.
include this in Revit MEP's list of file
locations (via Application Menu->Options).
12.04 System Types Requirement: Assigning Fitting value for a Impact: Sets the angle between fittings
pipe connector's System Type allows for the connectors
g parameter,
use of an Angle p associated to the
connection.
12.05 Manufacturer Data Requirement: Call up the correct Victaulic Bends, iPlex Bends, Valve types,
manufacturer data in lookup tables for correct Flanged fittings.
sizing of fittings in the project. Impact: Using real world components can lead
to a more accurate coordination with other
services in the project model.
P PIPES DESCRIPTION COMMENTS

13.01 Correct manufacturer Requirement: Use correct manufacturer E.g. Inside and outside diameter measurements
sizes sizes in projects. Note: Using Transfer for pipes.
Project Standards to import pipe sizes yields Impact: Using real world components can lead
inconsistent and unreliable results. It is to a more accurate coordination with other
recommended to configure them in your services in the project model.
project template(s).
Refer to other Discipline Specific requirements to ensure your components are created with the end users' needs in mind.
NOTES
REQUEST FOR INDUSTRY ASSISTANCE: We need more Industry feedback to improve this list and to better explain issues to be
considered when creating discipline sympathetic content. Please provide clear examples and explanation of issues through the feedback form
on the ANZRS website.
listed in this document are met on the respective components that they sell sell.

REVITFAMILYCREATIONPACK ARCHITECTURE/INTERIORSHAREDPARAMETERSPREADSHEET Version 3 [01-2012] C5
Thislistdefinesallrequirementsandconsiderationsthatmustbeundertakenwhencreatingcontentthatiseither(a)usedforonespecific
disciplineonly,or(b)beingcreatedtoservemorethanonediscipline.ArchitecturalandInteriorsspecificrequirementsarediscussedbelow.
Category Parameter Group ANZRS Parameter Name GUID Discipline Type Comments
Baluster
Casework
Casework Materials and Finishes BenchtopFinish_ANZRS 55a091ea-ccd6-453c-8c1c-6c57cdaa5b51 Common Text
Casework Materials and Finishes BenchtopMaterial_ANZRS 67840e22-f79b-46e4-abdf-12985fff3669 Common Material
Casework Dimensions BenchtopThickness_ANZRS 59d03b47-c19e-4f65-839b-984e45094615 Common Length
Casework Materials and Finishes CarcassFinish_ANZRS 222dfaf6-59b4-4674-a3ca-b918349bb59b Common Text
Casework Materials and Finishes CarcassMaterial_ANZRS 570eada9-e328-4027-b78f-aaef29758e8a Common Material
Casework Dimensions CaseworkPanelThickness_ANZRS 9f8679c4-91c3-4508-880d-e2de7d4fc32c Common Length
Casework Materials and Finishes KickerFinish_ANZRS 416d6873-69da-4e8c-91f9-5cf9dab21a20 Common Text
Casework Dimensions KickerHeight_ANZRS
g _ 3de99c19-ae26-4657-bd3e-3dac3bc2e225 Common Length
g
Casework Materials and Finishes KickerMaterial_ANZRS 31c0b1cf-4305-4b5f-be8a-c36ddc6933a2 Common Material
Columns
Curtain Panels
Doors
Doors Materials and Finishes DoorFrameFinish_ANZRS d860ca85-31bc-43c3-a612-fb5fa4e5a75f Common Text

Doors Materials and Finishes DoorFrameMaterial_ANZRS 29ec812c-151d-45cc-89f1-ac2fc0ea2636 Common Material
Doors Identity Data DoorFrameType_ANZRS 72d2fc95-0229-4807-ba58-8837dcd6de10 Common Text
Doors Dimensions DoorGlazingHeight_ANZRS 98a51c4d-b048-48b3-aa68-0273935be0a9 Common Length
Doors Identity Data DoorGlazingType_ANZRS c746eeef-2888-4ac6-9f42-9b19ba58cd93 Common Text
Doors Dimensions DoorGlazingWidth_ANZRS 06a249ce-4d43-4bb3-84c0-3f7c1fac8eea Common Length
Doors Identity Data DoorGrille_ANZRS f1b2f6f4-7180-4a8d-b4d2-24b99aa88e87 Common Yes/No
Doors Dimensions DoorGrilleHeight_ANZRS 5dbc4879-f7ec-4c9b-9e7c-65013eb80bd5 Common Length
Doors Dimensions DoorGrilleWidth_ANZRS f78bd142-2abe-44ed-96c7-adfd6166c861 Common Length
Doors Identity Data DoorOperation_ANZRS b21c4118-4b2c-4e81-8fdd-aafd3d0ebc13 Common Text Hinged, Sliding etc.
Doors Materials and Finishes DoorPanelFinish_ANZRS de4cbf9b-eda3-4501-a686-3370256e0a05 Common Text
Doors Materials and Finishes DoorPanelMaterial_ANZRS 1773b6be-9d64-4208-a5a1-b028dd3279fd Common Material
ANZRS_C5_ARCHITECTURE / INTERIOR SHARED PARAMETER LIST, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG 1/4
Doors continued
Doors Text DoorSignageWording_ANZRS 4ab9d95c-c92e-4c22-9cf1-52f9e5aeba12 Common Text
Doors General DoorNumberOfPanels_ANZRS 72fa8514-933a-476e-a015-bd965b496335 Common Integer For Stacking & Bi-folding Doors
Doors Dimensions DoorPanelBWidth_ANZRS a103b830-0e16-406b-a757-9d2e2322b499 Common Length Used for Double leaf doors of unequal
width
Doors Dimensions DoorPanelDepth_ANZRS 06c6cc8a-b116-4d12-b763-f47858dccc8c Common Length
Doors Dimensions DoorPanelHeight_ANZRS 8d89d050-4116-4397-8b70-7efef66fef88 Common Length
Doors Dimensions DoorPanelWidth_ANZRS 8943a09d-41b6-4109-a34d-5865635be2d5 Common Length
Electrical Equipment
Electrical Equipment Electrical NumberOfPhases_ANZRS db2832d3-8fd6-4aff-beb2-4445299a4399 Common Text Apparent Power if using MEP
Electrical Fixtures
Electrical Fixture Electrical MountingType_ANZRS aeb9637d-840d-40e9-b7d6-2155c2f0a300 Common Text

Electrical Fixture Electrical NumberOfOutlets_ANZRS ae9a9461-f24b-4a30-9c06-5b4ffb04066c Common Integer
Entourage
Furniture
Furniture Constraints p p _
OperationalSpace_ANZRS f2067227-c4b4-4c4c-98b7-e3650f5549bf Common Length
g
Furniture Constraints SafetyZone_ANZRS bf1ff5a7-9eb5-41a3-a85b-8151058ccffd Common Length
Furniture Constraints WallOrSafetyScreen_ANZRS 7d169209-eb62-4e55-8da4-6a84ff2752fd Common Yes/No
Furniture Systems
Furniture System Green Building Properties SalvageOrReuse_ANZRS cc8bcf67-57be-4c6d-8622-fcb1e29b4aed Common Yes/No
Lighting Fixtures
Lighting Fixture Electrical Lighting Voltage_ANZRS baf9a875-90bd-402d-ad77-52b7ca270de1 Common Text Electrical Potential if using in MEP
Lighting Fixture Electrical Lighting Wattage_ANZRS fe00657c-289c-4509-9d2f-ab32e6ce1121 Electrical Wattage
Lighting Fixtures Electrical Lighting NumberOfLamps_ANZRS 58480370-c3c5-4bd6-b5a5-8258e8c2a991 Common Integer
Mass
Mass Identity Data Descriptor_ANZRS bdb78e8d-c24f-46c0-8623-f0133fe52eeb Common Text
Multiple Categories
Multiple Categories Analysis Results AcousticRating_ANZRS 878ef614-3eaa-4103-83b4-de08051507da Common Text

Multiple Categories Constraints FilterObject_ANZRS 972d25d6-210a-4efc-8853-7325d950979b Common Text Used to filter families in schedules
Multiple Categories Fire Protection FireRating_ANZRS 876c98f8-7c5e-45f1-b39a-408802ea9549 Common Text
Multiple Categories General InstallationGroup_ANZRS 44ae92ca-af39-49ec-b3bd-318ead7f92bb Common Number Group 1 - built and installed by builder,
Group 2 - purchased then installed by the
builder, Group 3 - Purchased and installed
by proprietor
Multiple Categories Identity Data StyleOrType_ANZRS c21ff3ca-caaa-4f70-a979-668d5e05e631 Common Text Door, Drawer, Casework Unit, Plumbing
Fixture, Car Park or Window Style
Multiple Categories Text ModifiedIssue_ANZRS 01d23264-4f17-4192-9aab-b6713511fcb5 Common Currency E.g.: YYMMDD.01
Multiple Categories Text CreatedBy_ANZRS fbed11cf-7186-4a1f-9570-e33895984d48 Common Text E.g.: Company Name
Multiple Categories Text CreatedByPhoneNo_ANZRS 028ef44d-611a-489c-896e-13b8bc7c6180 Common Text E.g.: Ph. +61-2 1234-5678
Multiple Categories Text CreatedByURL_ANZRS a2a5f573-a5c9-4fb1-a60b-44076867f985 Common Text
Multiple Categories Text CreatedByURL_ANZRS 346b98ef-5e53-4de5-9bef-5bf67eecc7ff Common Currency Eg:www.anzrs.org
Parking
Parking Dimensions CarparkWidth_ANZRS 6788cf80-07dd-4fc3-8924-6f7e548d5622 Common Length

Parking Dimensions CarparkDepth_ANZRS d6fc88aa-71be-4615-925f-f4a46da91a39 Common Length
Planting
Plumbing Fixtures
Plumbing Fixture Plumbing BowlCapacity_ANZRS 2f9461e8-e428-4668-8b29-4a91bf39e908 Common Volume

Plumbing Fixture Constraints Circulation_ANZRS 7cd8cdb0-705a-4a19-afe8-241004784e4c Common Yes/No For AS/NZ accessibility standards
Plumbing Fixture Identity Data FlushRate_ANZRS 7215a724-9f97-4930-b37e-4be13a79fffe Common Volume
Plumbing Fixture Identity Data FlushingTechnology_ANZRS 23c51c94-ec41-4810-8b4c-19cb313943b5 Common Text
Plumbing Fixture Identity Data InstallationType_ANZRS 6f656f82-2054-4078-9015-5226ae254661 Common Text
Plumbing Fixture Materials and Finishes PlumbingMaterial_ANZRS c7311995-c3c8-4540-8dba-275d100762c3 Common Material
Plumbing Fixture Plumbing TapHoles_ANZRS 0d080900-d609-42c5-ac2c-9762cdf618c2 Common Number
Plumbing Fixture Plumbing Trap_ANZRS 649fc895-d008-426b-9132-edfc726f51d0 Common Text
Plumbing Fixture Dimensions WasteOutlet_ANZRS 3c4534cf-e124-4ca2-a61d-5f4d574ec171 Common Number
Plumbing Fixture Identity Data WELSRating_ANZRS db2b9dcc-8bc6-4109-877c-2feca2edb3e9 Common Text
Railing
Site
Specialty Equipment
Structural Columns
Structural Column Materials and Finishes ColumnMaterial_ANZRS 491e601c-6b8e-4ad6-8b57-904f6875a0f0 Common Material
Structural Foundations
Structural Foundation Materials and Finishes FoundationMaterial_ANZRS a9b38a5d-b5a5-4fb0-9154-96357673c413 Common Material
Structural Framing
Structural Framing Materials and Finishes FramingMaterial_ANZRS 78dd9e62-12bc-447d-ae9f-f93739bc20dc Common Material
Telephone Devices
Windows
Windows Materials and Finishes WindowFrameFinish_ANZRS df9da2d7-217d-4bf2-aa53-34cc5bc0c10d Common Text

Windows Identity Data WindowFrameType_ANZRS bf0d9cbf-3c31-4db1-996e-e35796047527 Common Text
Windows Materials and Finishes WindowGlazingType_ANZRS 75cd52b1-774c-4d16-a535-a3566d4f6919 Common Text
Windows Dimensions WindowHeadHeight_ANZRS 82c1e324-f6e3-43b5-a11f-a60d6ba29e40 Common Length
Windows Materials and Finishes WindowFrameMaterial_ANZRS 5e097e4e-120c-415e-acb4-1a720cc3782b Common Material
REQUEST FOR INDUSTRY ASSISTANCE: We need more Industry feedback to improve this list and to better explain issues to be considered when creating discipline sympathetic content. Please provide clear examples
and explanation of issues through the feedback form on the ANZRS website.
It is our vision that these proposed standards will receive the promised support from the dominant commercial content creation companies in Australia, New Zealand as well as the Revit user community.
It is our intent that the criteria provided within this document pack will become the minimum benchmark of all shared and sold content throughout Australia and New Zealand. A content creator can only claim to provide
ANZRS-compliant content if the compliance requirements listed in this document are met on the respective components that they sell.
REVITFAMILYCREATIONPACK STRUCTURALSHAREDPARAMETERSPREADSHEET Version 3 [01-2012] C6
disciplineonly,or(b)beingcreatedtoservemorethanonediscipline.Structural specificrequirementsarediscussedbelow.
Multiple Categories
Multiple Categories General InstallationGroup_ANZRS 44ae92ca-af39-49ec-b3bd-318ead7f92bb Common Integer
Group 1 - built and installed by builder,
Group 2 - purchased then installed by the
builder,
Group 3 - Purchased and installed by proprietor
Multiple Categories Analysis Results AcousticRating_ANZRS 878ef614-3eaa-4103-83b4-de08051507da Common Number
Multiple Categories Text CreatedBy_ANZRS fbed11cf-7186-4a1f-9570-e33895984d48 Common Text E.g.: Ph. +61-2 1234-5678
Multiple Categories Text CreatedByURL_ANZRS 346b98ef-5e53-4de5-9bef-5bf67eecc7ff Common URL E.g. www.anzrs.org
Multiple Categories Text CreatedByPhoneNo_ANZRS 028ef44d-611a-489c-896e-13b8bc7c6180 Common Text
Multiple Categories Materials and Finishes Material_ANZRS cbe1507c-b099-40b2-ba07-7bb33df20f59 Common Material
Multiple Categories Constraints FilterObject_ANZRS 972d25d6-210a-4efc-8853-7325d950979b Common Text
Structural Rebar
Structural Columns
Structural Columns Structural Analysis ColumnConcreteStrength_ANZRS 754df05e-446c-4fd0-8b30-0f253fd1ad80 Common Text
Structural Connections
Structural Connections Dimensions BoltDiameter_ANZRS e440e5db-99fd-4a04-80b6-247eb51fd3d5 Common Length
Structural Connections Dimensions BoltSize_ANZRS 16606b93-c8f4-45f5-93df-985b0a1105ab Common Length
Structural Connections Constraints BoltSpacing_ANZRS e8fd2e89-4e9c-48da-bebc-d7878af5eaae Common Integer
Structural Connections Constraints Embedment_ANZRS 5d20b7ad-6494-4a81-8e9a-eacefbffc900 Common Text
Structural Connections General NumberOfBolts_ANZRS 00c38be6-b805-42bf-a95a-a999297a12e7 Common Integer
Structural Connections Dimensions PlateThickness_ANZRS 8d370c79-334d-4c52-84ca-04708f86415f Common Length
Structural Foundations
Structural Foundations Identity Data FootingMark_ANZRS 73c085b5-b0be-4aa5-8ca8-d2d568df4240 Common Text
Structural Foundations Dimensions BuriedDepth_ANZRS 659f4ae0-77c0-4892-9963-bbbb5c583503 Common Length
Structural Foundations Dimensions BlindingDepth_ANZRS 210f82e8-7d09-4bb6-9391-88d39c04f05c Common Length
Structural Foundations Dimensions RebateWidth_ANZRS 97ae7d81-0856-4958-8a36-73c9233f2cd6 Common Length
Structural Foundations continued..
continued
ANZRS_C6_STRUCTURAL SHARED PARAMETER LIST, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG 1/2

Structural Foundations Dimensions UpstandHeight_ANZRS f089b3fd-f809-4284-9655-e2bbceafcfa0 Common Length

Structural Foundations Dimensions PileDepth_ANZRS 7b35864c-14b3-4cc8-a07f-11693bea9cb2 Common Length
Structural Framing
Structural Framing Dimensions FramingWidth_ANZRS 2ab56d76-f726-430f-9ca6-fbe79a28c069 Common Length
Structural Framing Dimensions BeamDepth_ANZRS 901912f1-9c87-4fe5-9675-26e2cf01af82 Common Length
Structural Framing Dimensions FramingDepth_ANZRS 53999211-a59a-45f9-9a0f-f41a7f77a078 Common Length
Structural Stiffeners
Structural Stiffeners Dimensions OpeningOverhang_ANZRS a2e5d7e0-ced8-4f3e-bda7-8c52d33cd3f9 Common Length
Structural Trusses
Windows
REQUEST FOR INDUSTRY ASSISTANCE: We need more Industry feedback to improve this list and to better explain issues to be considered when creating discipline sympathetic content. Please provide clear examples
and explanation of issues through the feedback form on the ANZRS website.
It is our vision that these proposed standards will receive the promised support from the dominant commercial content creation companies in Australia, New Zealand as well as the Revit user community.
It is our intent that the criteria provided within this document pack will become the minimum benchmark of all shared and sold content throughout Australia and New Zealand. A content creator can only claim to provide
ANZRS-compliant
ANZRS compliant content if the compliance requirements listed in this document are met on the respective components that they sell.
ANZRS_C6_STRUCTURAL SHARED PARAMETER LIST, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG 2/2

REVITFAMILYCREATIONPACK MEPSHAREDPARAMETERSPREADSHEET Version 3 [01-2012] C7
disciplineonly,or(b)beingcreatedtoservemorethanonediscipline.MEP specificrequirementsarediscussedbelow.
Air Terminal
Air Terminal Mechanical Airflow AirTerminalStaticPressure_ANZRS 2467b38d-9570-445f-943d-c20d4829ff56 HVAC Pressure
Air Terminal Mechanical Airflow AirTerminalVelocityPressure_ANZRS a28e3ed3-a47a-41de-a4e7-dcb14bee9c4a HVAC Pressure
Air Terminal Mechanical Airflow ThrowDistanceHighVelocity_ANZRS c1f98d59-946e-4420-95d8-0c9e3bd7f780 HVAC Velocity
Air Terminal Mechanical Airflow ThrowDistanceLowVelocity_ANZRS ad759877-a15e-4d4d-bc1d-eac04b2d8439 HVAC Velocity
Air Terminal Mechanical Airflow ThrowDistanceMediumVelocity_ANZRS 1f48b4b0-e437-41c2-8630-b7a0533f6360 HVAC Velocity
Doors
Duct Accessories
Duct Accessories Mechanical Airflow AreaServed_ANZRS 6601f0ae-9d28-4af3-b566-90f8136f6c3b Common Area
Duct Accessories Mechanical FilterModuleFormat_ANZRS 99e780ed-c4c8-4216-a0cf-e13adfd7c73b Common Text 3x2, 3x3 etc.
Duct Accessories Mechanical FilterModuleSize_ANZRS 68bcd0f7-f5c4-47bf-9ab0-5ebf05288fc2 Common Text
Duct Accessories Identity Data FilterType_ANZRS c6fa9ace-9164-42aa-a4a0-b769483d5646 Common Text Flat Panel, Pleated Panel etc.
Duct Accessories Identity Data FireDamperType_ANZRS 987d1a51-09fb-49e1-8d9f-5001ccf2942c Common Text
Duct Accessories Fire Protection FireRating_ANZRS 6546c9cd-d82f-42b7-814c-4a94bea616df Common Text for Fire Dampers
Duct Accessories Identity Data InitialCleanResistance_ANZRS fef623bb-e3a2-4fc4-8c6f-011e395b3065 Common Text Pa
Duct Accessories Mechanical NominalHeatingCapacity_ANZRS f4c9a0fa-84d2-4f01-8191-659dac9709a4 Common Number kW
Duct Accessories Mechanical RecommendedFinalResistance_ANZRS 84d27e07-0a45-4ef3-908d-d40626ca92d7 Common Text Pa
Electrical Equipment
Electrical Equipment Electrical LineCurrentPhase3_ANZRS 2ecda723-9e1b-46d7-90b2-60e002b4fed3 Electrical Apparent Power Superseded by

ApparentLoadPhase3 ANZRS
Electrical Equipment Electrical ApparentLoadPhase3_ANZRS f7543670-ab95-4cb5-95f6-97157c70ca17 Electrical Apparent Power
Electrical Equipment Electrical NumberOfPhases_ANZRS 4119aa64-8bbc-44f3-9b05-f9928035cd56 Common Integer
Superseded by
Electrical Equipment Electrical ActivePower_ANZRS 7f042f44-0b86-4d93-aeed-877b98617482 Electrical Wattage
ApparentLoad_ANZRS
Electrical Equipment Electrical ApparentLoad_ANZRS a95f1141-eec5-4fa0-b45c-2704213bc28e Electrical Apparent Power
Electrical Equipment Electrical PowerFactor_ANZRS d49beec4-4247-4b62-a6df-87f86fb5bb34 Common Number
Electrical Equipment continued..
Electrical Equipment Electrical LineCurrentPhase1_ANZRS 7ab09009-4e8c-417f-a1da-c121146ddda3 Electrical Apparent Power Superseded by

Electrical Equipment Electrical ApparentLoadPhase1_ANZRS ccbd1e01-8774-45e3-b472-856575c924ce Electrical Apparent Power
ANZRS_C7_MEP SHARED PARAMETER LIST, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG 1/4

Superseded by new version, using
Electrical Equipment Electrical BallastLoad_ANZRS 965f5313-6ef5-4fb4-9035-24b21f088b19 Common Number
Wattage as unit type
Electrical Equipment Electrical BallastLoad_ANZRS 8e48bd49-e00c-444b-825a-eff53f4bb8c8 Electrical Wattage
Electrical Equipment Electrical PowerFactorState_ANZRS 2497d420-9378-4d34-bcbe-d8493769e30b Common Yes/No
Electrical Equipment Electrical LineCurrentPhase2_ANZRS 2ec83b2e-6932-48cf-9fdd-1624f87b547c Electrical Apparent Power Superseded by
Electrical Equipment Electrical ApparentLoadPhase2_ANZRS 62b6a35e-272f-497c-90ee-5236df998984 Electrical Apparent Power
Electrical Fixtures
Electrical Fixtures Electrical NumberOfOutlets_ANZRS adfd2219-b2f8-44c5-a941-f90703fa2af1 Common Integer

Electrical Fixtures Electrical MountingType_ANZRS 10c7e54d-fc76-450a-bcdd-a377ace5b97b Common Text
Fire Alarm Devices
Lighting Devices
Lighting Fixtures Electrical NumberOfLamps_ANZRS 4e3c9549-5131-48ff-bfca-72edc81eee3f Common Integer
Mechanical Equipment
Mechanical Equipment Plumbing PumpImpeller_ANZRS 641923d3-7be6-4968-bcf9-40e273d07eba Common Text
Mechanical Equipment Plumbing PumpShaft_ANZRS 05444f7b-f3e5-45a2-8f26-e4b3fc3c7c20 Common Text
Mechanical Equipment Plumbing PumpShaftSeal_ANZRS 7656040a-3f02-41d3-8499-9f93b81c894d Common Text
Mechanical Eq
Equipment
ipment Pl mbing
Plumbing MinP mpEfficienc ANZRS
MinPumpEfficiency_ANZRS f73eead1 f048 45f1 b575 def270a49a00
f73eead1-f048-45f1-b575-def270a49a00 Common N mber
Number
Mechanical Equipment Plumbing PumpHead_ANZRS c247224e-a153-4f35-bb60-bf549843cec2 Common Length
Mechanical Equipment Plumbing PumpCapacity_ANZRS b295a262-c5f3-408e-a669-8da35f7179e6 Piping Flow
Mechanical Equipment Plumbing PumpService_ANZRS ebaa6d05-7ae3-49e0-a037-d56810debc07 Common Text
Mechanical Equipment Plumbing PumpCasing_ANZRS a93ace1d-6f87-4ac1-88af-3a34e930031a Common Text
Mechanical Equipment Mechanical MaxSpeedRevsPerSecond_ANZRS d87340ff-dbb6-4ad3-9c9d-978df06d0df8 Common Integer
Mechanical Equipment Mechanical NoiseLeveldBA_ANZRS 9bf22bc2-6e15-4210-bfcc-1e645413f8c3 Common Integer
Mechanical Equipment Mechanical FanDiameter_ANZRS 71953797-4788-4003-979e-add1c11a4e9c Common Length
Mechanical Equipment Mechanical Refrigerant_ANZRS f50ab3a2-eecf-469f-95d5-b25a9cc009ff Common Text
Mechanical Equipment Mechanical ImpellerType_ANZRS 41272b04-8602-4878-b9c5-eebdaee94cf0 Common Text
Mechanical Equipment Mechanical SensibleCoolingCapacity_ANZRS 4fe00da2-8c50-4342-a279-6f5cc27fa4c7 HVAC Cooling Load BTUh or W
Mechanical Equipment Mechanical NominalCoolingCapacity_ANZRS 7960b6d4-ba04-4eb9-81da-02ae5159e8a1 HVAC Cooling Load BTUh or W
Mechanical Equipment Mechanical TotalCoolingCapacity_ANZRS 6c338c3a-60d6-4cb3-8037-99a73e39564b HVAC Cooling Load BTUh or W
Mechanical Equipment continued..
Mechanical Equipment Mechanical TotalHeatingCapacity_ANZRS 009b85b6-ef88-4290-88fc-41b61c8c2469 HVAC Heating Load BTUh or W
Mechanical Equipment Mechanical Airflow EnteringAirDB_ANZRS 63e70534-47bf-47e5-9ec6-94dd3e4ed92b HVAC Temperature
Mechanical Equipment Mechanical Airflow ExtStaticPressure_ANZRS 3695a101-1830-4b24-9626-a67a525df4c3 HVAC Pressure Ft. of head
Mechanical Equipment Mechanical Airflow MinimumAirFlow_ANZRS a2965be9-43e7-44b0-97a3-9055a3eda963 HVAC Air Flow
Mechanical Equipment Mechanical Airflow MaximumAirFlow_ANZRS 24415c8e-9017-41ee-8b7b-72822906369b HVAC Air Flow

Mechanical Equipment Mechanical FCU_s_Served_ANZRS a7f9c3f7-c0c1-4fcb-9175-d8d7a1f7da8d Common Text

Mechanical Equipment Mechanical FCU_s_Served_ANZRS ad7301c5-763f-4935-ab43-7e0173af670b Common Text
Mechanical Equipment Mechanical RPM_ANZRS 6c5ab7b8-7ebf-4a89-9ffe-7c0366690d70 Common Integer
Mechanical Equipment Mechanical ExhaustFan_ANZRS 60ef8c54-c285-4213-8061-cf6fbe45dd5d Common Yes/No Built-in exhaust fan - Yes or no?
Mechanical Equipment Identity Data OperatingWeight_ANZRS 1b592ea2-7b19-435a-bb30-58dde06d85bc Structural Force lbs or kgs
Mechanical Equipment Dimensions EquipmentWidth_ANZRS 1480a020-4f43-468c-9931-4afe73d1ed9c Common Length
Mechanical Equipment Mechanical TemperatureExchangeEfficiency_ANZRS 8752a61f-da34-459a-a454-02eec046d058 HVAC Coefficient of Heat
Transfer
Mechanical Equipment Mechanical EnthalpyExchangeEfficiency_ANZRS e7d0e63c-ea31-4f29-b606-106b19ac15ca HVAC Coefficient of Heat
Transfer
Mechanical Equipment Mechanical HeatingCapacity_ANZRS 1673f40a-abee-4b70-bc94-d682a403f15a HVAC Heating Load
Mechanical Equipment Mechanical HeatTransferDuty_ANZRS 248feadb-bf60-4e0c-b0f4-31aab807a721 HVAC Heat Gain
Mechanical Equipment Mechanical EquipmentNominalHeatingCapacity_ANZRS 08409b81-0333-44fd-a447-2daa91e0ee81 HVAC Heating Load
Mechanical Equipment Mechanical Airflow PressureDrop_ANZRS ba0cc0cb-e1e0-487c-b97a-a769c6e7ef11 HVAC Air Flow
Mechanical Equipment Mechanical Airflow EquipmentAirFlow_ANZRS 4bbf6d91-fa8c-4a18-b174-e757c6bcc404 HVAC Air Flow
Multiple Categories
Multiple Categories General InstallationGroup_ANZRS 44ae92ca-af39-49ec-b3bd-318ead7f92bb Common Integer Group 1 - built and installed by
builder, Group 2 - purchased then
installed by the builder
builder, Group 3 -
Purchased and installed by
proprietor
Multiple Categories Mechanical Side1TempOut_ANZRS cebc7355-59bc-4c38-b706-e387a31a1f70 HVAC Temperature
Multiple Categories Mechanical CHWPressureDrop_ANZRS e5baaca6-cbf2-4663-8320-868b3f6576c0 Piping Pressure
Multiple Categories Mechanical Side1Flow_ANZRS 35b6889f-197b-41a8-a139-89c4a538bb12 Piping Flow
Multiple Categories Mechanical Side2TempIn_ANZRS 8d9a9c0b-3bee-4f63-a326-1aa781a626ca HVAC Temperature
Multiple Categories Mechanical CHWFlow_ANZRS 4d4404e1-8cf4-471b-90c1-f46e9cb04458 Piping Flow
Multiple Categories Mechanical Side2Flow_ANZRS 96aeb045-e9e4-42fa-9286-40b01a579f1c Piping Flow
Multiple Categories Mechanical Side1TempIn_ANZRS 3616ca7d-e2af-4848-8474-80eb9f617a57 HVAC Temperature
Multiple Categories Mechanical Side2TempOut_ANZRS 51df882d-1a2e-4458-8d00-41433335b01a HVAC Temperature
Multiple Categories Mechanical MotorFL_ANZRS 518c264d-fd11-418b-bfa4-0588e2f1715c Electrical Current
Multiple Categories continued..
Multiple Categories Mechanical MotorFLA_ANZRS fce5488f-93f6-4a55-84ce-bf41428c66b2 Electrical Current
Multiple Categories Electrical EssentialLoad_ANZRS b39e398a-5cc4-4256-8e3a-35d28a04fd6b Common Yes/No
Multiple Categories Electrical ApparentPower_ANZRS e23541f7-b7ef-4360-b5a9-4901e0df0d4f Electrical Apparent Power
Multiple Categories Electrical StartingCurrent_ANZRS 02518aa5-00cb-47d7-80ce-812016abfe4f Electrical Current
Multiple Categories Electrical NumberOfPoles_ANZRS 38f27766-bcb3-4e26-861c-5da76ff093ba Electrical Number of Poles
Multiple Categories Electrical MotorHP_ANZRS 1742f8cb-0321-4892-a32e-9de1fb5faf50 Common Text

Multiple Categories Electrical ApparentCurrent_ANZRS c744570e-2508-472e-949f-8708fbf2a886 Electrical Current

Multiple Categories Mechanical Airflow ActualReturnAirFlow_ANZRS c672fd45-6a3b-46a4-ae2b-db405e05f7e4 HVAC Air Flow
Multiple Categories Mechanical Airflow ActualSupplyAirFlow_ANZRS 8c849464-f89d-43fb-87a5-18c5b06ffcdc HVAC Air Flow
Multiple Categories Mechanical Airflow OutsideAirflow_ANZRS fc35a33a-eab9-499e-90eb-7f71066727f8 HVAC Air Flow
Multiple Categories Electrical Wattage_ANZRS 2d4bf2c6-177e-465d-8729-d13913a1b7e1 Electrical Power
Multiple Categories Electrical Voltage_ANZRS c9598df6-dd91-4e04-80c2-9e3d3ce2d306 Electrical Electrical Potential
Multiple Categories Mechanical Airflow AirTerminalTotalPressure_ANZRS a4f64ec3-943c-4f76-9d84-fec9bfdc7ad2 HVAC Pressure
Multiple Categories Electrical Frequency_ANZRS 540cd79b-31a0-48c6-984c-2c3ce7d26975 Electrical Frequency
Multiple Categories Text CreatedByPhoneNo_ANZRS 028ef44d-611a-489c-896e-13b8bc7c6180 Common Text E.g.: Ph. +61-2 1234-5678
Multiple Categories Text CreatedByURL_ANZRS 346b98ef-5e53-4de5-9bef-5bf67eecc7ff Common URL Eg: www.anzrs.org
Multiple Categories Text CreatedBy_ANZRS fbed11cf-7186-4a1f-9570-e33895984d48 Common Text E.g.: Company Name
Plumbing Fixtures
Plumbing Fixtures Constraints Circulation_ANZRS 7cd8cdb0-705a-4a19-afe8-241004784e4c Common Yes/No For AS/NZ accessibility standards
Plumbing Fixtures Dimensions WasteOutlet_ANZRS 3c4534cf-e124-4ca2-a61d-5f4d574ec171 Common Number

g Fixtures
Plumbing Identity
y Data Type
yp _ANZRS 7766a322-95b4-427c-bc4e-a4140e2caf0f Common Text
Error in previous release,
Plumbing Fixtures Identity Data FlushingTechnology_ANZRS 81434f0c-96b3-48a8-853c-7afe3f705378 Common Text
therefore being replaced.
Plumbing Fixtures Identity Data FlushingTechnology_ANZRS 23c51c94-ec41-4810-8b4c-19cb313943b5 Common Text
Plumbing Fixtures Identity Data InstallationType_ANZRS 6f656f82-2054-4078-9015-5226ae254661 Common Text
Plumbing Fixtures Identity Data WELSRating_ANZRS db2b9dcc-8bc6-4109-877c-2feca2edb3e9 Common Text
Plumbing Fixtures Identity Data FlushRate_ANZRS 7215a724-9f97-4930-b37e-4be13a79fffe Common Volume
Plumbing Fixtures Plumbing Trap_ANZRS 649fc895-d008-426b-9132-edfc726f51d0 Common Text
Plumbing Fixtures Materials and Finishes PlumbingMaterial_ANZRS c7311995-c3c8-4540-8dba-275d100762c3 Common Material
Plumbing Fixtures Plumbing TapHoles_ANZRS 0d080900-d609-42c5-ac2c-9762cdf618c2 Common Number
Plumbing Fixtures Plumbing BowlCapacity_ANZRS 2f9461e8-e428-4668-8b29-4a91bf39e908 Common Volume
Sprinklers
Sprinklers Plumbing SprinklerFlow_ANZRS 98dba6bc-3b13-4210-8d31-8ba0edba99ba Common Volume
Sprinklers Plumbing SprinklerPressure_ANZRS 25785697-2cfb-4679-9e0e-aee28bd82a88 Common Volume
Sprinklers Fire Protection SprinklerGuard_ANZRS 62dc217e-76dc-4452-b12d-ce0c7ad19518 Common Yes/No
REQUEST FOR INDUSTRY ASSISTANCE: We need more Industry feedback to improve this list and to better explain issues to be considered when creating discipline sympathetic content. Please provide clear
examples and explanation of issues through the feedback form on the ANZRS website.

REVIT FAMILY CREATION PACK - COMPLIANCEREQUIREMENT C8
Thisreferencelistdefinesthelistofsubcategoriestobeusedtomeetminimum
compliancecriteria.Additionalsubcategoriesmaybecreatedbycontentcreatorsas
needed,butthisbasiclistshouldbeusedtoensureimprovedconsistencybetween
contentthatissharedandsoldfromdifferentcontentsources.
LIST OF COMPLIANT SUBCATEGORIES Version 3 [01-2012]
ANZRS has assembled a list of subcategories for each of the standard Revit Object Styles (also known as Categories). Some are hard-coded
(already built-in), and cannot be deleted or renamed. These have been highlighted in red text, and with a red dot preceding their names.
The lineweights and line patterns that can be assigned have not been mandated within ANZRS, as they fall outside the current project scope. The
names of the subcategories, and their naming syntax, however, are included as compliance requirements.
The list does not purport to be exhaustive, but it is expected to grow similar to the Shared Parameter lists with the contribution from others (via
feedback through the ANZRS website)
website). Where subcategories have been provided
provided, the use of competing subcategories is prohibited and
constitutes non-compliance. For example, under the Category Plumbing Fixtures, the use of a subcategory WC would be deemed to be
competing with the established Toilets/Bidets subcategory already provided by ANZRS. Where there is a need for another subcategory beyond
what is already provided, the subcategory should subscribe to the conventions listed in C1s Section 5.03 Subcategory Naming to maintain
compliance with ANZRS. A more exhaustive list of these conventions (with examples are found in R2 19.04-19.07)
ADDITIONAL NOTES:
Furniture vs. Furniture Systems
Many Revit users are initially (and sometimes permanently) confused as to why Furniture and Furniture Systems co co-exist
exist as Object Styles. There
is no apparent difference other than that they can be scheduled separately. The name Furniture Systems suggests an intended use for modular
or system-based furniture, as opposed to the more isolation-based context for Furniture.
Apparently, Furniture Systems was (in Revits earlier years of development) intended to be cuttable, whereas Furniture was not. Had this
eventuated, it would help explain why both are supported within the product. By observation, it appears as though since Autodesks acquisition of
Revit that this has 'fallen through the cracks.
Software Limitations:
There are various software-driven limitations which these standards have had to work around the cuttable vs. non-cuttable limitations of some
categories is one such limitation. If/when this changes within the product, the standards will be amended to reflect this.
CATEGORY CUTTABLE SUBCATEGORY EXAMPLE / COMMENTS

Air Terminals No Clearance Zones Safety clearances, servicing access zones etc.

Cable Tray Fittings No Center line
Clearance Zones Safety clearances, servicing access zones etc.

Cable Trays No Center line
Drop
Rise

Casework Yes Cabinets/Panels Visual 'layer' over carcase
Carcass/Framing
Counter Tops
Glass
Hardware Ironmongery (where required)
Hidden Lines Can be used for showing items above or below others
Opening
Sh l i
Shelving_Fixed
Fi d
Shelving_Freestanding
Swing_Elevation Dashed lines typically to show object actions
Swing_Plan Dashed or solid lines typically to show object actions
Workstations/Desks Used where family needs to be custom and/or cuttable - if
not, use Furniture Systems->Workstations
ANZRS_C8_COMPLIANT SUBCATEGORIES LIST,VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG 1/9

Ceilings Yes Common Edges
Hidden Lines

Columns Yes Clearance Zones Safety clearances, servicing access zones etc.
Hidden Lines

Communication Devices No Clearance Zones Safety clearances, servicing access zones etc.

Conduit Fittings No Center line

Conduits No Center line
Drop
Rise

Curtain Panels Yes Frame Used on sash panels or others requiring inin-built
built
frame/mullions
Glass Transparent Panel - typically glass or perspex of some
kind
Hardware
Hidden Lines
Panel Opaque only
Sealant
Swing Elevation
Swing_Elevation Leaf/Panel/Sash opening lines (typically dashed) shown
in elevation (may also be used in 3D, if required)
Swing_Plan Leaf/Panel/Sash opening lines (typically dashed or solid)
shown in plan
Thresholds

Curtain Systems Yes Hidden Lines

Curtain Wall Mullions Yes Hidden Lines

Data Devices No

Detail Items No Hidden Lines
Light Lines
Lighter Lines
Lightest Lines Suggest minimum line thickness applicable
Medium Lines
Thick Lines
Thicker Lines
Thickest Lines Suggest maximum line thickness required

Doors Yes Architrave/Trim
Frame/Mullion
Glass Can't rename to Glazing
Hardware Ironmongery (if required)
Hidden Lines

Opening
Panel
Structural Opening
Swing_Elevation Leaf opening lines (typically dashed) shown in elevation
(may also be used in 3D, if required)
Swing_Plan Leaf opening lines (typically solid) shown in plan
Thresholds

Duct Accessories No Clearance Zones Safety clearances, servicing access zones etc.

Duct Fittings No Center line
Contour

Duct Insulations No Clearance Zones Safety clearances, servicing access zones etc.

Duct Linings No Clearance Zones Safety clearances, servicing access zones etc.

Duct Placeholders No Clearance Zones Safety clearances, servicing access zones etc.

Ducts No Center line
Drop
Rise

Electrical Equipment No Clearance Zones Safety clearances, servicing access zones etc.
Hidden Lines
Switchboards Switchboard housing is included

Electrical Fixtures No Clearance Zones Safety clearances, servicing access zones etc.
General Purpose Outlets
Heaters Radiant heaters attached to building (walls
(walls, ceilings
typically)
Hidden Lines

Entourage No Clearance Zones Safety clearances, servicing access zones etc.
Hidden Lines
People Includes other animals
Sundries Excess objects for rendering purposes
Vehicles Cars, Trucks, Boats etc.

Fire Alarm Devices No

Flex Ducts No Center line
Pattern

Flex Pipes No Center line
Pattern

Floors Yes Clearance Zones Safety clearances, servicing access zones etc.
Common Edges
Hidden Lines
Interior Edges
Slab Edges All seating - fixed or loose

Furniture No Bedding
Drawers/Dressers
Hidden Lines
Outdoor Furniture Tables, Chairs, Umbrellas, Awnings
Seating_Fixed
Seating_Freestanding
Shelving Shelving that is available 'off the shelf', and does not
constitute a Storage system (see Furniture Systems)
Tables_Fixed
Tables_Freestanding

Furniture Systems No Hidden Lines
Partitions
Pedestals For loose fitout items such as wastepaper bins, refer to
Entourage
Storage Includes Storage Systems, such as compactuses,
lockers, metal cabinets etc.
Workstations Users may find that Casework is a preferable category for
Workstations, as they are often L-shaped, and if created
as Furniture or Furniture Systems categories, do not
support
pp a cut representation.
p
Workstations may also cover other similar modular
elements such as benches/tables in schools.
Generic Models Yes Clearance Zones Safety clearances, servicing access zones etc.
Hardware Ironmongery for doors and windows
Hidden Lines
Plinths For internal applications - Refer Site category for external
applications
Signage Does not include illuminated lighting

HVAC Zones No Boundary

Lighting Devices No Clearance Zones Safety clearances, servicing access zones etc.

Lighting Fixtures No Clearance Zones Safety clearances, servicing access zones etc.
Hidden Lines
Light Source
Signage For non-illuminated signage, use Generic Models
category
M
Mass Y
Yes F
Form
Gridlines
Hidden Lines
Mass Exterior Wall
Mass Floor
Mass Glazing
Mass Opening
Mass Roof

Mass Shade
Mass Skylight
Mass Zone
Nodes
Pattern Fill
Pattern Lines

Mechanical Equipment No Air Handling Units
Boilers
Chilled Beams
Chilled Water Sets
Chillers
C d
Condensing
i Units
U it
Conveyor Systems
Cooling Towers
Extraction Systems Rangehoods, Fume Cupboards
Fans
Hidden Lines
Transportation Equipment Travelators/Escalators/Elevators
Variable Air Volume Terminals

Nurse Call Devices No Clearance Zones Safety clearances, servicing access zones etc.
Hidden Lines

Parking No Bike Racks
Graphics Parking signage (on-surface), such as access symbols
Hidden Lines
Wheelstops
Parking Layout Traffic Management items (speed humps, islands, access
spikes etc.)
Parts Yes Hidden Lines

Pipe Accessories No Clearance Zones Safety clearances, servicing access zones etc.
Hidden Lines

Pipe Fittings No Center line

Pipe Insulations No Clearance Zones Safety clearances, servicing access zones etc.
Hidden Lines

Pipe Placeholders No Center line

Pipes No Center line
Drop
Rise

Planting No Clearance Zones Safety clearances, servicing access zones etc.
Ground Cover
Hidden Lines
Trees/Shrubs

Plumbing Fixtures No Basins/Sinks/Tubs Material application may vary, but functionally they are
nearly the same thing - requiring supply and egress of
fluid.
Baths/Showers Typically don't have separate visibility requirements.
Some units are literally combined, in any case.
Gas Cooking Equipment Plumber connects gas services
Gas Supply Fixtures Plumber connects gas services
Hidden Lines
Host Cuts Subcategory would typically stay visible on Slab
Setout/Penetration plans, while fixture is invisible.
Taps/Mixers Functionally these are effectively the same thing.
Toilets/Bidets Typically the same material and visibility requirements
Urinals May be integrated with Toilets/Bidets?
Waste Outlets Drain locations within sanitary fixtures, where host cut
may or may not be aligned.
Water Storage Hot Water Units
Units, Water Tanks etc
etc.

Railings Yes Balusters Vertical Rail Supports
Hidden Lines
Railings Beyond Cut Line
Rails

Ramps Yes Down Arrow
DOWN text
Hidden Lines
Ramps Beyond Cut Line
Stringers
Stringers Beyond Cut Line
Up Arrow
UP text

Roads Yes Hidden Lines

Roofs Yes Common Edges
Fascias
Gutters
Hidden Lines
Interior Edges
Soffits

Security Devices No Clearance Zones Safety clearances, servicing access zones etc.

Shaft Openings No Hidden Lines

Site Yes Hard Landscaping Bollards, plinths and other impact/protection devices
Hidden Lines
Pads
Property Lines
Site Furniture Receptacles (bins), fixed outdoor seating (e.g. park
benches). Furniture category in this case does not
automaticallyy host to topographic
g elements, whereas Site
components do.
Utilities
Way Finding Tactile Indicators etc.

Specialty Equipment No Appliances Refrigerators, Freezers, Microwaves, Televisions, etc. -
anything that simply requires a socket connection.
Audio Equipment Speakers
Bathroom Fixtures Paper Towel Holders
Holders, Toilet Tissue Dispensers
Dispensers, Soap
Dispensers, Hand Dryers, Towel Rails
Display Boards Whiteboards/Blackboards/Pinboards/Electronic
Smartboards
Grab Rails Grab Rails for disabled access
Hidden Lines
Security Equipment For non-electrical/comms Equipment

Sprinklers No Clearance Zones Safety clearances, servicing access zones etc.

Stairs Yes Hidden Lines
Down Arrow
DOWN text
Stairs Beyond Cut Line
Stringers
Stringers Beyond Cut Line
Up Arrow
UP text

Structural Area Yes Boundaryy
Reinforcement
Structural Beam Systems No Hidden Lines

Structural Columns Yes Hidden Faces
Hidden Lines
Rigid Links
Stick Symbols

Structural Connections No

Structural Foundations Yes Hidden Lines

Structural Framing Yes Chord
Girder
Hidden Faces
Hidden Lines
Horizontal Bracing
Joist
Kicker Bracing
Other
Purlin
Rigid Links
Stick Symbols
Vertical Bracing
Web
W b

Structural Path Yes Boundary
Reinforcement
Structural Rebar Yes

Structural Stiffeners Yes

Structural Trusses No Stick Symbols

Telephone Devices No

Topography Yes Hidden Lines
Primary Contours
Secondary Contours
Site Scrape Contour Can be applied through Site Settings ->Contour Line
Display
Triangulation Edges

Walls Yes Clearance Zones Safety clearances, servicing access zones etc.
Common Edges
Hidden Lines
Sweep_Cornice Applicable to wall sweeps
Sweep_Skirting Applicable to wall sweeps

Windows Yes Architrave/Trim
Frame/Mullion
Glass Can't rename this to glazing.
Hardware Ironmongery (if required)
Hidden Lines
Moulding/Muntins Do these need to be separate?
Opening
Reveal
Sash
Sill/Head
Sill_Wall For sills embedded within window families
Swing_Elevation Sash opening lines (typically dashed) shown in elevation
(may also be used in 3D
3D, if required)

Swing_Plan Sash opening lines (typically dashed) shown in plan

Wires No Home Run Arrows
Wire Tick Marks
NOTES
It is our intent that the criteria provided within this document pack will become the minimum benchmark of all shared and sold content throughout
Australia and New Zealand. A content creator can only claim to provide ANZRS-compliant content if the compliance requirements listed in this
document are met on the respective components that they sell.

REVIT FAMILY CREATION PACK - ADVANCEDFEATURESCHECKLIST R1
considerationsthatform partofrecommended
practices.Thesearenotcompliancerequirements.
ADD IMAGEHERE
FAMILY NAME AUTHOR
GENERAL REQUIREMENTS Version 3 [01-2012]

1 FILE MANAGEMENT Y N
1.01 Units
2 REFERENCE PLANES Y N
2.01 Embedded intelligence
2.02 Easy selection
3 GEOMETRY Y N
3.01 Detail Level
3.02 Visibility Settings
3.03 Symbolic Lines (Correct use)
3.04 Flip controls (Flip arrows)
3 05
3.05 Correctt orientation
C i t ti in i views
i
4 OBJECT STYLES & SUBCATEGORY Y N

4.01 Geometry & Linework Subcategories
4.02 Graphic Overrides
4.03 Customised line patterns
5 PARAMETERS Y N
5.01 Grouping
5.02 Modified By
5.03 Formulae
5.04 Locked Values
5.05 Scheduling & Tagging
6 NESTING Y N
6.01 Minimize Nesting
6.02 Purging All
6.03 When to nest
7 MATERIALS Y N
7.01 Naming of Materials
7.02 Material parameter assignment
7.03 Shared parameters for scheduling
8 OTHER Y N
8.01 Tagging & Keynoting
8.02 Discipline-specific Requirements
ANZRS_R1_ADVANCED FEATURES CHECKLIST, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG 1/2

SIGNATURE
APPROVED ISSUED
NOTES
SEE SEPERATE CHECKLIST PDF PACK FOR DIGITAL CHECKLIST FORMS.

Refer to R1s SUMMARY OF ADVANCED FEATURES for definitions of the topics listed above.
ANZRS_R1_ADVANCED FEATURES CHECKLIST, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG 2/2

REVIT FAMILY CREATION PACK - REFERENCE [OPTIONAL] R1s
Thisreferencelistsetsoutadditionalfeaturesthatcanbedefinedwithinafamilythatwill
requiremoreadvancedfamilycreationexperience.TheitemslistedbelowareANZRS
optionalrequirements.Itisuptoindividualcontentcreatorsorfirmstoevaluatehow
theseadditionalfeaturesmaybenefittheirclientsoroutput.
ADVANCED FEATURES SUMMARY SHEET Version 3 [01-2012]
1 FILE MANAGEMENT QUESTION ANSWER

1.01 Units Have the correct units been All components are recommended to be created using metric
used within this component? templates; units must always be in millimetres, unless object is large
enough to justify being measured in metres. (E.g. Building Mass)
Discipline-specific units we suggested to comply with Australian/New
Zealand industry standards.
2 REFERENCE PLANES QUESTION ANSWER

2.01 Embedded intelligence Have the default reference Default reference planes that are required for component functionality
planes (those with are recommended to be kept in the family. This is particularly relevant
embedded intelligence) been for some discipline-specific families (E.g. Structural Beam families).
retained? The function of reference planes can then be checked before deletion.
Default reference planes from the family template that do not have
embedded intelligence/functionality, and are not being used, may be
removed from the component.
2.02 Easy selection Are the extents of all If several types have been created within a family then it is important
Reference Planes neat and that the length of the Reference planes is sufficient to extend beyond
tidy? the extent of the largest family type that has been created.
Reference planes are best kept 'neat' to make understanding the
construction and constraints within the family as simple and clear as
possible.
The displa
display eextents
tents of all Reference Planes need to be set to 3D
(not 2D) to ensure that all views are updated simultaneously when the
extents of a Reference Plane are edited (the only exception is when
the reference plane in a single view is obstructing visibility).
For co-linear Reference Planes, extend or shorten the extents of
each to ensure easy selection and clear distinction between them.
Naming them would assist in this distinction.
3 GEOMETRY QUESTION ANSWER

3.01 Detail Level Have the Coarse, Medium, Whilst the Detail Level is not required to make a component
Fine Detail Level settings compliant it may be worth considering.
been set appropriately for For large projects (e.g. Healthcare) ensure that simplified plan
each element? representations of components are visible in views showing Coarse
Detail Level to improve performance (see R2 Section 22.05 - Coarse
Detail for more information).
3.02 Visibility Settings Have the visibility settings Simplified plan representations of components can declutter views,
been set and checked for resulting in clearer documentation. Additional symbolic line work may
elements that should not be be added to help distinguish one object from another.
visible in specific view types? Content creators will need to evaluate this requirement based on the
family brief and possible end-user requirements.
Refer R2 Sections 22.01 to 22.07 for more information.
3.03 Symbolic Lines: Correct How have symbolic lines Use symbolic linework to add detail when required. (e.g. door swing
use been used appropriately in linework to be displayed in plan or elevation views).
the family? Assign linework to the correct subcategory (refer "List of Compliant
Subcategories")
For neat and 'lightweight' plan representations, use linework to create
symbolic plan detail and hide the complex geometry in plan views.
Can be used to define sectional appearance in cuttable families,
when modelled geometry is hidden.
ANZRS_R1s_ADVANCED FEATURES SUMMARY, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG 1/4

3.04 Flip controls (Flip Have flip controls been Where appropriate, have the necessary flip controls been added?
arrows) correctly used? Be consistent in where you place flip controls in your components.
Ensure that the flip control is easily seen within the project
environment at a scale of 1:50 and 1:100. (What may seem to be a fair
distance in the Family Editor environment at a scale of 1:10 or 1:20
can be too close in the project environment.
Note: Some flip controls cannot be deleted from a family. E.g. Door
families come with default flip controls which cannot be deleted from
all views.
Refer to R2 Section 6.08 & 6.09 - 'Flip Controls' for more
information.
3.05 Correct orientation in Has the family been correctly The named views in the family editor should correspond with the
views oriented? actual directions of the view with respect to the family. For example,
the Front Elevation view of the family is in fact the front view of the
object.
Rename the views and/or Reference Planes if an error has been
made, so that the family displays correctly in the Family Editor.
When families are created to be hosted in a wall (e.g. Door or
Window) make sure to build the component to match the defined wall
orientation. The exterior wall face will be automatically defined in the
Family Editor. If this is not done, the component will be facing the
wrong way when placed in a wall within the project environment.
Refer to R2 Section 15.01 - Origin Locations for more information.
OBJECT STYLES &

4 QUESTION ANSWER
SUBCATEGORY
4.01 Geometry & Linework Does the family contain all Ensure all subcategories are either from those provided by ANZRS,
subcategories the required subcategories or conform to the naming rules supplied (see Form C1s Section 5.03
for the geometry and Subcategory Naming)
symbolic linework? Be sure to test the family in the project environment to check that the
subcategories work as intended in the 'Visibility/Graphic Overrides' and
'Object Styles' dialogues. This test also helps to check that all
geometry and linework is assigned to the correct subcategories.
4 02
4.02 Graphic Overrides Have any graphic settings Avoid altering properties of default Line Styles and Line Patterns from
been changed? metric family templates, as these stand to conflict with expected
display properties of downstream users of the content.
4.03 Customised line Have any linework settings The default settings that come with the family templates are
patterns been customised? acceptable. For consistency we recommend that these settings be
maintained. Only override line thicknesses or styles where there is a
specific reason to do so, and then document that reason for future
reference.
5 PARAMETERS QUESTION ANSWER

5.01 Grouping Have parameters been Content creators may use their own discretion when grouping
grouped logically and parameters. However, the grouping should be logical, and consistently
consistently? applied across all families by the same author. It is preferable to group
in a consistent manner related to the actual function of the parameter.
Refer to SP Lists - C5, C6 and C7 for recommended parameter
grouping of ANZRS compliant parameters.
5.02 Modified By Has a 'Modified By' Enter the company name of the modifier in the ANZRS Shared
parameter been added for Parameter 'ModifiedBy_ANZRS' to keep a record that this component
content that has been has been edited by someone other than the original authoring
changed by company (not company.
original content creator)? Do not delete the 'CreatedBy_ANZRS 'parameter or associated
values as defined in Form C1s (Section 6.02).
Respect copyright and ownership rights of other content creators.
5.03 Formulae Is the logic of the formulae Have the formulae and conditional statements been used correctly?
being used easy to follow? Ensure that formulae can be understood or logically followed by using
clearly defined parameters and keeping the formulae reasonably
simple, where possible and appropriate. It is beneficial for both the
content creator and the user to work with a component that is easy to
understand and repair in future, as needed.

5.04 Locked Values Does the family use locked This functionality can be useful for BPM-specific content, but is not
values for parameters that generally recommended for generic content which may be designed to
should remain constant for be more flexible in application to varying projects.
all types and instances?
5.05 Scheduling & Tagging Do all appropriate Shared Ensure that all schedulable parameters are exporting data
Parameters schedule and successfully into a project environment.
tag as intended? Consider the use of Project Parameters to add metadata to families
of a particular family category (Note: this data will schedule, but cannot
be used in tags).
E.g. A Yes/No parameter that schedules if a door is used for 'Interior'
or 'Exterior' use is best suited as an instance-based project parameter
within the project. This can be useful to sort & schedule interior doors
and exterior doors separately within the same door schedule.
6 NESTING QUESTION ANSWER

6.01 Minimize nesting Does the number of levels of Preferred Practice: maximum 1 level of nesting.
nesting exceed the It is recommended to avoid exceeding a maximum of 2 levels of
compliance limit? nesting where possible and practical to do so.
Note: Each level of nesting doubles the time it takes to edit a value
within the project file and dramatically affects file size.
6.02 Purging All Have all levels of nesting, It is suggested to purge all nested components that are used in the
and the host file, been host family. This applies to each level of nesting. E.g. If family 'A' is
purged? nested into 'B' and 'B' is nested into 'C' then each family (A, B and C)
must be purged.
If a nested family has not been purged before loading it into the host
family, then edit the nested component, purge, reload and overwrite
the nested component within the host family.
6.03 When to nest If nesting has been used in Nesting can be advantageous when building a family, if done wisely.
this family, is it justified? Refer to R2 Sections 14.02 to 14.06 for advice on when nesting is
appropriate and the impact of its use.
7 MATERIALS QUESTION ANSWER

7.01 Naming of Materials If materials have been Determining which of these is the most important is difficult, and is
created within the family, is for the most part, a subjective assessment.
the naming of those Refer to R2 Section 14.01 - Naming Tips (Good Nomenclature) for
materials compliant with more guidance.
standards?
ANZRS stipulates the use of underscores '_' as delimiters between

each descriptor (name part). Various descriptors may be required to
enable sufficiently accurate discovery of, and distinction between
Material Names. To achieve some level of consistency, the following
(hierarchical) order of the information should be followed:
Minimum required: Description, Keywords, Manufacturer, Keynote or

Mark values. Optional (as required): Manufacturer, Manufacturer's
Product Code, Primary Descriptor, Secondary Descriptor, Finish,
Finish Descriptor.
Example: Paint_Ceiling_White_Dulux_615-04912
7.02 Material parameter Has it been assigned? It is not a requirement to assign material parameters to every piece
of geometry. However it can be useful to allow users to edit and
manipulate the materials of the component easily - particularly for
Generic components.
Use element-specific names for material parameters, where deemed
appropriate. (E.g. Door_Leaf_Material, Door_Frame_Material,
Seat_Fabric_Material etc.)
Refer to C5, C6 and C7 for discipline-specific lists of ANZRS
approved Shared Parameters, which include some for material
assignment.

7.03 Material parameter Has it been assigned? Group all material parameter labels under 'Materials'
Name material labels clearly to allow users to evaluate quickly which
material parameter affects what geometry.
Nominate parameter settings, assigned as type or instance as
deemed appropriate by the content creator.
Tip: It is a nice trick to assign a white material colour to generic family
geometry rather than using the 'default' dark grey material that comes
standard in a family template. That way users don't have dark grey
components showing up in project views that are using shaded with
edges at the display setting.
7.04 Shared parameters for Do these materials need to Consider whether or not the user may need to schedule the materials
scheduling schedule? that are being selected to control the family appearance, and whether
or not the material name may require a shorter 'proxy' name/reference
(due to the potentially lengthy structure of the actual material name).
Avoid creating two material labels (one being a data-only label that is
separate from the material geometry label). This could cause incorrect
scheduling to occur.
Refer to C5, C6 and C7 for discipline-specific lists of ANZRS
approved Shared Parameters, which include some for material
assignment.
8 OTHER QUESTION ANSWER

8.01 Tagging & Keynoting Have tagging or keynoting This is not a compliance requirement, however users may benefit
values been added? from considered data being entered. Do not add everything simply
because it has fields available.
Consider the relevance of the data pre-populated within the family,
based on its category, type, purpose or recipients (e.g. Client).
8.02 Discipline-specific Have discipline-specific MEP - Are connectors required, and if so, have they been added, and
Requirements data/elements been added to are they oriented correctly? Refer C4s Sections 4.02 (and 11.03)
families, where appropriate, Flow Direction for more information.
to ensure cross-discipline Structure - Have the material assignments and identity information
compatibility? (concrete/wood/steel etc.) been correctly applied?
Refer R2,, C2s,, C3s and C4s for more g p p
guidance on discipline-specific
requirements.
NOTES
REQUEST FOR INDUSTRY ASSISTANCE: We need more Industry feedback to improve this list and to better explain issues to be

REVIT FAMILY CREATION PACK - REFERENCE R2
Thisdocumentisintendedtoserveasalistofrecommendedbestpracticesthattieintothe
compliancesectionoftheANZRSFamilyCompliancePack.Forminimumcompliance
requirementsrefertoformC1s.ForAdvancedFeaturesrefertoFormR1s.Thisdocument
coversmanyofthetips,tricksandbestpracticesthathaveproventoworkwellwhen
creatinggoodqualitycontent.
BEST PRACTICES, TIPS AND TRICKS Version 3 [01-2012]
Many of the items listed below are not compliance requirements but are habits, that if embraced, will make a remarkable difference to the
stability and longevity of your content. You will also find that adopting many of these disciplines will save you time and reduce the effort
required to repair, edit or refine your components. Where a topic has extensive points to consider, we have made reference to the most
important points on a given topic in the C1s or R1s and elaborated further in this document. This document should not be referred to
exclusively as many of the important compliance requirements have not been duplicated here.
A
1.01 Abbreviations w or W = Width (Measured from the left to right face of an object.)
(Approved) Avoid using 'length' to define a width measurement.
d or D = Depth (Measured from the front to back face of an object.)
Avoid using 'length' to define a depth measurement.
h or H = Height (Measured from the bottom to top face of an object.)
t or T = Thickness (Measured from the front to back face of an object.)
l or L = Litres (Caps) (Note: Lower case 'l' can be confused for '1'.)
w_ = with E.g. 'SNGL Hinged Door w_sidelight'
wo_ = without E.g. 'Conference chair_wo_arms'
1.02 Annotation DO:

(Do's & Don'ts) Create text that is usable no matter what the scale of the view
.
1.03 Annotation in families Annotations within families come in two ways: One being 'Annotation Text' and the other being
'Annotation Label' (refer R2 Section 1.04 - Annotation Labels)
Annotation Text
This is a text note that gets added to a view of the family
family. The best use of text in a family is when
creating an Annotation Symbol.
Warning:
Remember when using annotation text in component, text remains the same size irrespective of
the view scale.
1.04 Annotation Labels Annotation Labels:

Annotation labels can only reside in Annotation families. Similar to other labels, an annotation
label reads the parameters within the family.
Annotation labels do not recognise Shared Parameters
1.05 Annotation Symbols Annotation Symbols are created to nest into model families as a 2D representation of the 3D
(Nested Tagging) model. Refer R2 Section 14.02 (and beyond) for Family Nesting. This does not have to appear
as the actual model as a Detail Component may, but more as a tag that identifies the element.
This can be text or the symbol that conforms to the relevant discipline, e.g. a Fire Extinguisher
symbol.
B
2.01 No Listing.
C
3.01 CAD based content in 2D Families
families (e.g. DWG/DGN Families containing CAD-based import instances (DWG/DGN) are not ANZRS compliant. Where
imports) CAD-based imports are used to generate 2D geometry during family authoring, Revit linework
must replace the CAD-based linework.
There are two ways of achieving this:
1. By exploding and reassigning the elements' subcategories, line styles and line patterns, or;
2. By tracing the elements with new Revit-native linework (and removal of the CAD-based import
instance(s) upon completion.
3D Families
3D CAD-based import instances may be required in some families for 3D visualisation purposes
(e.g. trees, planting, vehicles, entourage etc.). While authors are free to make such families, they
do not meet the minimum compliance requirements for ANZRS.
Best practice would suggest that if the 3D geometry can be made with Revit-native geometry, then
it should be. Moreover, such families (whether ANZRS compliant or not) should contain 2D Revit-
native geometry (symbolic lines, masking regions, detail components etc.) in plans, elevations
( d sections,
(and ti where
h th family
the f il category
t is
i cuttable).
tt bl )
ANZRS_R2_BEST PRACTICES LIST, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG 1/13

3.02 Cuttable Family Some family categories permit cut representation of the family, while others do not: termed
Categories 'cuttable' and 'non-cuttable' respectively. Elements within cuttable families may be set to be visible
only when the family is cut. This is useful for illustrating the assembly or inner workings of a
family where it is relevant and appropriate to do so.
Refer to the Revit Help Menu (or "List of Compliant Subcategories") for a list of cuttable and
non-cuttable family categories.
Symbolic linework within cuttable families can be assigned to any subcategory, and in either a
Cut style or a Projection style. The lineweight of this linework can be determined within the
family's and/or project model's Object Styles. See next row for more information.
3.03 Cuttable Family Items that are shown cut are typically assigned a heavier lineweight. The inability to assign a cut
Categories lineweight to any particular category indicates that the category is non-cuttable.
Refer to the Revit Help Menu for the latest list of cuttable and non-cuttable family categories.
3.04 Categories Definition OmniClass classification is the suggested method to breaking down what category content
belongs to. Using this method will introduce consistency and less room for placing content into
two different categories.
OmniClass numbers can be found in the Family Category and Parameters Dialogue box in the
Family Parameters section.
D
4.01 Detail Components Creating Detail Components (that are limited to 2 dimensions) can be a handy way of creating
(General) families quickly. However, the apparent speed of creating 2D elements may be offset or negated
by the speed of making changes and adding elements that are propagated through 3 dimensions.
Without the coordination across all three spatial dimensions, there's little or no advantage to using
Revit over any 2D CAD package. When creating Detail Components you need to consider the
purpose you are creating them for. There is no point creating a family built from 2D linework if
you intend to make good use of other model data. Moreover, Detail Components cannot be
scheduled, whereas model elements can.
4.02 Detail Components Items to consider when producing 2D Detail Components for elevation views of 3D components:
(In Elevation Views) Display of detail elements (such as masking regions, Detail Components, symbolic lines etc.) can
be problematic if the family containing these elements is not oriented perpendicular to the view
within the project. Refer to R2 Section 19.07 - Symbolic Lines (General) for more information
on display of elements relative to view direction, as this applies to any detail elements within a
y
family.
4.03 Detail Components When creating a fairly detailed or geometrically complex family in 3D with solid forms, you may
(In Plan Views) wish to use a Detail Component family (limited to 2D)(rather than the model), to symbolically
represent the object. Often this symbolic view is used for plan representation. Refer to R2
Section 13.03 - Masking Regions (Visibility Control) for additional information regarding
controlling symbolic representation.
4.04 Detail Components When creating the Detail Component families it is extremely important to have the origin
(Origin Points) determined based on common or standard documentation processes. For example, a Detail
Component of a brick course profile should be set to one side's bottom corner, to align with the
top side of whatever it rests on.
4.05 Detail Components Consider making all of your nested Detail Components as Shared families (by changing the
(Shared Nested) family's Shared (yes/no) parameter). This will help when adding them into line-based Detail
Components and other detailed family components.
4.06 Detail Components When creating Detail Component families (that are to be nested), think carefully about the family it
(Tips) will be nested into. For example, if you are creating a window sill detail, think about the
subcategories that would be useful. It is good practice to use consistent subcategories between
the 3D family and any required nested Detail Components.
Reference Planes
Reference planes in Detail Components will drive the form and size of your detail so it can be
used for multiple different sizes.
Ensure you use Reference Planes and set their Is Reference parameter value to Strong if you
intend to dimension to the reference.
Remember circular or curved objects are very difficult to dimension to so adding Reference
Planes to coincide with quadrants of curves will assist dramatically during documentation.
4.07 Detail Items Detail Items are a 2D representation of an object, hosted by the view and/or file in which they
reside. The size of these relates directly to the model (much like Model Fill Patterns). If a 2D
representation of a 3D object is required (such as a plan representation of a complex object) it
may be best to create it first as a Detail Component and nest it into the 3D component and link its
parameter values as required.
Refer to R2 Sections 14.02 to 14.06 for more information on Nesting.

4.08 Discipline-specific See Discipline-Specific Spreadsheet C2
(Architectural
Requirements)

(Structural
Requirements)
(MEP Requirements)
E
5.01 No Listing.
F
6.01 Family Category If you import a new family into a Project File without checking the Family Category and
(Changing Category) Parameters, you may have imported these subcategories into the project under the wrong Family
Pitfall : Category. See next row for more information.
Custom subcategories
Removing unwanted subcategories from the family editor:

When reassigning a Family Category, it will appear to remove all custom subcategories from the
Family Editor. However, when loading the family into the project, the (previous and new)
subcategories will both been loaded and assigned to the respective Family Categories.
Therefore it is very important that you remove all custom subcategories within the Family Editor
before changing the Family Category and Subcategory. If an error has occurred, remove previous
custom subcategories, then change family category and re-create new custom subcategories and
reassign to geometry and linework within the family. See R2 - Section 6.02 (below) for additional
pitfall to check for.
6.02 Family Category Inbuilt intelligence won't always be preserved when the Family Category is changed.
(Changing Category) Be aware that changing a Family category does not mean that all intelligence associated with the
Pitfall: preferred family template type will automatically be added in. While subcategories and
Inbuilt intelligence parameters may be added, physical elements such as host elements and reference planes won't
be added to the family - which may be critical for the family to perform as required.
Solution:
Begin with the correct and intended family category template wherever possible, to avoid these
pitfalls.
6.03 Family Name Defined convention:

Convention <Functional Type>_<Subtype>_<Manufacturer>_<Descriptor1>
(Compliance The Functional Type field is designed to hold the highest level of family information, in terms of
Requirements) purpose e.g. Door, Window, Furniture, Utilities etc.
The Functional Type field has nothing to do with the Family Subcategory, but should be used to
help web users to find a component easily in an on-line store through a site search browser.
6.03 Family Name For example, a door family must have a Functional Type of 'Door' even though it applies to a
Convention system component placement tool option within the Revit Project environment e.g.
(Compliance Door_Sliding_6Panel.rfa
Requirements) Inclusion of the functional type in all cases is better for overall consistency. Exceptions for
continued.. specific software features or categories create confusion and may only apply for a limited time.
Moreover, family files found outside of Revit are more recognizable (for what they are) by their
filename.
The Subtype field holds the next logical level of information that distinguishes this family type
from another e.g. Sliding Doors vs., Pivot Door etc.
Avoid Manufacturer name or model name if component represents a generic object type.
All names and parameter labels must be in English.
E.g. Window_DoubleHung_Acme_Tilting_SashClad,
Column_Baseplate_Generic_2DPlan,
Plant_Chiller_AirCooled_Generic
6.04 Family Name DO:

(Do's & Don'ts) Read the Revit Model Content Style Guidelines (Section 2.3) and comply with it wherever
possible. See R2 - Section 18.06 - Excerpt of RMCSG Section 2.3 in this document.
Be consistent with your family's file naming, whatever system you employ.
Charge a diligent person with the responsibility of ensuring your naming standards are followed
(within each individual organization).
Check your spelling and syntax. Simple spelling errors and inconsistent application of your
system may cause trouble later.
Distinguish any generic content from BPM-specific content, e.g. include the word 'Generic' (or
something equivalent) in the family name, as this will assist in future substitution (of generic items
to more specific items) as and when the need arises.

DON'T:
Use spaces, dots or symbols within the family name (other than underscores '_' and/or dashes '-
', but use them consistently).
6.05 Family Name ANZRS vs. RMCSG

(RMCSG Comparison) The Revit Model Content Style Guidelines v2 (RMCSG) largely subscribes to our prescribed
convention, however we would make the following observations:
Where the RMCSG recommends NOT including the category of an object at the start of a family
name, this may make navigation more difficult (using the Type Selector) until further UI
enhancements are implemented into the product. Including the category also permits easier
selection and filtering of elements by category when navigating Revit models in Autodesk
Navisworks.
Where the RMCSG recommends using dashes between name parts, the use of hyphenated
words would cause confusion and undermine the naming system. We therefore would
recommend the use of the underscore '_', an alternative delimiter.
Where the RMCSG recommends using underscores between words within name parts, we
recommend using no delimiter, i.e. to use CamelCase with no spaces (name parts are visually
identified by each having a capital letter).
Refer to R2 Section 18.06 - Excerpt of RMCSG Section 2.3 in this document to view excerpt
copy of Revit Model Style Guidelines, for comparison.
6.06 Filled Regions Filled Regions can only be created within Annotation families and Detail Component families.
(General) While Detail Components are 2D elements, they can be hosted by a 3D workplane in a 3D
family. They also allow you to use both Model and Drafting Patterns. Annotation families permit
only the use of Drafting Patterns.
6.07 Filled Regions DO:

(Do's and Don'ts) Create Filled Regions from out of the box patterns, where possible. If using a custom pattern
file, ensure that the 'pat' file is issued with the .RFA file to ensure it can be manipulated by users if
necessary.
DON'T:
Create 'Solid White' Filled Regions to obscure elements beneath. This mimics the purpose of a
Masking Region and has been known to cause visual conflicts when printing. See R2 Sections
13.01 to 13.03 for more information on Masking Regions.
6.08 Flip
p Controls Flip
p controls (arrows)
( ) are used in a project
p j environment to changeg the orientation of a selected
(General) element. You can dictate how the family will behave based on the flip control(s) added to the
family.
Note:
Work plane-based families will flip about their host workplane.
Some family templates automatically have flip controls embedded in the template file, based on
the family category. These default flip controls cannot be removed completely from the family. (If
you delete them in the plan view, they may still be in the elevation views). This can be limiting,
since you may not always want users to have the ability to flip certain objects. There is currently
no way to remove these in all views.
6.09 Flip Controls Single flip controls rotate a family by 180, irrespective of whether the control is oriented
(Control Options) vertically or horizontally.
Double flip controls mirror the family across the origin-defining Reference Plane that runs
perpendicular to the direction of the flip control.
G
7.01 No Listing.
H
8.01 No Listing.
I
9.01 No Listing.
J
10.01 No Listing.
K
11.01 No Listing.

L
12.01 Line-based Families Detail Components
Revit allows you to create a Detail Component based on the length between two user-defined
points. This type of family is also known as a '2-point pick', and can be great for creating
extendable families like the detailing of plasterboard. The one thing to remember is each end is
fixed and the elements contained within those ends are what extend. Another example would be a
detailed door jamb. Either jamb is shown and the door panel is the element that extends.
Check whether your Repeating Detail families would perform better (or be more useful) as a line-
based Detail Component.
When nesting (regular) Detail Components into a line-based Detail Component, ensure that you
lock the nested elements to the appropriate reference geometry (usually the Centre(Front/Back)
reference plane).
Generic Models
Metric Generic Model line based families are for the 3D extendable families. These are great for
items like cupboards and benches. If you write in an array for a carcass of a singular cupboard,
this can array across the entire length of the 2-point pick.
M
13.01 Masking Regions DO:
(Do's & Don'ts) Ensure you set masking regions to 'Draw in Foreground' (wherever applicable).
DON'T:
Add the boundaries of Masking Region on the Subcategory, unless it's required by the
performance criteria of the family. Remember that if you attach them to the Category it will be
turned off with the entire category which makes them easier to manage.
13.02 Masking Regions Masking Regions are added to families to hide 3D model elements within a project environment
(Tips) or complex geometry within the Family Editor.
When adding Masking Regions to the Foreground, think about how the family will interact with
other families. If a chair needs to be shown under the desk ensure the Masking region isn't ticked
as '...in foreground'. Refer R2 Section 13.03 - Masking Regions (Visibility Control), next row,
for more information on display order of Masking Regions.
13.03 Masking Regions Masking regions are typically required to obscure other elements that may appear beneath the
(Visibility Control) family (e.g. colour fills, or 'lower' objects). While detail elements in projects are usually hosted
only by the view in which they exist, in families they can be hosted by reference planes. Therefore
masking regions should be hosted to reference planes, situated appropriately (e.g. in height)
within 3D families. This ensures that the correct display order is achieved.
For example, a masking region used to symbolically display a chair (in plan) should be hosted to
a reference plane that sits at the top of the chair.
Similarly, a masking region used for the same purpose in a table or desk family should be
hosted to a reference plane that defines the top-most surface, so that lower objects (such as
chairs) placed under the table are appropriately 'covered'. This helps avoid display conflicts
between the two objects in projects. This also applies where 'lower' elements are nested into
'higher' elements, and vice versa. Refer to "C4s Section 2.02 Masking Regions" to see
ramifications that masking regions can have on MEP content.
13.04 Material Naming Keep material naming as simple as practically possible, and above all, consistent.
(Naming Convention) Determining which of these is the most important is difficult, and is for the most part, a subjective
assessment.
ANZRS stipulates the use of underscores '_' as delimiters between each descriptor (name part).
Various descriptors may be required to enable sufficiently accurate discovery of, and distinction
between Material Names. To achieve some level of consistency, the following (hierarchical) order
of the information should be followed:
Minimum required: Description, Keywords, Manufacturer, Keynote or Mark values. Optional (as
required): Manufacturer, Manufacturer's Product Code, Primary Descriptor, Secondary Descriptor,
Finish, Finish Descriptor.
Example: Paint_Ceiling_White_Dulux_615-04912
13.05 Material Naming Determining which of these is the most important is difficult, and is for the most part, a subjective
(General comments) assessment. For architectural purposes, the application may be important, whereas for a quantity
surveyor or subcontractor, the manufacturer and manufacturer's code may be more important. For
recognition and distinction, the precise order of these matters little. However, it may have more
impact on navigation (given that material names are sorted alphabetically). During early work on a
design intent model, some information such as the manufacturer and precise finish information
may not be known.

13.05 Material Naming Generic materials are often used as placeholders, which would permit more detailed information
(continued) to be added as it becomes known.
For this reason, a simplified system may suffice, which may either evolve into something more
detailed, or be switched at a particular point in time (e.g. when a decision has been made).
The question is: what level of detail is appropriate in the material selection at a given stage of a
project's life cycle?
The simple rule-of-thumb is: low(er) detail early; high(er) detail later.
13.06 Material Naming When assigning classes to materials, be aware that what you assign may be overridden if/when
(Gotchas) you assign a Render Appearance to the material.
If you are using these custom classes and naming conventions, note that various materials may
tend to persistently appear in your projects. Most of these come from families, while some are
'hard-coded'. In 2012 these can be purged.
Dimensional information may be required to differentiate the material from something else that is
similar. Ensure the units subscribe to local standards, and remember that direction and alignment
can be adjusted for model fill patterns (applied as surface patterns).
13.07 Material Use It is considered good practice to ensure materials can be applied to all content quickly. This can
(Tips) be accomplished by assigning a material to the subcategory in the Object Styles dialog. When
more specificity is required (e.g. in Interiors work), the content may need to be assigned a material
unique to that object or element. By assigning a material parameter to geometric forms within
families, it is possible to use both methods being able to assign materials throughout the project
per subcategory, or by components material parameters (whether type or instance parameters).
13.08 Multiple Types It is better to plan ahead and to take time to evaluate whether several variations of an object
(Splitting families) should be created using (aka 'split across') more than one family. Whilst it may require the user to
load multiple families (i.e. compared to one)(usually, but not always adding more file size to the
project) the benefits still remain:
Learning to use and manipulate the family is simplified.
It is apparent to the users what their choices are, when navigating the component library.
Simpler families are often more robust, and simpler to edit on future occasions.
13.09 Multiple Types E.g. A stacking door family with an array for panel number could become quite complex if it
(Splitting families) includes both open and closed door configurations. In this case it can be advantageous to create
An example a prototype door and use it (when fully tested) to spawn variations - one for each number of leaves
p
in the door. Given the complexityy of some stackingg doors, as an example,
p it could be quite
q
feasible to have a six panel stacking door family and a separate 8 panel stacking door family. This
would eliminate the need to use arrays and complex formulae.
N
14.01 Naming Tips Any good nomenclature should exhibit the following characteristics:
(Good Nomenclature) It should be structured consistently
It should be as simple as it can be (while maintaining the required performance). Ideally, the
simpler it is, the easier it will be to use, yet (a) it should be sufficiently prescriptive, and (b) it
should be structured in an intuitive way.
The following characteristics should apply to family file naming and material naming:
Hierarchical ordering of information (i.e. from most important to least)
Extensible (so it can be applied to simple and more detailed applications)
Flexible (so it can be used for every application)
14.02 Nesting & Family Brief Some categories or disciplines require nesting to be used (e.g. Electrical), making it unavoidable
(When to nest) on some occasions. For example, electrical fixtures typically require nested detail components to
symbolically display the actual fixture in plan views; planting families use nesting to permit the
scaling behaviour of base geometry required.
14.03 Nesting & Hosted It can be appropriate to nest families when attempting to create a hosted component from a non-
families hosted component.
(When to nest) Due to some limitations with the use of hosted families (especially where hosts and hosted
elements may exist in separate files), the use of non-hosted families is often preferential. In
addition, to create a hosted version a non-hosted family requires only that the non-hosted version
is placed into a hosted family template (of the same category). Note that some parameters may
have to be linked (aka 'daisy-chained') between host family and nested family.
14.04 Nesting for complex It can be appropriate to nest families when the family is simply too complex to build all of it in one
families file.
(When to nest) Within Revit's family editor, there is still no way to 'properly' hide an element or type (which can be
very frustrating!) as the geometry turns gray instead of invisible. Where families have several
types (particularly those that vary considerably), nesting of families allows greater visibility control.
There is a point where only so many reference planes and parameters can exist within a single
family, and still be useful and decipherable!

14.05 Nesting vs. Groups It can be appropriate to nest families when its a better alternative than using Model Groups.
(When to nest) The performance impact of using model groups and nested families negatively impacts
performance. Sometimes using nested families will have less of an impact on performance than
using groups, e.g. when assembling a collection of objects such as a table and chairs. If you're
unsure about which is the better choice, test each method in a new file, and multiply the object by
10000 times. Then try to work within each file and observe the differences in performance (e.g.
zoom, pan, orbit, edit, save and re-open...)
14.06 Nesting File size

(Impacts to consider) Nesting can dramatically increase a familys file size. A family's file size is added to the project's
file size whenever a family is loaded into the project. It follows then that larger families have a
commensurate impact on a project's file size.
14.06 Nesting Processing speed

(Impacts to consider) Nesting of families also impacts the speed by which changes can be made (processed) to a family
within the project. Based on simple performance testing, the following findings have been
observed:
For 1 level of nesting, the processing speed is roughly twice as long
For 2 levels of nesting, the processing speed is roughly three times as long to apply changed
parameter values to a family within the project environment.
O
15.01 Origin Locations Each Reference Plane has a Defines Origin parameter, which may be on or off. Where two or
more Reference Planes (that each have this parameter enabled) intersect, the family's origin is
located.
Some Structural Families do not respond well to having such Reference Planes moved within the
family. It is best to re-assign the Reference Planes' Defines Origin parameter where required.
P
16.01 Parameter Naming Syntax is CamelCase - applying a capital to every word within the Parameter's Name, without
(Compliance spaces.
requirements) Naming of parameters in nested files
Re-save and rename any nested components that were once shared by other families if the
changes made could affect other hosts sharing the same original nested family.
Some content creators add a prefix of "X_" to all nested family names to ensure users do not
employ nested components as stand-alone families in the project environment. This is
encouraged but not mandatory for compliance.
A chair family may be used on its own or as part of a table-and-chairs family. Therefore it is
noted that renaming is not always necessary.
Refer to R2 Section 14.01 - Naming Tips (Good Nomenclature) for more information.
16.02 Parameter Naming Use the compliance, predefined Shared Parameters (See C5, C6 and C7 and associated Shared
(Compliance Parameter files) that have been included in this package to ensure maximum interoperability
Requirement) between shared and/or sold content in accordance with these guidelines.
Using approved SPs Approved SPs must be used on all content where nominated data is required to schedule or tag.
16.03 Parameter Groups While it's common practice to group 'less important' or parameters whose values are driven
entirely by others (rendering them un-editable) under the Parameter Group 'Other', it is a good
way to keep them somewhat concealed or 'lightly' protected from Revit users. Those parameters
that are designed and intended to be changed should be sorted under more specific groups (such
as 'Dimensions' or 'Constraints'). The sorting of parameters among the parameter groups has no
bearing on their 'schedulability'.
16.04 Performance - Arrays Building relationships with arrayed elements in the family dramatically degrades performance -
(What affects how a especially if the array is a type-based parameter. You can expect that complex arrays (especially
family performs?) if they are controlled by type parameters) can delay edits to family types within a project
environment by 5-15 seconds or more (per edit) in a project environment, depending on the
number of instances of that family type populating the model.
16.05 Performance - Voids Use Voids in moderation and with clear consideration, but where possible use Solids instead.
(What affects how a Voids have a negative impact on the performance of families:
family performs?)
Parametric relationships between elements (e.g. Voids cutting Solids) reduces processing
speed. The more elements that need to interact and change, the greater the performance impact.
Voids contained within Arrays will compound the negative impact.
Voids also increase file size.

16.06 Performance - Other The following items also have a direct impact on performance of families:
(What affects how a Curved surfaces (especially multi-directional curved surfaces), unnecessary edges and vertices
family performs?) all impact on performance.
Interconnected parameter relationships can also affect family performance, however the value of
family functionality may be more important than performance in many cases.
Creation methodology affects performance. File size is not directly proportional to file
performance.
16.07 Performance Measures Measures of a family's performance:
(Brief requirements) Does it 'behave' as required?
Does it fulfil the purposes for which it was created?
Does it resemble or match a real-life version of itself (where appropriate)? Refer to "L3 Generic
vs. Specific"
16.08 Performance Measures Does the family flex properly?

(Editing a Family) Have all reasonable efforts been made to minimize the family's impact on performance of the
projects it goes into?
16.09 Performance Measures Project performance is usually determined by the amount of work the application must compute
(Impact in Project file) or calculate within the project environment when an edit to a family is made, or when regeneration
of the model is required. The time taken to achieve either of these is a quantitative measure of a
family's project performance. Generally speaking, the greater the computational demands, the
longer the time required.
File size can be important, and though it is not directly linked to performance, the greater the file
size, the greater the demand on computer memory to store and deal with the information. Broadly
speaking, smaller file size (of projects) yields better performance. However, if good content
creation methods are ignored it is possible to have a small project that performs poorly.
16.10 Performance Measures Does it provide for an accurate representation in accordance with its designated purpose (e.g.
(Output criteria) level of accuracy and detail, rendering appearance)?
16.11 Performance Do's DO:

(Things to do to Build families to minimum necessary file size, while preserving required functionality.
improve performance) Control, or limit the use of nested families/linked parameters to that which is necessary.
Make appropriate use of Detail Level visibility controls.
Compact the family before use.
Purge the family before use.
Make appropriate use of typey catalogues
g g the familyy in order to instead use
or consider splitting
multiple simpler versions.
Consider using symbolic lines and masking regions instead of geometry in plan views.
Remember that the family is a virtual representation of the real-life equivalent.
Maximise use of non-hosted families. These are better for use in Model Groups, which in turn,
improves performance.
Remember that 'Grouped and Associated' arrays impact performance (and should be used in
moderation).
16.12 Performance Don'ts DON'T:

(Things to avoid that Include non-native geometry (DWG/SAT/JPG etc.) where it can be avoided. Families
negatively affect comprising non-native geometry have been known to behave unpredictably when mirrored or
performance) flipped.
Use voids (if they can be avoided), as they can cause performance degradation: 'Avoid the Void!'
Nest more than one level deep. (Consider suitability, dependent on family)
16.13 Performance & Create components that are flexible enough to function as generic content, where appropriate.
Flexibility There is often great emphasis on BPM-specific content, but it can be a perfectly valid practice to
(Being smart in how you create a generic family that can be modified to suit a range of future and/or actual BPM content's
setup the family) parametric needs.
16.14 Planning How will it schedule? (Shared & Nested vs. only Nested)
(Behaviour & Features) How will it render? (Are high-end render materials necessary?)
How will it be dimensioned? (Name critical Reference Planes and assign Is Reference values)
16.15 Planning Aim: Ensure the content is fit for purpose and practical. Keep in mind the value in building a
(Initial family Set-up) component that is easy to understand. Content creators can save much time by building
components that are easy to edit and repair (consistency is key).
16.16 Planning Does it need to be a 2D or a 3D object? (You will need to use a model family (3D) template if
(Initial family Set-up) you want it to be able to be scheduled).
What family category (and therefore which family template) should the object be?
Will it be hosted or non-hosted? (Consider use with regard to linked project files).

16.17 Planning What parameters will require flexibility or should remain editable? (Which parameters should be
(Parameters & Nesting) Instance and which should be Type-based?).
Are formulas required to drive other parameters?
If nesting will be used, what parameters should be linked from nested family to host family?
How will the object interact with other elements in the model?
16.18 Planning Which Disciplines will need to use the component? (What functionality is required?). Refer to
(Functionality) Discipline Specific family requirement lists (within this pack) for help and ideas.
Where the origin will be? (How will object be placed and aligned in project?)
How much detail is really required and how will it be controlled? (i.e. through Visibility Settings ,
subcategories or symbolic line representation?)
How will the object interact with other elements in the model?
What scales will the object be viewed at?
16.19 Planning Does it need to be parametric? (Dimensional / Data).

(Types & Flexibility) Will it be easier to make variations of this component if it is built parametrically? (If so, what
parameters are required to accommodate this?).
Does it require multiple options? (Family types / Nesting).
Should it be one family, or multiple simpler families?
How many types are required? (Is it appropriate to split the family into multiple files, or use Type
Catalogs?)
Are types dramatically different? (What visibility controls will be required? Is splitting of the family
more appropriate?)
Q
17.01 No Listing.
R
18.01 Reference Planes Where possible, keep all reference planes outside of 'sketch mode' so that the relationships
(Tips) between the planes and other geometry is easy to see and understand. This enables easier
remedy of related problems. Having many reference planes outside of sketch mode can take a bit
of time to get used to, but it once you do, it can be very helpful to audit or repair a family if the
reference planes are kept neat.
Note also that Reference Planes (with dimensions applied to them) residing inside sketch mode
can also result in the family being over-constrained. Where Revit reports this problem, reconciling
or remedying this can be made more difficult if the Reference Planes and associated dimensions
are 'across spaces' (inside and outside of 'sketch mode').
Keep Reference planes tidy (re length and alignment) and only extending beyond the geometry
to which the reference plane is associated.
18.02 Reference Planes DO:

(Do List) Attach model geometry to 'datum' or 'reference' geometry, such as Reference Planes and
Reference Lines (by alignment and/or locking) to achieve optimum consistency and family
stability.
Set dimensions between Reference Planes (rather than physical geometry), i.e. the witness lines
of the dimensions should refer directly (i.e. 'testify') to the (existence of the) Reference Planes
Name important/key Reference Planes to maximise clarity during future editing. Where
possible, match the name of the Reference Plane to that of the Is Reference parameter value
(except where the Is Reference parameter is set to Weak Referenc e or Not a Reference ).
18.03 Reference Planes DON'T:

(Donts List) Constrain physical geometry to other physical geometry. Creating these constraints usually
occurs by aligning, then locking one object to another, or dimensioning between two objects, and
locking (or assigning a parameter to) the dimension. Generally, the widespread practice of
creating constraints between physical geometry contributes to instability in family behaviour.
Hide Reference planes (or override them to display as white!). Do use the Temporary
Hide/Isolate tool to hide annotation objects (by Category, of course), and then save the family
prior to exiting the file. This can help to achieve better control of family thumbnail images.
18.03 Reference Planes DON'T:

(Donts List) (continued) Create Reference planes inside 'sketch mode' where possible. It is best practice to create
reference planes outside of sketch mode and only then to assign sketch lines to the shared
reference planes in sketch mode.
This is for the following reasons:
(a) The same reference plane can be used to reference and control multiple elements if it is drawn
'outside' of sketch mode. (If it is drawn within a sketch, the reference plane will no longer be
visible once the sketch is completed.)
(b) It makes understanding component authoring logic much easier to understand when all the
constraints are visible.

18.04 Reference Planes Set the Is Reference parameter for all Reference planes in the family.
(Is Reference) Reference Planes that do not need to be referenced (e.g.: dimensioned to) within the project
environment should have the Is Reference parameters set to Not a Reference .
Primary, or important reference planes (that define key extents or locations within the family)
should have their Is Reference parameter set to Strong Reference , or one of the default options:
Front, Back, Left, Right, Top, Bottom, Centre(Front/Back), Centre(Left/Right),
Centre(Top/Bottom) .
18.05 Reference Planes Avoid presenting undesired 'instance-parameter-driving' blue arrows to users (visible when a
(Is Reference) family instance is selected in the project environment). To do so, make sure to set the Is
Pitfall - Instance labels Reference parameter of the associated reference planes to Not a Reference .
Pitfall: Aligning an object (in the project) using a reference plane within the family whose Is
Reference parameter is set to Strong Reference will cause the object to stretch, not move. This
would only apply if the reference plane is 'connected' to the rest of the model by an instance
parameter.
18.06 Section 18.06 - Excerpt This is an excerpt directly from the Revit Model Content Style Guide :
of RMCSG Section 2.3 Create unique names for each family. For example, a fixed window family and a fixed door family
cannot share the same name.
Use natural language to name the family. The family name should describe how the family is
identified in the real world (i.e., in catalogs, by manufacturer, etc.).
If possible, do not include the family category in the family name, unless the functional type is
the same as the category (e.g., window).
Use title casing (as with the title of a book) for family names, as they are case sensitive.
Keep file names as short as possible. Family names must display in dialogs and in the Type
Selector.
When adding optional descriptors to family file names, consider the order in which the
descriptors are listed to ensure that the family files display in the Project Browser in the most
logical and intuitive order.
Do not use spaces between words in file names. To separate words within a syntax element
(e.g., Manufacturer or Descriptor), use the underscore character (_).
If a hyphen () is used to include a performance range, enclose the range in parentheses, for
example, (230250_Ton).
If a type catalog is to be used with a family, name the type catalog (.txt file) with the same name
as the family. See section 2.10 for additional information.
S
19.01 Shared Parameter Refer to the Family creation Compliance Lists C1s Section 6.03 Parameter Naming for exact
Naming naming convention requirements.
(Compliance Refer to R2 Section 14.01 - Naming Tips (Good Nomenclature) for more information.
requirements) Refer to Approved Shared Parameter lists that form part of this pack. (C5, C6 and C7)
19.02 Shared Parameters Shared Parameters are used when the information in the family needs to be accessible in
(General) Schedules and Tags, or exported to external database (e.g. ODBC) formats.
Shared Parameters can also be a very useful tool to create consistency for company content,
even if the data is never needed for export or documentation purposes.
In order to achieve consistent and uniform content, consistent Shared Parameters should be
used for defining family data.
Shared Parameters with the same name but created separately will not be recognized by Revit
as the same parameter, as each is distinguished by its Globally Unique Identifier (GUID).
The ANZRS has created a base collection of Shared Parameters so that families can work
together regardless of origin and creator. Refer forms C5, C6 and C7 as well as the actual
Shared Parameter files that can be sourced directly as part of this document pack.
When the ANZRS Shared Parameter can link to existing parameters it is advised to link with a
formula. This way there will be no need to rename or re assign the parameter.
19.03 Shared Parameters The problems encountered when two shared parameters of the same name (but not of the same
(Pitfall) GUID) co-exist in a project are frustrating and difficult to resolve, especially for beginners. Being
able to identify which is which (and therefore being able to remove the unwanted one, or substitute
the use of one for another) is difficult to say the least. The use of multiple parameters in a single
project file within a schedule will result in multiple columns/fields where there should be only one.
19.04 Subcategories Simply put, the answer is YES, you can have too many subcategories!
(Can you have too many Several content sources using a variety of subcategory standards each = an endless number of
in a family?) subcategories being imported into projects.
The number of custom subcategories to a minimum). Ideally limit the number of custom
subcategories to ensure that View Templates in the project environment aren't crowded with too
many subcategories, originating from library content.

19.05 Subcategories Only add subcategories that will improve component functionality in the project environment.
(General rules) Only nominate sub categories that require independent (a) visibility (on/off) or (b) graphic control
in a project.
Example: On the occasion that various plumbing fixtures may need to cut a floor slab, this cutting
element may need to remain visible on penetration plans while display of the 'regular' physical
form is turned off.
Avoid using subcategories to control something that should be controlled within the elements
instance Visibility parameter instead.
Example: Subcategories for office furniture like 'seat', 'back' and 'arm rest' will be suitable as
'Seating_Fixed' or 'Seating_Freestanding', since it is never required to have one visible and the
others not - for all instances within a view. Chairs created either with arms or without arms would
be controlled by visibility control over the element (arm) rather than each element constituting its
own subcategory. Autodesk's own training material for family creation does not recognize the
impact of this, especially when applied this way to hundreds or thousands of families.
Read R2 Section 6.01 - Family Category (Changing Category) for more important information
about Family Categories and how they affect imported Subcategories.
19.06 Subcategories Here is an example of what happens when several families are imported into a Project file using
(Naming Pitfalls) similar (but not identical) subcategory names.
'Access Hatch' (Case sensitive - Title case)
'ACCESS_HATCH' (Same spelling, Case sensitive - All CAPS)
'Access Hatch' (With blank space at end of name, not visible in the Family Editor)
'Access Hatches' (Plural form, rather than singular)
'Access Panel' (Same meaning, but different name)
Impact to users of content
As you can imagine, this makes editing and creating View Templates a nightmare because it
becomes tedious and time consuming to work out which Subcategories belong to which families.
Read R2 Section 6.01 - Family Category (Changing Category) for more important information
about Family Categories and how they affect imported Subcategories.
19.07 Subcategories Avoid material names in subcategories.

(Naming requirements) In rare cases (e.g. Category: Doors, Subcategory: Glass), this is unavoidable as the subcategory
cannot be renamed (e.g. to Glazing). Subcategories should refer to general terms for elements.
Multiple references to materials would have a significant impact on the numbers of subcategories
without necessarily yielding a requisite value in functionality or productivity for the end user.
Underscores are used as delimiters between term/descriptors. Dashes as delimiters dont work
as they may be required by genuine hyphenated words.
Compliant: 'Swing_Dashed'
Non-compliant: 'Swing-Dashed
Spaces (single) shall be used to separate words within single terms/descriptors.

Compliant: Conveyor Systems
Non-compliant: ConveyorSystems
All names should be written in plural form. This does not mean that everything has to have an 's'
on the end (e.g. Hardware). None should have an apostrophe before an 's'.
Compliant: Frames, Appliances, Clearance Zones
Non-compliant: Equipments (plural form of 'Equipment' is 'Equipment')
Ensure all spelling is correct. Australian English is preferred, compared to U.S. English
Case format is Title Case capitals for every word.
Compliant: Door Frame, 'Swing_Elevation'
Non-compliant: Door frame or 'Swing elevation'
Subcategories typically need not be very specific - typically they are more general in what they
refer to.
Example: Robe Hooks may typically apply to only a few door families in a project, whilst
'Hardware' will likely be applicable to all doors, and could logically be used to control visibility and
display of something like a robe hook.
Compliant: Hardware
Non-compliant: Robe Hooks
19.08 Symbolic Lines Symbolic Lines are detail elements with a family, and are hosted by the view in which they reside.
(General) They are only visible in a project model when the family is seen in the corresponding view
direction. They are typically used to symbolise (indicate/represent) elements. This sort of
representation can be effective, particularly in Coarse Detail Level, where the detail of the
geometry of the family is unclear if it is not simplified.
TIPS:
Using Symbolic lines to represent a front or back elevation of an object will result in the same
appearance for both elevations (since they are parallel).
Symbolic Lines within families are only visible in projects where the project view's direction is
perpendicular to the view within the family that hosts the symbolic linework.

19.09 Symbolic Lines Symbolic Lines are also useful for those families that are non-cuttable.
(Cuttable Families) Refer R2 Section 3.02 to 3.03 for more information on Cuttable Family Categories.
Refer R2 Section 13.01 to 13.03 for more information on Masking Regions.
19.10 Symbolic Lines Use Symbolic lines when you cannot achieve what is needed in 3D, or where the linework is too
(Do's List) complex or detailed.
Remember to assign the Symbolic Line to a Detail Level, Yes/No Parameter, whether it is to be
shown only when cut, or to which subcategory it belongs.
Tip: Symbolic lines can also be used to add some detail to a crude geometric form (e.g. for a
plan representation) until the content creator has time to add more detail through geometry.
19.11 Symbols Symbols (Generic Annotation families) stay the same size, irrespective of view scale.
All symbols should conform to relevant discipline codes of practice and standards.
19.12 Symbols DO:

(Do's & Don'ts) Create the symbol or text to the actual printed size as they scale to the view.
All symbol families should conform to relevant discipline codes of practice and standards.
DON'T:
Don't share the annotation family as it will not be able to embed into a model family.
T
20.01 Type Name Type names do not lend themselves to standardization to the same extent as the families
themselves.
Type names need to sufficiently distinguish the unique nature of the type parameters that
generate the type itself, and this may require something more than the object's dimensions.
Type name may be best determined by both dimensions and text-based qualifiers, e.g.:
Filename = Plumbing_Shower_Generic_Corner.rfa
Family Type Name = 900w x 900d (with base)
Refer to R2 Section 1.01 - Abbreviations (Approved)
Refer to R2 Section 14.01 - Naming (Good Nomenclature)
20.02 Type Name - ANZRS vs. ANZRS position is that the Revit Model Content Style Guide v2 (RMCSG) currently places too
RMCSG much emphasis on dimensions solely determining the type names of a family.
It also warns against using abbreviated dimension suffixes to distinguish these dimensions.
Omitting the dimension qualifiers (W, D, H etc.) after the dimensions may lead to confusion and
lack of consistency (determining which value corresponds with which dimension), despite the best
of intentions. Where dimensions may not be required, any other descriptor(s) may be used. For
example, a bed object may have the following filename and type, e.g.:
Filename = Furniture_Bed_Generic.rfa,
Type Names = King/Queen/Double/Single
U
21.01 No Listing.
V
22.01 Visibility (By view type) VIEW TYPE VISIBILITY MENU
Explained This level of visibility control is different from visibility parameter control options. This menu
enables content creators to control the level of detail that can be display firstly by view type,
followed secondly by the view detail of the views.
SETTING OPTIONS EXPLAINED
Visibility of a family determines in which view the family displays and what it looks like in that
view. Typically, when an element is created by a family, the geometry of the element will change,
depending on the current view. In a plan view, you may want to see a 2D representation of the
element. In a 3D or elevation view, you may want a fully detailed 3D representation of the
element. You have the flexibility to display different levels of geometry.
22.02 Visibility (By view type) EXAMPLE:

Examples How to achieve good visibility control of window glazing in Plan views:
Make use of symbolic linework to communicate simplified plan or elevation representations. After
creation of 3D glazing geometry (which is typically created as an extrusion), prohibit it from being
visible in Plan views (for both Projection and Cut display) using the Visibility Settings for that
element. Use symbolic linework, set to the Glass[Cut] subcategory to represent glass in Plan
views (using a single line for each pane). This is better visibility control of geometry than hiding the
geometry completely in Coarse and Medium Detail Level (which would affect 3D views as well).
DOOR LEAF & SWING DIRECTION INDICATION
Turn off visibility of the door leaf in Plan view and use symbolic linework (using Panel[Cut]
subcategory) to represent the door panel in its open position in plan view. Take a similar approach
to show door swing direction (using the appropriate ANZRS-supplied subcategory (see Form C8:
Subcategories)) in elevation views.

22.03 Visibility (By view type) Geometry and its visibility at various Detail Levels should be considered carefully. To have parts
Guidelines of a component missing at Coarse or Medium Detail Level will confuse other users/model editors.
Geometry should only be prevented from being visible at Coarse or Medium Detail Level if it
should normally be displayed exclusively to that Detail Level (such as a basic 3D form that is
designed to be suggestive of the real component (such as a simple box for a dishwasher). In this
case, there should be additional 3D geometry (of greater detail) that is set to be visible at Medium
Detail Level. The same geometry could also be visible at Fine Detail Level, or it could be invisible
then, in lieu of yet more, higher-detail geometry visible at Fine Detail Level.
Geometry that appears to be missing because of bad application of this technique can create
headaches for downstream users.
All geometry should be visible in fine view.
22.04 Visibility - Detail Level When creating geometry you have the option to alter the Visibility Settings of the model or
(General) symbolic element. This allows you to achieve better control over levels of detail for your family.
In Structural families, Detail Levels are used slightly differently. When a Structural Framing
family is seen within the project environment in a view set to Coarse Detail Level, the families are
represented by Stick Symbols. However, more geometric detail is shown at Medium and Fine
Detail Levels.
If nesting Detail Component families, make sure you assign the visibility of the component to the
appropriate detail level.
22.05 Visibility - Coarse Detail Coarse Detail Level is typically used for low detail, low fidelity elements. Often, the geometry
visible at this Detail Level is only indicative of the element, and is typically seen in large-scale
views such as Site Plans, General Arrangement drawings etc. Geometry assigned to this level of
detail may include symbolic linework, detail elements (including Detail Components) or low-detail
3D forms.
22.06 Visibility - Medium Medium Detail Level is appropriate for medium-detail elements. Geometry assigned to this level
Detail of detail may include symbolic linework, detail elements (including Detail Components) or medium-
detail 3D forms. The accuracy and detail of the elements should be sufficient to serve it purpose
as either resembling the real object or passing for it. This level of detail is typically appropriate for
use in views of scale between 1:100 and 1:20.
22.07 Visibility - Fine Detail Fine Detail Level is typically used for highly detailed elements. As a rule-of-thumb, Fine Detail
Level is used for families that have geometry that must display at scales from 1:20 to 1:1.
W
23.01 No Listing.
X
24.01 No Listing.
Y
25.01 No Listing.
Z
26.01 No Listing.
NOTES
ANZRS website.

REVITFAMILYCREATIONPACK CHANGELOG Version 3 [01-2012]
Thisdocumentlistsallthechangesthathavebeenmadesincetheprevious versionof
ANZRS(Version2.,June2011)
Note:Thisdocumentdoesnothaveacodebecauseitdoesnotformpartofthe
officialANZRSpack.(Forreferencepurposesonly.)
REF.
REF
C1S VERSION 2 VERSION 3 COMMENTS

G
General
l Amended
A d d terminology
t i l to
t include
i l d
reference
f to
t other
th forms
f off reference
f
geometry namely reference lines and
geometry,
reference points
points.
3.01 Heading:
g Reference to Reference Heading
g of this item has been Heading g has been renamed to reduce
Planes renamed to 'Dimension to Reference confusion.
Elements '. Note: The term 'Reference Elements '
includes reference planes, reference lines
andd reference
f points.
i t
4.02 Use Reference planes
p as a Altered terminology
gy to include
framework to which geometry
g y is reference to other forms of reference
aligned and locked. geometry, namely reference lines and
reference points. Referred to as
'R f
'Reference Elements'
El t '
UUse 'R
'Reference
f Elements'
El t ' (reference
( f
planes
l are mostt commonly l used) d) as a
framework to which geometry is
aligned and locked
locked.
6.05 Modified Issue (currency format) 6.05 'Modified Issue (currency format)'
has been merged with 6.04 'Modified
I
Issue (date)'
(d t )'
6.06 6.06 Parametric Behaviour 6.05 Parametric Behaviour 6.06 has become 6.05
C2 / C2s VERSION 2 VERSION 3 COMMENTS
G
General
l Documentt code
D d change:
h The former
Th f C2 d
documentt (now
( C2s)
C2 )
Section C2 is now C2s serves as the accompanying summary
sheet to the new C2 Checklist
Checklist.
This document includes both compliance
and optional discipline-specific
requirements.
requirements
New The new C2 Checklist has been Discipline-specific
Discipline specific compliance checklist
checklist.
Document designed to accompany the C2s Only compliance requirements are listed in
Summary Sheet
Sheet. this checklist
checklist.
C3 / C3s VERSION 2 VERSION 3 COMMENTS

General Document code change: The former C3 document (now C3s)
Section C3 is now C3s serves as the accompanying summary
Checklist.
and optional discipline-specific
requirements.
checklist.
Summary Sheet
checklist.
10 01
10.01 The description and comments field
for 10
10.01
01 'Justification' has been
updated to improve the explanation of
this requirement
requirement.
C4/C4s VERSION 2 VERSION 3 COMMENTS

G
General
l Documentt code
D d change:
h The former
Th f C4 d
documentt (now
( C4s)
C4 )
S ti C4 iis now C4s
Section C4 serves as the
th accompanying i summary
Checklist.
and optional discipline
discipline-specific
specific
requirements.
requirements
checklist.
Summary Sheet
checklist.
ANZRS_CHANGELOG,VERSION3COPYRIGHTRESERVEDHTTP://WWW.ANZRS.ORGPG1/4
1.01 Heading:
g 'Annotation Symbols'
y Title changed
g from Annotation
Symbols to Nesting of Annotation
Symbols vs. Detail Components
1 01
1.01 Requirement: Requirement:
Use Generic Annotation template for Where filled regions are required for
all MEP 2D symbols in preference to symbolic representation:
the Detail Component template
template. Use a nested Generic Annotation
family for symbolic display of the
family where display size is set
relative to printed output (e.g. a GPO
or light switch), or;
Use a nested Detail Component
where the family's
y size is relative to
the model (e.g.
( g a 1200mm long g linear
light
g fixture))
1.01 Impact: Impact:
Ensures 2D symbols remain the Using a nested Generic Annotation
same size on sheet regardless of family will ensure that a 2D symbol
drawing
d a g scale.
sca e These
ese annotation
a otat o remains
e a s the t e same
sa e ssizeeo
on ssheet
eet
families can then be nested into the regardless
g of view scale. These
various physical
p y fitting
g families. annotation families can then be re-
used in other families. (e.g. other
single-point light fixtures).
Nested geometry is often required
b
because filled
fill d regions,
i which
hi h are
usefulf l for
f symbolic b li display
di l are nott
a ailable within
available ithin 3D families
families.
If filled regions are not required
required, and
the symbolic display of a family
should be determined relative to the
model symbolic linework may be
model,
sufficient without the use of nested
families at all.
8 01
8.01 Comments: Comments:
E g Load Classification: Power Uses
E.g. Load classification types include
the demand factors set in electrical HVAC Lighting
HVAC, Lighting, Motor
Motor, Other and
settings under Power
Power. Extend these Power
Power.
to suit the AUS/NZ standards
standards. Note: where the electrical connector's
connector s
Load Classification value is set as
'Power',
Power , the Demand factor's
factor s
calculation method settings may not
suit regional regulatory standards. In
such cases, this item is exempt from
ANZRS compliance
p until feature
changes
g in the software resolve this.
Impact:
p Allows for calculation of
maximum demands for each Load
Classification within the project. Also
i
incorporates
t Demand
D d Factors
F t applied
li d
t Load
to L d Classifications.
Cl ifi ti
8.01 Requirement:
q Requirement:
q
System
y types
yp are automaticallyy System
y types
yp are automaticallyy
specified
p from the connectors that the specified
p from the connectors that the
pipe/duct/conduit/cable tray are pipes or ducts are connected into.
connected into.
8 01
8.01 Comments:
Note: Cable trays and conduits do not
have a System Type parameter
parameter.
They can make use of the parameter
Service Type applied instead within
the project environment
environment.
C5 VERSION 2 VERSION 3 COMMENTS

Plumbing FlushingTechnology_ANZRS
FlushingTechnology ANZRS has This was necessary to match the MEP
Equipment been recreated as a new parameter Shared Parameters (C7)
(with new GUID)
Multiple
M lti l New Shared
N Sh d Parameter
P t added:
dd d
Categories CreatedByPhoneNo ANZRS
CreatedByPhoneNo_ANZRS
Multiple CreatedByURL_ANZRS(Text) Shared Parameter changed to URL

Categories
g superseded
p byy format.
CreatedByURL_ANZRS
y _ (URL)
( )
Parameter
P t Parameter
P t Groups
G within
ithi Shared
Sh d CamelCase
C lC and
d prefix
fi were never
G
Groups within
ithi P
Parametert file
fil are no longer
l prefixed
fi d required
i d
SP file with MEP
MEP, no longer in CamelCase
CamelCase,
and now in plural form consistently
consistently.
The parameter group
'MEPFireAlarmDivice' now renamed Typographical error fixed
to 'Fire Alarm Devices'
Electrical
El ti l LineCurrentPhase1_ANZRS
Li C tPh 1 ANZRS To be
T b more consistent
i t t with
ith existing
i ti
Equipment superseded by Revit terminology; applies only when
ApparentLoadPhase1_ANZRS power is 3
3-phase
phase
Electrical LineCurrentPhase2_ANZRS
LineCurrentPhase2 ANZRS To be more consistent with existing
ApparentLoadPhase2_ANZRS power is 3
3-phase
phase
Electrical LineCurrentPhase3_ANZRS
_ To be more consistent with existing
g
ApparentLoadPhase3_ANZRS power is 3-phase
Electrical ActivePower_ANZRS
ActivePower ANZRS superseded by To be more consistent with existing
Equipment ApparentLoad ANZRS
ApparentLoad_ANZRS Revit terminology; applies only when
power is single-phase
Electrical
El ti l New version
N i off BallastLoad_ANZRS
B ll tL d ANZRS BallastLoad_ANZRS
B ll tL d ANZRS unitit ttype should
h ld be
b
E i
Equipment t created,
t d with
ith new GUID W tt
Wattage, nott Number.
N b
Mechanical
ec a ca FCU(s)Served_ANZRS
CU(s)Se ed_ S replaced
ep aced with
t
Equipment
q p new parameter
p
FCU_s_Served_ANZRS
_ _ _ , in
accordance with C7 MEP SP tables
Multiple CreatedByURL_ANZRS(Text)
CreatedByURL ANZRS(Text) Shared Parameter changed to URL
Categories superseded by format
format.
CreatedByURL ANZRS (URL)
CreatedByURL_ANZRS
Plumbing
Pl bi Flushingtechnology_ANZRS
Fl hi t h l ANZRS replaced
l d Typographical
T hi l error fixed
fi d (lowercase
(l 'T'
E i
Equipmentt with
ith new parameter
t i 'Technology'.
in 'T h l ' Mismatched
Mi t h d with
ith itself
it lf
FlushingTechnology ANZRS , in
FlushingTechnology_ANZRS as it existed in other discipline
discipline-specific
specific
accordance with naming standard SP lists
lists.

Curtain Existing subcategory: Changed subcategories: Now written in plural form
Panels Threshold Thresholds
Detail Items Existing subcategory: Changed subcategories: Now written in plural form
Lightest Line Lightest Lines
Mechanical - New subcategory:
Equipment Boilers
Mechanical
M h i l - N
New subcategory:
b
E i
Equipment
t Chill d Beams
Chilled B
Equipment Chilled Water Sets
Equipment Condensing Units
E i
Equipment
t C
Cooling
li Towers
T
Equipment Variable Air Volume Terminals
Multiple CreatedByURL_ANZRS(Text)
CreatedByURL ANZRS(Text) Shared Parameter changed to URL
Categories superseded by format
format.
CreatedByURL ANZRS (URL)
CreatedByURL_ANZRS
G
General
l We note
W t that
th t some subcategories
b t i
('Clearance Zones') listed are not
directly useable
useable. This doesn't detract
from the performance or operations of
the software
software, so for the time being we
have retained them (possible version
and feature changes might make
them usable in the future).
R2 VERSION 2 VERSION 3 COMMENTS
6 03
6.03 - Added
Add d ffor clarity:
l it
I l i off the
Inclusion th functional
f ti l type
t in
i allll
cases is better for overall
consistency Exceptions for specific
consistency.
software features or categories create
confusion and may only apply for a
limited time
time. Moreover
Moreover, family files
found outside of Revit are more
recognizable (for what they are) by
their filename.
6.05 Removed: To be more consistent with R2 6
6.03
03
Where the RMCSG recommends not
using the category unless it is also
the same as the Functional Type
field, we recommend including the
category
catego yo
onlyy wheree e the
t e object
category
g y is not used/handled byy a
category-specific
g y p tool (e.g.
( g doors,
windows).
NOTES
REQUEST FOR INDUSTRY ASSISTANCE: We need more Industryy feedback to improve p this list and to better explain
p issues to be
It iis our vision

i i ththatt th
these proposedd standards
t d d will ill receive
i the
th promised
i d supportt from
f the
th dominant
d i t commercial
i l content
t t creation
ti companies
i iin
A t li New
Australia, N Zealand
Z l d as wellll as the
th Revit
R it user community. it
throughout Australia and New ZealandZealand. A content creator can only claim to provide ANZRS
ANZRS-compliant
compliant content if the compliance requirements
listed in this document are met on the respective components that they sell sell.
Refer to the Update Letter that is in the front section of this pack. It outlines other improvements to this ANZRS Pack Version 3.
Version 3 [01-2012]
END OF
PACK
CO-AUTHORS
MICHELLE VAN KOLCK (LOUW)
CHRIS NEEDHAM
BELINDA HODKINSON
WEBSITE & FEEDBACK

Email: feedback@anzrs.org
Website: www.anzrs.org

ANZRS V3 01-2012 Fullpack 4f1c1c896ade6

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ANZRS V3 01-2012 Fullpack 4f1c1c896ade6

Uploaded by

Copyright:

Available Formats

Version 3 [01-2012]

Michelle Van Kolck is known in the Revit community for her

Belinda is the BIM Development Manager at Sinclair Knight Merz. Her

Chris Needham is the owner and director of C3 Consulting Solutions,

ANZRS_ABOUT COMMITTEE & PROJECT, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG 2/3

Its been a mammoth effort, and not without the contributions of

The project has attracted interest globally.

Feedback was received from a number of contributors during the

The document pack constitutes:

Introduction and project contextual information

The Revit Content Model Style Guidelines produced by Autodesk

ANZRS addresses content standards for Autodesk Revit only. It

The committee is actively in dialog with other related parties and

ANZRS_ABOUT COMMITTEE & PROJECT, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG 3/3

WHATS NEW IN VERSION 3? Version 3 [01-2012]

pack became available on our website. <NextPage>

ANZRS_L0_UPDATE OF ANZRS PACK, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG. 1/2

2.0 Support and industry discussions

6.0 Do you want to become part of the ANZRS team?

7.0 Sponsorship and Funding

ANZRS_L0_UPDATE OF ANZRS PACK, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG. 2/2

LETTER OF INTRODUCTION Version 3 [01-2012]

ANZRS_L1_LETTER OF INTRODUCTION, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG. 1/5

2.0 REVIT MODEL CONTENT STYLE GUIDELINES

ANZRS_L1_LETTER OF INTRODUCTION, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG. 2/5

Good content is content that:

7.0 MEASURES OF SUCCESS

ANZRS_L1_LETTER OF INTRODUCTION, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG. 3/5

8.0 EXPRESSIONS OF VALUE

9.0 STATEMENT OF LIMITATIONS

10.0 FUTURE SCOPE

ANZRS_L1_LETTER OF INTRODUCTION, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG. 4/5

10.05 QUALITY CONTROL

ANZRS_L1_LETTER OF INTRODUCTION, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG. 5/5

HOW TO USE THIS PACK Version

1.0 BASIC CONCEPT OF PACK

2.0 DIAGRAM TO EXPLAIN DOCUMENTATION SET

3.0 DOCUMENTS CONTENT OUTLINED IN TABLE FORMAT

These are the introductory documents to this pack.

FORMS COMPLIANCE (ALL DISCIPLINES) C1

FORMS COMPLIANCE (DISCIPLINE SPECIFIC) C2 - C4

C2, C3 and C4 each set out discipline-specific requirements for Architecture/Interiors,

FORMS SHARED PARAMETERS (DISCIPLINE SPECIFIC) C5 C7

C8 is a table of Object Style Subcategories that, when incorporated by multiple content

FORMS CHECKLIST SUMMARY OF ADVANCED FEATURES (OPTIONAL) R1

FORMS SUMMARY OF GENERAL BEST PRACTICES ALL DISCIPLINES R2

GENERIC VS SPECIFIC Version 3 [01-2012]

1.0 UNDERSTANDING THE ISSUE

2.0 TARGET AUDIENCE

3.0 THE VALUE OF INFORMATION DURING THE DESIGN LIFE-CYCLE

Less resolution is required early; more resolution is required later

ANZRS_L3_GENERIC VS SPECIFIC, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG. 1/4

4.0 POTENTIAL CONFLICTS BETWEEN GENERIC CONTENT AND PRODUCT-SPECIFIC CONTENT

No. Title Generic Content Product-Specific Content

ANZRS_L3_GENERIC VS SPECIFIC, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG. 2/4

6.0 COMMON CHARACTERISTICS OF EACH TYPE OF CONTENT

No. Generic Content Building Product-specific Content Issues for Designers

ANZRS_L3_GENERIC VS SPECIFIC, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG. 3/4

No. Generic Content Building Product-specific Content Issues for Designers

To date, techniques used to reconcile this have included:

ANZRS_L3_GENERIC VS SPECIFIC, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG. 4/4

GLOSSARY OF TERMS Version3 3[12-2011]

1.0 GLOSSARY OF TERMS

ANZRS_L4_GLOSSARY OF TERMS, VERSION 3 COPYRIGHT RESERVED HTTP://WWW.ANZRS.ORG PG. 1/3