Okay, I don't really ♥ parameters, and I know you don't either. Lately we've had a lot of Ideate BIMLink customers asking us to fix their shared parameters by either merging duplicate values into a single parameter or by renaming them. While Ideate BIMLink can tackle both of these issues efficiently I thought it would make for a productive discussion to review how to avoid the problem in the first place. With this in mind, I headed to the East Bay User Group in January 2014 to tackle this issue head-on.
Some of the most common shared parameter problems surface quickly when we attempt to use content prepared for us by product manufacturers. Have you ever run into these head-scratchers?
Or this one?
These problems both relate to shared parameters and for reasons that I won't go into now are not surprising given that we are using manufacturer supplied content. Our goal for this article is to prevent this from happening within your own content in the first place.
This decision tree below shows our recommendations on how to determine whether your parameter needs to be shared or not. The risks of misusing shared parameters are great and can result in lots of wasted time, so refer to this diagram before you embark on your journey into shared parameter files.
One of the biggest misperceptions about shared parameters is that they are a requirement of a project simply because linked files are involved. This is not true. For example, if the goal is to have the parameter value appear in a schedule and the parameter in question is an instance-based parameter then the only reason you would need to have a shared parameter, is if the value will be displayed in a Tag or Title block. Note that elements such as Rooms, Spaces, Sheets, and Views are always instance-based and therefore would only ever need shared parameters if it needs to be displayed in the Title Block or within a Tag. The criteria for a parameter to work across multiple files are EITHER that it is a shared parameter OR that it's a project parameter with the same name and the same unit (text, length, etc).
Exceptions to this rule of thumb apply primarily to the issue of whether the parameter is desired to NOT apply to all families within that category. A classic example would be for those managing Electrical Equipment elements. This Revit category is far too broad. A PROJECT parameter such as "Transformer Width" would apply not only to transformers but also to any other family falling under the Electrical Equipment category, such as a the nurse call light family. In this scenario, a shared family parameter would be recommended to avoid this problem.
Hopefully this diagram will help you make an informed decision about your data structure and will help avoid the problems of duplicate shared parameters. I want to thank those in attendance at the East Bay User Group - it was a great discussion. Perhaps there are now a few who may also ♥ Revit Parameters.
Check out Part 2 of this topic: I ♥ Revit Parameters Part 2: The Shared Parameter File Path.
For in-depth consulting on organizing your data structure within Revit, contact [email protected].
About the Author
Glynnis Patterson, NCARB - Director of Software Development Glynnis is a Registered Architect and has worked with the BIM industry since 1998. A graduate of Carnegie Mellon University, she has worked as an architect, educator and construction site manager. Glynnis is currently the Director of Software Development Services at Ideate, Inc. and continues to work with AEC clients across the nation, developing, and implementing best practices solutions. In her spare time Glynnis does volunteer work and builds Lego projects. @GVPinNJ
Ideate Software