Everyone wants to have accessibility clearances built into families. Sure, why not? Pop in that door or drinking fountain, and BAM! (sorry, Emeril!) you got your clearances RIGHT HERE!
This topic came up in a recent AUGI post, and I (naturally) have a pretty strong opinion on it. I’ll save you a click (unless you want to read through others’ comments) and repost my reply here:
This is something that gets asked for all the time, and here’s the deal: you have to really commit to accurately creating and using families with those clearances built in – especially doors.Because there’s so many variations. Push side on a straight-on approach. Push side with a side-approach. Same with the pull-side. And if they change from one side of the door to another? More variation. And active leaf conditions? Revit won’t assess the scenario when the door is placed, the user has to do that, and it’s then either a Type variation (can wreck havoc on your door schedules, if filtering/sorting by type ever becomes a need) or a whole lot of instance variables, which become MUCH harder to track and manage. And lets not even start on making sure the creator of that family is consistent in building those visibility settings into EVERY door family to be used by that firm so that the workflow is consistent not just from project to project, but within the same project! It needs to be very thoroughly thought through from the beginning.
I now have my teams place separate generic models for the clearance outlines adjacent to the doors, so they are making a conscious assessment. They are visible in working views, but filtered out in documentation views.
I spent quite a lot of time putting together a Detail ‘clearances’ family. It works for different sizes and different access conditions. I then create an ‘access check’ view and manually place these families on each side of the doors I want to check. (PS – I am in Australia).
Hi Luke, sounds like a great approach – but can I ask why you created it as a detail component, rather than a generic model family? As a detail, it is only seen in the view it’s placed in, so doesn’t visually inform the modelers in other views. I deliberate over detail component / generic annotation (symbols) / generic model families all the time, and I’d like to hear someone else’s take on why to use one over the other.
Pingback: Trackback
Pingback: Trackback