Revit is an Object Oriented Database, using numeric ‘handles’ to track data fields, and associate them to individual elements, via category definition. This invisible ‘handle’ is more important than the name of the parameter itself in correctly consolidating information. Whenever a parameter needs to extend beyond a single project file, the parameter needs to be a Shared Parameter, from an external master list, in order to establish the same handle across files. This includes project/annotation, as well as project/project. In other words: If you want to tag it, or want to pass it on to another project and have it show up correctly in a schedule, it must be a Shared Parameter.
The Shared Parameter master list:
Each project can be linked to an office wide Shared Parameter list. The path is preset in the Template, but may need to be mapped if the file is started without the template, or is from an outside source (manufacturer doors/windows, for instance). Please coordinate with your office BIM Coordinator/Manager to create new Shared Parameters. Loose management of this list can be very frustrating to the project teams, believe me!
____________________________________________________________________________
Example of using a shared parameter:
I may need to establish a “% Recycled Material” parameter for my casework families. I will need to schedule this info to effectively manage it in a project file, and I may want to be able to use filters or tags to quickly identify what elements meet a threshold criteria. Here’s the repercussions of using a non-shared vs shared parameter:
Limitations of using Non-Shared Parameters:
I can create the parameter as a Project Parameter directly in the project, perhaps by creating a new parameter in the casework schedule. I can now add the data from the manufacturer to the object easily. BUT – I can’t pass this family to another project and have it hold that data. Without a Shared Parameter, the family only has the data in the project environment. Once out of the project, that data field does not exist. I also cannot tag the casework with a custom tag that reports the data.
Benefits of using Shared Parameters:
Versatility and Consistency:
a) OFFICE-WIDE DATA: Load that parameter into both the casework family itself, and into a custom casework tag. Also load it into the project environment. Because they (family, tag, project) all received the parameter from a single source, they data knows that it is the same ‘bit’ of information. Because the family holds that data, I can load it into another project and the value stays with the object.
b) PROJECT SPECIFIC DATA: I can skip loading the shared parameter into the family, and only load it into the tag and the project environment. Saves me some time, and since my family represents a generic piece of casework, I don’t want that info to be permanently assigned to it, only assigned in the project. But using Shared Parameters gives me coordination through the custom tag, which can be a great efficiency tool when I want to quickly check the data across many instances of varied casework.
Pingback: Trackback