Scheduling Wall Heights in Revit

One of the new features in Revit 2015 was the ability to schedule wall heights - well, sort of.  More Wall parameters could be scheduled than previously:

• Base Constraint
• Base Offset
• Top Constraint
• Top Offset
• Unconnected Height

What was not included in this list was "Top is Attached" or "Base is Attached". 
This is really worrying because it means that when a wall is attached at top or bottom, the "Unconnected Height" is almost certainly going to be displaying a false value in the properties dialog box, and in the schedule.  

Unattached wall with correct Unconnected Height property

Attached wall top with wrong Unconnected Height property

In the properties dialog you can see those "Attached" checkboxes so it might alert you to the issue, but that does not help in a schedule, as you cannot display those properties there.

This also occurs when a wall has been attached to a gable end roof (or any angled roof)

Edit Wall Profile

The same problem could also happen if a wall has had its profile edited - again the wall heights could be scheduling false values. 

This is not so simple to pick, as there is no property for "Profile is edited" - however, Revit knows if it has been edited or not because it displays a "Reset Profile" icon in the ribbon if a selected wall has had its profile edited .

 Schedules

Basically, when you schedule wall heights using the 'Unconnected Height' property, it could be a pack of lies!  If we could also schedule the "Attached" properties of a wall, then we could use the schedule to identify attached walls, and perhaps use conditional formatting to highlight possible false height values.


One alternative solution is to create a calculated value of Length x Unconnected Height to get the supposed area;  this can be compared to the actual reported area (built-in property).  If they are different then you know that the wall has been either attached or had its profile edited - therefore the 'Unconnected Height' property is unreliable.

You could take this a step further by adding a comparison calculation

You could then do some conditional formatting to make any dodgy wall heights easily apparent

One other thing you could do is reverese engineer the height by adding a calculated Average Height - This would only be accurate for rectangular walls, as those with sloping tops or edited profiles would still not be accurate - hence the use of the word 'Average' in the calculation name.  I would use this solution with caution - perhaps only where walls have accidentally been attached to floors above.

Attach Walls to Edited Floor Sketches?

One of the reasons that all of this is likely to be an issue for all of you is that when you edit a floor, Revit always asks if you want to attach walls below it.  The default answer is 'Yes', which means that a lot of walls will end up being accidentally attached to floors above - meaning that your wall heights will be wrong in schedules.  Wouldn't it be better if the default answer was 'No' and even better still if this dialog box never, ever appeared.

Please vote for this Revit Idea to encourage Autodesk to do something about this.

Weird Stuff with Revit Shared Parameters

When you create a suite of similar parametric families (say windows), you will define a series of parameters that control the families in the project - it may be dimensions, visibility switches etc.  If those are instance parameter, there is a really important choice you have to make:

• Should they be "Shared Parameters" or just regular "Family Parameters"?

Conventional wisdom says that you only need to make them shared if you want to tag or schedule them in the project.  However, there are some other critical differences in behaviour that may affect your decision:

Did you know that when you make them 'Family Parameters', then start using the families in the project and swap them over for similar families with identical parameters - Revit loses the  data held in the instance parameters - even if the instance parameters are identically named in the families?  Aargh!!  That is not good news.  This even happens if the families were cloned from one source that already had the parameters set up.

However, if you used 'Shared Parameters' that instance property data is maintained when you swap family/types (provided that the same shared parameters are defined in each of the families).

Here is another reason for using shared parameters even when you don't need to tag or schedule them.