The Review tab displays a list of pre-defined issues that are unique to Revit annotation elements. If the issue does not exist, given the Display, Sort by, Filter, or Search criteria, it will not be listed. See below for important details about each of these annotation issues. Have another Revit annotation problem that you’d like to add? Let us know!
Dimension strings can result in a zero value when the hosted element gets moved, typically by another user, after the dimension is created. Most often this happens when an align command is used. When the dimension string is a single dimension, you should delete the dimension. For multi-string dimensions you can move both witness lines (one is on top of the other) up and then back again to force the zero value to disappear while leaving the other segments intact.
In some instances the zero value segment is hidden in the view, often because the hosted element is both aligned and not visible in the view. In these instances we recommend using the right-click > Dismiss option.
An annotation clash is defined as an overlap of the bounding box of two annotation elements. Some annotative elements are ignored during annotation clash, either because the results would not be helpful, such as for Revision Clouds, Lines, Stairs Paths, or Groups, etc. or because there are programmatic challenges to get accurate results such as for Title blocks and Spot Dimensions/Spot Elevations.
Dimension text is currently defined by a point, and not by a bounding box, so clashes between one dimension and another will not be displayed.
In the example shown below, there is a clash identified between a Wall Tag and a Linear Dimension String. The clash is shown as “Working Dimensions: WV_L5 - Dimension Clash” and each of the two elements that comprise the clash are also listed below. If you double-click on either of the clashed elements, the Revit view where the clash can be seen will become active and the view will zoom to the location of the clash.
Each tag has a bounding box that is sized according to its geometry. Invisible lines in a tag family, for example, can create an unexpectedly large bounding box and may produce unexpected clash results. If that overlap area exceeds the specified Clash Sensitivity, as a percent of area allowed relative to the smaller of the two boxes, it will be considered a clash.
Blank tags are annoying because they show a “?” when the parameter value is empty. This condition can result in a need to re-publish the documentation. Use the Review tab to find and manage these conditions. If you’re in a hurry, you can right-click to select all blank tags and delete them before you publish. Alternatively you should double-click on each tag and resolve the parameter value. For example, a wall tag typically references the Type Mark value. If your project has 100 wall tags that all tag the same wall type, setting a value on the wall Type Mark will result in all 100 issues being resolved at once.
NOTE: Material Tags return inaccurate information about their tag text values via the Revit API and therefore are excluded from this issue, unfortunately.
Occasionally when copy/pasting tags or when using design options, elements can be inadvertently tagged more than once, taking up valuable white space and resulting in messy and confusing documentation.
You can also delete duplicate tags by right clicking and selecting either Retain Originals or Retain Latest. Originals refers to the tag with the lower element Id (the one placed first).
When an elevation mark is first manually placed it will have one of the four directional checkboxes selected. Later, if all of elevation(s) referenced by the mark are deleted, the elevation mark itself will remain. This issue is designed to help you find and delete these marks. Deleting the marks is not required for printing, as they can be hidden during printing, but has the benefit of also not needing to be checked for annotation clashes.
In Revit you can select any element and right-click to select Hide in View>Elements. This method should be used sparingly for model elements and almost never with annotative elements, simply because they are already view-specific (with the exception of dependent views). Double-clicking on an annotative element, from either the Browse or Review tab will display this prompt to help you view the element.
All annotative elements that have been treated this way will display under the “Hidden by Element” issue in Ideate Annotate on the Review tab except in cases where the view is a parent/child view. This means that all of the elements listed under “Hidden by Element” may be safely deleted without any unforeseen consequences. We recommend deleting these items. Annotative elements that exist on a parent/child view and have been hidden with this method will be displayed instead under the “Other Not Visible” issue type as described below.
The purpose of having two different issue types that relate to annotation visibility is to make the important distinction between elements that are intentionally set to be invisible as described above for “Hidden by Element” and the many other invisibility conditions that are possibly unintentional. The later are identified as “Other Not Visible”. When the invisibility is not intentional the recommended action item is less clear. See below for a few examples, with recommended actions.
A keynote can be used to tag a wall or beam condition in a callout section. Later the size of the callout might be adjusted by someone else in a different view. The result of changing the callout could be that the tagged element becomes hidden. When the element is hidden the tag also becomes hidden.
Recommended Action: In this scenario you should ask yourself whether the keynote is important to the project documentation. If so, then you should use the XRay feature to learn why the keynote is hidden and resolve that condition.
All annotation can be made invisible if the annotation crop is turned on in a view and the annotation is outside of the crop area. The annotation crop function is particularly valuable for dependent views and is sometimes unnecessarily used for non-dependent views.
Recommended Action for non-dependent views: This recommendation refers to views where the view’s Dependency property is set to “Independent”. In these views the invisible annotative elements are not displayed within any other view. If they are not expected in the active view, then they should be deleted to avoid confusion and to reduce liability issues.
Recommended Action for dependent views: This recommendation refers to views where the view’s Dependency property is set to “Primary” (aka parent view) or to another view name (aka child view). In these views the invisible annotative element MIGHT be visible the child or parent view and should be carefully considered before any action is taken.
From the Revit Help file:
“Elements and tags can become orphaned when:
Note: Tags can also become orphaned as a result of certain functions, such as Mirror, or Cut and Paste. These functions delete the original element and create a copy with a different ID, which can result in an orphaned tag.”
When a tag becomes orphaned, the result is a tag with a “?” and when a keynote tag becomes orphaned, the result is that the values remain, but could be no longer valid. In both cases these represent a liability in your production documents. You should either re-host or delete all orphaned tags to maintain a clean project.
Keynotes that are not referenced in the project keynote file can still exist in the project, the result is that the values remain, but may no longer be valid. This can present a liability in your production documents. You should either re-associate or delete all unreferenced tags to maintain an accurate and clean project. See Autodesk help for more information on fixing these conditions.
Thank you for taking time to inform us about a bug or feature request.