Weird Revit Railing Stuff - Part 2 - Railing Extents

Go to Revit Stair & Railings Index Page

We often create railings that consist of only the handrail, be it the old style rail or new (v2013) Top Rail or Handrail.  The reasons for this are varied:

• Often we are only interested in seeing a railing in plan
• Everyone knows that balusters in Revit railings are um, tricky, to say the least!
• Balusters, fixings, transitions etc are incredibly difficult to get right in Revit railings so many people just do those in 2d in a section view.  Yes, very "un-Revit", but pragmatic

 

In Revit pre v2013, with the old style railings, this did not cause any problems aside from the usual ones of controlling railing locations.  However, from v2013 onwards, you can get all kinds of weird stuff happening, particularly with railing extents  . . . .

Top Rail Railing Extents

With the new style of v2013 railings you can still use the old method of horizontal rails, described in my earlier post on Top Rails in Revit Railings.  If you do this, there would be no issues with railing extents.
If your railing has only a Top Rail, but no balusters, no supports, no old style rails, then it will cause problems.

No rail structure, no balusters

In this situation, the actual railing containing the Top Rail may have large extents:  In v2013 the extents will always include the 0,0,0 origin point in your project; in more recent versions the origin may vary, and may depend on whether the stair has been moved from its original location.

This problem shows up in two situations: groups and selection by click and drag.

Groups

If you create a group that contains a railing with only Top Rails, the overall extents of the group will include the extents of the railing, and hence your project origin point (in v2013).  This could result in a group with very large extents, causing all kinds of confusion.

In Revit Sundial (test version of Revit 2015 subscription enhancements, yet to be released), the code has been changed a little so that the extents do not include 0,0,0 but instead seem to include the previous location of a stair/railing that has moved.  Each time you move the stair/railing, the extents remember the previous location.  How weird is that?  Not sure when this was changed.

Selection

If you select a stair and railing by dragging across them from left to right (to include them wholly), it would normally include the stair, its sub-components, the railing and its sub-components (inc. top rails).  NB. check this in the filter selection

However, if your railing has only Top Rails, but no other sub-components, the extents of the railing would most likely be bigger so that the railings are not selected.  This is very confusing because the Top Rails are selected, which visually looks like railings are also selected - check the selection filter to see that they are not.

If Top Rails are selected, they will most likely display pins;  you will also notice that the Create Group command is greyed out - this is because Revit will not allow you to create a group that contains Top Rail sub-components, but not the parent railings.

In this situation you would need to manually add in the railings to your selection.  You might be tempted to select by dragging from right to left, which would capture the railings because it crosses their extents - but any good Revit user knows that this is seriously bad practise because it could also include hidden elements (That is the number one Autocad habit that new Revit users must unlearn!).  Once the parent railings have been added in to the selection set, the Create Group command becomes available.

Good news:  In Revit Sundial, the list of railing sub-categories has been tidied up so they are listed together by adding a "Railing:" prefix (like the stairs).  Its only a little thing, but it makes life easier - thanks Factory.

Top Rail Properties in Revit Railings
Weird Railing Stuff:
Part 1 - Top Rail Transitions
Part 3 - Railing Sketch Offsets & Transitions

Go to Revit Stair & Railings Index Page