Revit Structure: Footing Elevations in Foundation Tags

Top of footing elevations are commonly found on a structural foundation plan, and many structural engineers like to show the top of footing elevations within their footing tag.  Footing tags that are a home to many pieces of information offer a concise way to provide a range of information in one location.  The only downside to this approach is that a straightforward method to include the top of footing elevation in a foundation tag does not currently exist out of the box.  This article outlines a method to provide a top of footing elevation in a foundation tag.

Out-of-the-Box Options

Out of the box, there are two options for showing footing elevations.  The first option is to simply use the elevation at the bottom of the footing.  This instance parameter is available in all out-of-the-box footings, and a tag referencing this parameter is also available.  The argument in favor of this approach is that everything is available out of the box, and little to no effort is required to use this tag.  The negative aspect of this option is that a structural engineer would have to change the tried-and-true way he has shown footing elevations on his drawings, as well as slightly altering the information provided on the plan—showing bottom, instead of top, of footing elevations.  This option is shown in Figure 1.

Figure 1: Out-of-the-box foundation tag with elevation at the bottom.

The second out-of-the-box option is to use a spot elevation to show the top of footing elevation.  This information may be shown separately from that shown in the footing tag; however, in an effort to keep consistent the look of their drawings both pre- and post-Revit use, structural engineers have tended toward placing the spot elevation next to or below the footing tag.  If a company uses a footing tag that has lines or boxes around each piece of information, there is a blank location on top of which the spot elevation is placed. 

A positive for this approach is that drawings can continue to look the way they always have, and all of the same information continues to be available in the same location.  The negative is that the footing tag is now two pieces and as a result, moving the tags around on the plan can leave orphaned spot elevations.  Chasing these around can be a bother and misplaced elevations are easily overlooked, so plans may eventually get to the contractor with stray footing elevations.  One might argue that this is not a major concern since design intent is not compromised; however, why not avoid the forthcoming request for information (RFI) to clarify footing elevations?

A Different Approach

Many seasoned Revit users, this author included, would argue to first utilize out-of-the-box options before creating something custom.  Even if the out-of-the-box option forces a change in how drawings look or how they are presented, if the information is greatly the same, or at least conveys the same design intent, why spend the added time to go about it differently? Function over fashion, in a manner of speaking.  With that said, the following outlines a custom workaround that will allow top of footing elevations to be included in a footing tag.

Step One: Create a Shared Parameter

The first step is to create a shared parameter for the top of footing elevation that will appear in the foundation tag.  This should be a length parameter.  This parameter then should be added as a project parameter and applied to structural foundations.  There are two reasons to use a project parameter here: first, using a project parameter will avoid the need to edit all of the structural foundation families (and re-editing them if updates occur) and second, elevations of elements are not available until they are inserted into a project, so there is little benefit to putting an elevation parameter into a family.

Step Two: Create a Foundation Tag

The next step is to create a new foundation tag, or modify an existing one, that references the new top of footing elevation parameter.  Ultimately, the elevation parameter will have to be input manually, so once the new tag is created and loaded into a project (or into a project template), one could choose to go no further in this process.  In fact, many structural engineers are probably already using a method similar to this, and simply typing in the top of footing elevation.  The downside here is that there won’t be any intelligence incorporated into the elevation, so all elevations will have to be altered as elements move up or down, and all elevations will have to be checked manually to ensure their accuracy.  The remaining steps will improve upon this process such that the elevations are more easily managed.

Step Three: One More Shared Parameter

In order to avoid manually entering and managing them, the top of footing elevations will be calculated using the bottom elevation and the foundation thickness.  This calculation will be carried out in a schedule.  Unfortunately, the thickness parameter in the out-of-the-box isolated footings is not a shared parameter, so it cannot be scheduled (wall footings and foundation slabs do not have this problem).  As a result, one more shared parameter is required.  Regrettably, this parameter has to be added to each family; simply replace the existing thickness parameter with the new thickness shared parameter.  This will have to be completed in every isolated foundation family.

Step Four: Schedule the Foundations

Once the new shared parameters and the new foundation tag are created, create a schedule that includes all of the structural foundations.  Depending on the complexity of the project, some filters may be necessary to show only the desired footings.  Which fields to include is at the discretion of each user, but at the very least include footing type, elevation at the bottom, the new top of footing parameter, and all applicable thickness parameters (each of the foundation families have their own thickness parameter).  For simplicity, this article will be concerned only with one of the foundation families, the isolated foundation; however, it is possible to include and manage all of the structural foundation families in one schedule.

Step Five: Add a Calculated Value

The next step is to add a calculated value that will report the actual top of footing elevations for each footing.  Please note that the bottom elevation parameter is based on the project coordinates, so if elevation zero is not the same in both the shared and project coordinates, then this will have to be incorporated in to the calculated value.  In this example, this has been handled by adding a parameter called “Datum” and setting it to the proper elevation.  Setting the datum value can be achieved quickly by altering the sorting/grouping settings to group all of the footings into one row and then changing the value all at once.  

To calculate the actual top of footing elevation, add the foundation thickness to the elevation at the bottom, and then add the datum value, if applicable.  The calculated parameter is illustrated in Figure 2.

Figure 2: Calculated parameter with Datum.

The convenient feature of calculated values in schedules, as opposed to formulae in families, is that there is an ellipsis (“…”) button that allows the user to browse to and select the other parameters, so typos are less likely.  With adding the calculated value, the accurate top of footing elevation will appear in the schedule next to the top of footing shared parameter that needs to be manually input.  A Revit user could then simply input the proper value to match the calculated value and the elevation would then appear in the foundation tag.  A suggestion here would be to group the foundations by their calculated top of footing elevations, and then input all of the values, thus only requiring that a user type any common elevations once.  If this technique is used, be sure to ungroup the foundations and show all instances once the elevations are entered. 

Ending the process at this step would provide a simplified way to manually enter all of the top of footing elevations, but it would not entirely solve the issue that the footings may move and the elevations will have to be managed.  Yes, having the accurate elevation immediately available will aid in the management process, but it could be even easier.

Step Six: Add a Check Value

To streamline the management of the manually entered elevation values, one more step is necessary.  Add another calculated value to the schedule that is called “check.”  Make this value be the difference between the manually input value and the calculated elevation value.  Finally, use conditional formatting to turn the input elevation cell red if the “check” cell is not equal to zero (see Figures 3 and 4).

Figure 3: “Check”

Figure 4: Conditional formatting

The “Check” column can be a hidden field, if so desired, because including this step causes any incorrect values (not the check value) in the schedule to turn red, thus making it extremely easy to identify and to edit the incorrect values.

Another approach is to make the “check” value a yes/no parameter, instead of length, that tests if the calculated value equals the manually entered value.  The conditional formatting can then be set to turn the inputted value red if the yes/no check parameter returns a “no.”  The yes/no return may be a more straightforward test output, but knowing the total difference between the calculated and the manually entered value may be useful.  Either method will work, but one or the other may be of more use to the user.

Once the schedule is expanded for the other structural foundation values, a calculated value as well as a separate check field will be required for each structural foundation family.  However, the conditional formatting can include multiple criteria, so simply add a test expression for each foundation family to the inputted top of footing elevation’s conditional formatting.

Step Seven: Use the Schedule

After the schedule is completed, the only remaining step is to use it, and to remember to occasionally check that values are not coming up red.  When the foundations and the tags are originally placed, the elevation field will be blank, so that helps to remind the user to visit the schedule.  Then, as long as the schedule is checked prior to issuing the construction documents, the structural engineer can be confident that the top of footing elevations are accurate.  Utilizing the schedule in this manner takes the otherwise long process of checking the manually inputted elevations and turns it into a shorter and much simpler task.  The schedule also adds a level of automation that will reduce errors. 

Figure 5 shows tiled windows of the completed schedule (the check column is shown here, but would typically be a hidden field, as previously noted), and the foundations with their tags.

Figure 5: Completed schedule and footings with tags.


As with all “workaround” solutions, this method is not perfect for all situations.  However, the tags, the schedule, the equations, and the formatting can all be altered to fit most conditions.

There is at least one available add-in that addresses a similar issue within Autodesk® Revit® Architecture, so someone out there may have created an add-in for this problem.  Furthermore, an add-in, or perhaps even a little extra coding could potentially be created to carry out the matching of the calculated values and the input values (i.e., “make column A equal column B”) so there may be an even easier method out there.

To conclude, there are viable out-of-the-box options for conveying the elevations of footings.  However, if a structural engineer would like to have a way to include specifically the top of footing elevation in the foundation tag, and would like the elevation value (almost) automatically populated with the correct value, with little management or maintenance of those values, then the above method is a viable option that has been successfully used on several projects.

Desirée (Dezi) Mackey, PE is a structural engineer with Martin/Martin in Denver, Colorado.  She serves as treasurer and on the board of directors of AUGI, she is President of the Denver Revit Users Group and has spoken at Autodesk University and Revit Technology Conference.  She and her husband, Brian Mackey, own BD Mackey Consulting, a BIM consulting firm.  Dezi can be reached via email at or on Twitter @RevitGeeksWife.

Appears in these Categories