The Stuff Revit Legends Are Made Of
When I first began using Autodesk® Revit® over 10 years ago, my excitement over certain features and functionality was quickly dampened when I began looking into the legend tools provided in the software. It’s no secret that the legend tools in Revit are lacking, specifically for symbol legends so commonly used in engineering design. In those 10 years not much has changed. One can only assume further development is not planned in this area of the software.
Legends are an essential but often overlooked tool in construction documents. Perhaps it goes without saying, but legends provide explanation and information for the various symbols and visual elements in use on a project. When considering what approach to take with legends, a fundamental question is: can the legend be all-encompassing and generic or must it be project specific, accounting for elements in use in the project only? The former typically includes all possible symbols that might be used with a disclaimer indicating that not all symbols listed may be used in the project. This approach significantly reduces the time associated with editing legends that otherwise need to be updated as the project progresses and content is added or removed. But it isn’t the most elegant or relevant either.
At this point, regardless of whether or not a project specific legend is needed, the second question is: should the legend use parametric information from elements and families in the model? The answer to this question is the main pain point and the focus for the rest of this article.
If you answered "yes" to this second fundamental question, your decision is pretty well made for you already, but let’s play along. Revit has built-in legend tools for this purpose, but they leave a lot to be desired. To create this type of legend, from the Create panel in the View tab, access the Legend button. You will be prompted to give it a name and specify a scale. This same result can be achieved by right-clicking the Legends node in the Project Browser (Figure 1).
Figure 1
Similar to other views in Revit, you can also adjust the detail level and visibility graphics or assign a view template. Once created, to add families to the legend go to the Detail panel in the Annotate tab and select Legend Component (Figure 2). Alternatively, you can drag the desired family type from the Project Browser into the legend.
Figure 2
A feature unique to legends is that a drop-down of all content available in the model appears in the options bar, as well as a view type control and host length parameter (Figure 3).
Figure 3
Excitement quickly turns to frustration as you try to get your legend components for device categories (electrical fixtures, security devices, data devices, etc.) to display properly. Using this method, I would describe Revit legends as inflexible at best and useless at worst. It is common practice to use nested generic annotations in MEP devices. This effectively places a symbol while also placing the family and its geometry. Symbol visibility is then commonly controlled via the detail level of the view, usually in tandem with other visibility functionalities of the family.
The problem in a true Revit legend then becomes that the orientation of the family cannot be rotated, forcing this to be a function of how the family is built, which most likely is not desirable. (If any of your content is face-based, hiding the geometry in this type of legend is that much more complicated.) This all but requires the use of generic annotations or detail components in the legend to represent the content in the model, and you are no longer using live model information.
Second, even if placement and orientation of legend components had no issues, parameters of the elements placed in these legends cannot be tagged or otherwise accessed, so you are left to use text. Don’t be fooled! The tagging tools are available in the ribbon, seemingly inviting you to starting tagging components, but they are powerless in these legends.
Third, there is nothing to help with creation of a tabular format. This means any lines for rows and columns must be manually added if desired. If you have gone down this path and gotten this far, you might be wondering what you liked about this program in the first place.
These legends are not without their advantages, however. Model elements placed in a legend view are not “included” in the model. That is to say, they won’t also appear or be counted in schedules. Also, as true legends, the same legend can be placed on multiple sheets, unlike the limitation of all other views in Revit. Nice, but barely one step better than a drafting view of annotations, lines, and text.
If these solutions thus far are unacceptable, you might be wondering if there are any other options. The answer is yes, but they are workarounds. As such, there are some trade-offs to consider. The following solutions achieve a desired result, but make use of functionality in Revit that is not its intended purpose.
One such workaround that is fairly common is to use the phasing functionality of Revit to assist in making legends (Figure 4). Yes, that is as crazy as it sounds. I am not going to explain in detail this method because there are plenty of blog entries and forum posts covering this approach. But the main goal, having ruled out a true Revit legend, is to be able to access model and parameter information for use in a legend. The elements you want in a legend are placed in a “documentation” phase, past or future. This is done by creating the legend in a floor plan or similar. From here, tags can be used to display the desired parameter information. Finally, because these elements are being placed in their own phase, they can be kept separate from the rest of the model both in plans and in schedules.
Figure 4
A few drawbacks to this method are that separate phases just for this purpose must be used and maintained; users must be trained on their proper use. If lines are desired for the tabular format, they must be created (and adjusted) manually. And lastly, it does not respond automatically to elements being added or removed in the project. If only content in use in the project is desired in the legend, this must also be managed manually.
A second option is very similar to the above phasing method but uses design options instead (Figure 5). Again, the idea is to sequester the elements for the legend in a part of the model where visibility can be controlled in plan and schedules, but access to the parameter information is still possible. As with the phasing option, there are plenty of entries on the web outlining the process to help you decide what approach you may want to try.
Figure 5
This brings us to a last option: schedules. There are three main advantages to this approach. First, the symbol legend uses only model content in use. Second, parameter information is easily accessible. Third, schedules greatly assist in the standardization, formatting, and overall appearance of the legend.
A legend is basically a type schedule. Obviously, every instance of an element should not be represented so “itemize every instance” must be unchecked under sorting/grouping. Because it is a schedule it also responds to phasing and filtering to allow for multiple “legends” for specific phases or scope in a given project. As many parameters as are needed can be added for information display or just for filtering and sorting/grouping controls (Figure 6).
Figure 6
Finally, this approach also allows for either category-specific or multi-category schedules. Category specific can act as a built-in filter. For example, if I only want to show security devices in my legend I can do so by creating a schedule for that category only. No other Revit categories will be shown. The opposite is also possible. A multi-category schedule can be used to create a legend that spans more than one Revit category (Figure 7). Keep in mind these kinds of schedules behave a little differently. Make sure at least one shared parameter is available to all desired categories so the schedule will “see” the expected elements. From here, filtering out elements you don’t want to see can be achieved most easily using parameters for just this purpose.
Figure 7
Because we are still in the land of workarounds, this approach is not without its problems. A schedule can only report content in the model, so it is difficult to have a “starting” legend. If it isn’t in the model it can’t be in a component schedule, thus it can’t be in the legend. Also, we need more than just the information—we also need to display a graphical representation. How does a schedule do that?
Alas, again we are met with more decisions based on what we are trying to achieve, weighing the pros and cons. One approach is to create actual fonts in a font editor program that depict the symbols you are using. These font characters are entered into a parameter of your choosing that is used in the schedule. Voila! Your schedule is now showing symbols and information for live model content.
There are two main drawbacks to this approach. First, an entire font character library must be created for this purpose. Second, almost as important as the first, is that creating non-standard fonts creates its own problems. This font must be available on all users’ computers. This is poignant when sharing digital files with outside entities.
If creating fonts have such big drawbacks, what other options are left? Beginning with Revit 2015, images can now be associated with families as instance or type parameters. These images can then be used in a schedule. All the benefits of a schedule without the drawbacks of creating a font character library! We are almost there. All that is left to decide is which parameter to use: type or instance?
First let’s consider the type image parameter, which works well because we want an image to correspond with its type. The up-front work here is to create an image file that depicts all of your desired symbols. Once loaded, however, any content that is added to or removed from the model is automatically updated! Problem solved. We now have a legend that responds to model changes, can display parameter information associated with the elements, and has the formatting controls to help with standardization and appearance.
Figure 8
A few necessary considerations to keep in mind. Trial and error is required to get your images created and sized properly. Those experienced with image editing software will have no problem. Those less experienced soon will be! Once the trial and error is over and the correct size is determined, it is easy to make the bulk of a library without reinventing the wheel each time.
Figure 9
With everything this method has in its favor, it also is not without its disadvantages. First, this does require the somewhat duplicate work of creating an image file that equals the needed symbols. Substantially easier and more universal than creating fonts, it nonetheless takes additional time. But, since we are talking about standard legends, hopefully your symbols are not changing from project to project. And once created they can be reused.
A second drawback is that if the image does need to be edited or changed for whatever reason, it cannot be done in the project. The family must be opened in the family editor in order to change or reload the type image. Furthermore, if any changes are made in the family editor, not even affecting the type image, “overwrite parameters” must be selected when reloading the family back into the project (Figure 10). Autodesk admits this is a defect, but as of version 2019 it is not fixed. Not a deal breaker, but definitely something to keep in mind.
Figure 10
A third consideration is to understand how a schedule controls the image size. An image in a schedule is controlled by two basic methods: 1) column width of the image column; 2) row height image column. This, in combination with the size of your images, controls their size on the sheet and applies to the entire schedule.
With the first approach, images in a schedule scale proportionately as its column width is changed. Changing the width of other columns in the schedule does not affect the image. This is the default setting.
The second approach is to control row height. With the schedule selected on sheet, this is achieved by using the control in the ribbon. This allows for width changes to the image column without changing the size of the image. However, changing the row height of other parameter columns in the schedule (changing their column width) will change the image size in the image column. This approach effectively means that to avoid unintended changes to the image column, a specified maximum of text lines in a row must be honored at all times in the other parameter columns.
Figure 11
These two approaches are mutually exclusive and can’t be in use simultaneously. The best approach is probably to build your images to work with the default column width method. From here the specified row height method can still be utilized if changing the width of the image column is required for some reason. Starting with the specified row height approach forces you to stay with that approach.
There is a fourth negative to consider, which Autodesk also admits is a defect. If sorted by a parameter with identical values across families, a schedule does not know what to do with two different families that make use of the same type image. Sort by whatever parameter you want; the type image will not display in this scenario. Mostly a rare situation, it nevertheless has happened and forces you to address the problem by other inventive means.
In Figure 12, the top schedule is not itemized and sorting by description. The bottom schedule is itemized and also sorting by description. In the top schedule, notice the empty symbol column. Because the schedule is being sorted by the description parameter, which is identical in both families, the type image is not displayed. Interestingly, this same behavior also occurs if you sort by type image but do not itemize the schedule. It is as if the schedule treats the type image parameter as unique if it is from a different family even if it is the same image.
Figure 12
One more thing that is more of a consideration than a drawback. If exporting files to DWG is a common requirement, once exported, all the images will be exported as images and maintained as external references by AutoCAD®. They are not embedded in the DWG.
A concern I had when first implementing this approach was if the images loaded into the families would have a negative impact on model performance. I can pretty confidently say that it has not. Because the images are in the families, not the model itself, Revit does its normal magic of managing and referencing families, types, and their instances without bloating the model.
Despite these points, the type images approach has been our standard legend approach on all our projects for almost three years. Not without its problems, its benefits outweigh the woes. It does definitely lend itself to engineering trades where the majority of symbols are variations on a theme. The applicability of this approach may not be as well suited for non-MEP disciplines.
If the idea of creating an entire image library that matches your symbol library is too much to bear, there is another option that still takes advantage of schedules. This approach is a hybrid of sorts between the automatic nature of a type image schedule and the manual method of placing symbols.
First, create a blank image (Figure 13). This image is blank and contains no graphics or information. As with the type image method, some trial and error may be necessary to achieve the desired result. This image file is loaded into the model itself. Once in the model, it can be selected in the instance image parameter for each desired element in the “legend.” The key is to load this image file into the image parameter for all scheduled elements. This can easily be done by “collapsing” the schedule, filtering by a parameter that only returns one row, and loading the blank image file. A separate schedule devoted to just this purpose could be also be created to help manage adding this image as new elements are added. Why load a blank image into a schedule? It allows you to set the row height to something other than what the non-image parameters allow. With all of this in place, generic annotations, probably the same ones nested in your families, can be manually placed on the sheet in the legend with the corresponding family (Figure 14). As an aside, because these are native Revit elements, when exported to DWG, they are exported as native AutoCAD elements (the blank image file will be exported as a single image and referenced).
Figure 13
Comparing both finished products in Revit or PDF, the legends are nearly indistinguishable. Why not brush up on your image editing skills and take advantage of an intelligent legend?!
Figure 14
Figure 15
As with many things, the lower initial time investment up front of not having to create and load images into each family type translates into continued manual management of the legend that adds up over time. As content is added or removed, the content placed on the sheet must be moved accordingly.
Perhaps there are other ways of creating legends not covered here. If so, share with the community so we don’t all suffer in isolation! Perhaps a mixture of the above approaches will provide a solution for you. Sometimes creative thinking outside the box is required to find solutions and meet deadlines. Whatever the case, I hope this article has provided some ideas to help make your Revit legends legendary!
Nathan Mulder has more than 10 years of experience in the AEC industry. He is currently the BIM and CAD Manager for Guidepost Solutions, a global leader in investigations, compliance, and security consulting, offering design services for security, telecom, and technology systems. A Revit MEP Electrical Certified Professional, Nathan is always looking for ways to fully leverage software to improve the project design and management process. Contact him at mulder.nathan@gmail.com or on LinkedIn.
