Wall Type Legend with Visibility Graphic / Filter Override

[BIM Branch]

Okay - I have gone almost insane with trying to search AUGI, the web, and other Revit forums looking for my specific answer, and cannot find what I am looking for.

I have a client that I have create a series of wall types. In a typical plan view (i.e. floor plan) users can draw their walls and through using Visibility/ Graphics, Filters, and Pattern Overrides. See the example below:

Wall_Types_Plan.JPG

I am now trying to create a wall types legend - using the plan view in the legend. I want to apply the same overrides in the legend.

My specific question is can you apply filters and graphic overrides in a legend? I have done the same exact process that I have done in a plan view, but it is not working. I have a major deadline and I need to get an answer to my team members!


Thanks for any help!

[pfaudler]

Not possible in Legend view.

But what I suggest you can do is to have "LEGEND" and "LEGEND DEMOLISH" phases before 'Existing' phase and add real wall objects somewhere on the side of your building in LEGEND phase. Create a plan view that only shows objects modelled in "LEGEND" phase and apply same filters/graphics as you have done in normal plan views. You can also use wall tags to show wall types. Use this as your wall legend view. you can make dependant views if you want to insert wall legend in multiple sheets. Also, demolish these wall objects in LEGEND DEMOLISH phase so that you don't see them in normal plan views and schedules etc.
you can use this method for floors/ceilings/roofs/doors etc.

[LP Design]

I second this suggestion. IMHO Revit legends are not quite up to par with the rest of the program. The "legend phases" concept sounds really odd at first, but I have been using it for door and window types legends for years now and it works well. Just make sure you set up a few 3D views by phase for quality control purposes.
-LP

[pmartini4560626]

I would generally advise against creating phases and geometry simply for legend views or other graphical workarounds. I say this because it creates an additional layer of complication and coordination with schedules, option sets, graphics in various views, and when sharing the model with other disciplines (i.e., linking in models and then trying to reconcile with phases from other models). Also, many a BIM execution plan (particularly with larger/institutional clients or contractors) will forbid you from workarounds like this.

The software was simply not designed to work this way, and workarounds have a way of biting you in the butt later. Unfortunately, it seems drafting lines and hatches might be your best bet. It's a bummer situation, but hopefully this will change with later releases.

[LP Design]

Since my last post here over 3 years ago I have not run into any significant problems with the legend demo workaround. Coordinating phases is simply a matter of fixing visibility in linked models which should be SOP.

In my personal experience I have not worked on any extremely large single projects (there are plenty posts on the forums about million SF models) so I can't really comment about butt-biting on that scale. On smaller jobs (<100,000 SF) the benefits have far outweighed any problems since the legend objects are directly linked via type to the physical objects in plan. For example, re-ordering and re-numbering the legend will automatically change plan callouts throughout, which to me is the very essence of BIM.

I have also worked on Revit projects with static legends and we have had coordination problems due to the non-bim nature of the process. Incorrect window tags, hours of double checking door types and sizes vs door types, etc.

Although I do have a difference of opinion here I would be interested to hear about a specific problem you have experienced and how it was solved.

[pmartini4560626]

Hi LP,

Here are some of the reasons why I have chosen to not create a separate phase to resolve graphical legend view issues (roughly in order of importance):

1. It is not a generally accepted practice. Certain projects have BIM execution plans that forbid workarounds because they disrupt standard workflows, particularly when its as heavy-handed as creating an entirely new phase to overcome graphical issues. Subcontractors who model all of the geometry and owners' BIM consultants would not like it, and ultimately we have to defer to the BIM execution plan we all agreed to use. While I have yet to find a "one size fits all" approach to Revit, this practice is so far removed from industry standard that it is reason enough for me to not adopt it.
2. It is not an intuitive process. People barely understand phasing as it is, and it was certainly not designed to overcome Legend View graphical issues. In the spirit of Lean management, non-intuitive practices disrupt flow.
3. It is a workaround. Workarounds by their definition are temporary and unusual fixes to a fundamental flaw. They can be difficult to reverse engineer if no one is available to explain it, or a cumbersome to work with when trying to make changes to the system upon which the workaround originally was based on. As we all know, Revit has a very particlar way of working, and if people don't understand all of the mechanics and moving parts, things blow up. Unfortunately not everyone is up to speed with Revit, and while we should not defer to the inexperience of others, we have to deal with reality and the limitations of others' understanding of how the software works.

Indeed, in using filled regions and lines we do lose the Revit intelligence and automation (the very essence of Revit), but unfortunately, Revit too fails to provide the intelligence and automation it promises. For example, the fact that we are even having this conversation, and that we can't apply overrides to Legend Views (we should be able to apply the same view template to the plan as we do the legends) speaks to its failure to deliver.

One possible Revit-friendly way to overcome some of the wall type graphical limitations could be with using the "Coarse Scale Fill Pattern" parameter in the walls to assign a hatch, using wall Legend Components, and then assigning the Legend View to be coarse. Problem with this is that if your plan views are coarse and you need to dimension to face of core, you can't actually see the core, so you'll have to tab around to find it (and then hope you hit it). There is a "Dimension to Core" option when you're dimensioning, although the fact that you can't actually see it dimensioning to the core is a bit disconcerting (and not congruent with the Lean principal of visual management).

What I have tried in the past is used filters associated with hatches, and then those hatches are used in Legend Views so that if the hatch changes, it changes in the plans too. It doesn't involve Legend Components, but it's been working fairly well for code compliance plans where showing the core doesn't matter (remember, filters override the entirety of the wall cut pattern).

For other plans where dimensioning to the core is required, using a separate material within the core (STC Rated, 1 Hour, 2 Hour, 3 Hour) has seemed to be the best. This too technically is a workaround, but now all of your wall types can be used as Legend Components in Legend Views, ratings and such are automated between views, and you can view the core. If you need a clean view without a line between the different wall types when they meet (technically the core is now different materials), you can use the Override Host Layers option under VG to remove them.

It's unfortunate we're even having this conversation. Hopefully Revit will fix Legend Views such that you can simply apply all of the other graphical overrides (VG, Filters, etc.) as you would with any other view.

[LP Design]

Thank you for your detailed reply. Although I do agree with the spirit of your point of view (why ARE we still having this discussion in 2016??) i still disagree about the specific problems you bring up.

Certain projects have BIM execution plans that forbid workarounds because they disrupt standard workflows, particularly when its as heavy-handed as creating an entirely new phase to overcome graphical issues.

With a good template the approach is not heavy handed nor disruptive. In my firm the phases, "legend" views, and several QC views are already set up and ready in the template. The workflow from that point is really simple. Just open the designated views and start dropping in objects.

BIM consultants would not like it, and ultimately we have to defer to the BIM execution plan we all agreed to use

We have had very little trouble with consultants regarding this item. Again, the phases are already set up in our template, so as long as their phase filters don't get set to "none" then there is no special coordination necessary. Obviously if a BIM EP specifically forbids something then the point is moot. I'm debating the validity of the practice in the first place.

People barely understand phasing as it is, and it was certainly not designed to overcome Legend View graphical issues.

we should not defer to the inexperience of others

I agree with both statements. Yes, I know I'm cherry-picking your post. Still though....

They can be difficult to reverse engineer if no one is available to explain it, or a cumbersome to work with when trying to make changes to the system upon which the workaround originally was based on

This is true as well, but you could make a similar argument about any company-wide policy change. Once the method is implemented it only becomes a pain if someone tries to change it. If everyone is on board then there is no need to reverse engineer or do anything complicated like that.

Any new system can be a pain to implement. Any existing system can be a pain to fix. IMO neither of those points invalidates the benefits gained by using a work around. I suppose there is simply a philosophical difference in the approach. Some view workaround as a dirty word because of reasons like what you mentioned. Others view workarounds as a way to get the functionality that should have been included in the first place.

[pmartini4560626]

Hi LP,

Let me clarify. A practice being a workaround in and of itself does not invalidate its use. That's why I mentioned using different materials for ratings in walls has proven useful for me. In a Revit metal stud wall, the materials are different (Metal Stud Wall, Metal Stud Wall - 1 HR, Metal Stud Wall - 2 HR) to show ratings, when in actuality, it's one material (it's all metal stud framing). This is technically a workaround, but it is still fairly conducive to how Revit works.

I'm not sure if the last two paragraphs of your most recent post are exactly relevant to what I'm saying. Change/employing alternate practices in and of itself is not bad. The problem comes when the standard works against the system's desired workflow. Teaching and learning Revit can be difficult enough, but to then add another layer of intricacy by teaching to work in a way that is not exactly conducive to the software causes a lot of frustration and leads to money-wasting mistakes. If there is enough value in it, its worth the effort. Could this alternate method become so commonplace that is no longer causes headaches, therefore invalidating my workaround/mistakes/reverse engineering argument? Sure--I just don't see that happening industry-wide though.

Point 1 of my recent post is what unilaterally makes me not use this alternate method. I have yet to see it in practice (I've been in three firms in the last three years and have had access to other firm's templates), and I work with large clients and contractors who would not allow it.

Come by San Diego and we'll chat in person.

[LP Design]

Good points again. I guess I'm not as worried about the overall industry but Albuquerque isn't as big of a market as SoCal. Even so we do have a bim users group that is working on creating a state wide standard so it will be interesting to see how things like this play out.

I'll definitely have to drop by. SD is my hometown and I sure do miss me some Rubios... (and In-n-out... (ok mostly in-n-out))

[j.smart496487]

A good workaround is to have a 'wall types' workset. This workset can be set to be hidden globally and only shown in the wall types plan legend. We are using this methodology currently. We have also grouped the range of wall types in the model and converted the group to an externally referenced file, to prevent accidental deletion, modification, etc.