Revision Clouds: Sheets vs. Views

[LP Design]

What am I missing re: duplicating views for sketches?

Its all about the print format. Some firms (including my own) just prefer to submit supplemental information in small page format. Then the problem becomes the fact that Revit does not allow the same view to be referenced on multiple sheets. Even if it did, the view usually needs to be cropped and re-sized anyway, so that still doesn't work.

Back in the CAD and hand-drafting days the process may have been different but the end result is essentially the same. Duplicate your work. I think that's why this particular issue bothers me. I don't WANT to go back to doing things the old fashioned way, but that's almost what has to happen when issuing small-size docs.

-LP

[patricks]

There have been other threads on this topic, where some people use a "masking" 8.5x11 title block that actually goes on top of the large sheet to mask out everything except the area in question, has an "instance" sheet number (not tied to the main sheet view numbers), and can then be hidden in the view after the sheet is printed to hard copy or PDF. But then the problem comes up of what if you need your small sheet to show a view in a different scale or show different info than what was on the original large sheet?

Our firm actually doesn't do clouds all that much. We typically do small ASI or RFP sketch sheets, with duplicated views for the very reason I mentioned above. Plus those sheets more often contain views that are all new and weren't on the original CD's.

Our projects are relatively small and usually not the "fast track" type where various parts of the building are released in separate packages, and where each sheet may go through multiple revisions. Our projects are more so the typical design-bid-build, where everything in the project is completed, sent out to GC's for bid (or to a GC for pricing to subs), and then construction begins. We rarely issue complete new sheets with revisions. But when we do, revisions Per Project is the way to go, with clouds placed on sheets. I don't want one sheet to be on revision 4 while another one is on revision 1 for changes made during the same round of revisions.

[antman]

Don't get me wrong, I think revisions in Revit need some serious help (i.e. a solution for large projects with hundreds, or thousands, of revisions and the need to organize and number them categorically - ASI, AB, CO, etc.), but for the issue at hand it seems to me to handle them extremely well.

The (non-Revit) standard I am used to involves making the change and adding a cloud and tag. Then making a small (8.5x11 or 11x17) sheet to issue, with just the portion of the view that is affected visible. The title block would include the text 'Partial Sheet X###' or 'Revised Detail #/X###', etc. The view on the small sheet would look exactly like the view on the sheet to which it corresponds.

It seems to me that the way to do this in Revit is to Duplicate as Dependent and put the revision cloud and tag in the view. Then the overall view and the partial view both look the same, and there is no redundant work to be done. David, you mention that duplicate views can get messy. Since dependent views are nested under the original, isn't that a clean way to deal with it? And in any case is it more messy than an AutoCAD drawing with 35 layout tabs?

[patricks]

^^^ I think that method would be a good candidate for the "masking" title blocks, where you actually drop your 8.5x11 on top of your original drawing with the cloud, print it, and then hide that masking sheet in the original sheet view. That way you're not having to duplicate any views. Only problem with this is that the masking title block wouldn't show up as a separate sheet in the Project Browser.

Another strategy would be to duplicate views (as dependent if you want them to show the same as original, or separate views if you need a different scale or show different info), and then name that view such as "ASI 1 - View Name", and use the Title On Sheet parameter to give the view a shorter name if needed when placed on the sheet. That way all your sketch views would be grouped in the PB if you have it set to Show All instead of Not On Sheets.

[damon.sidel]

The need for a duplicate view stems from the fact that the original view needs to remain on the original contract document sheet, and it cannot be on that sheet as well as on a sketch sheet. On a large job with a significant number of sketches, the duplicate views can get messy. An alternate method would be to make an image of the revised area, and put that on a drafting view, which then goes on the sketch sheet.

If you are changing more than just annotations, you're going to change the original view, so even if you are issuing a drawing on a different sheet, you'll have to maintain the model so that the views on the original contract document sheet continue to look good (but always changing, right?). Duplicates could get messy, but you could set up your project browser for different design phases to organize it that way. As for an image on a drafting view, that seems like you'd end up A) redrawing the entire view and B) not keeping the model coordinated, which kind of defeats the purpose, no?

Duplicate your work. I think that's why this particular issue bothers me. I don't WANT to go back to doing things the old fashioned way, but that's almost what has to happen when issuing small-size docs.

Yes, you duplicate the view, but you get all the information and as you edit it, you are editing the model at the same time, so a duplicate view would differ from the original mostly because of annotations by the time you are done... if you do it correctly.

There have been other threads on this topic, where some people use a "masking" 8.5x11 title block that actually goes on top of the large sheet to mask out everything except the area in question, has an "instance" sheet number (not tied to the main sheet view numbers), and can then be hidden in the view after the sheet is printed to hard copy or PDF.

Ack! That sound horrible! Then the only way to keep track of these new sheets is through some messy, hacked-up schedule or something? I don't see this as any better than dealing with the ramifications of duplicating views.

It seems to me that the way to do this in Revit is to Duplicate as Dependent and put the revision cloud and tag in the view.

I think from the posts and thinking about organizing the Project Browser by design phase, I'd rather just straight Duplicate the view so I have the ability to file it anywhere I want, change the scale, etc. Yes, if you ever have to reissue a full sheet, you'll have to make sure to cross-check all the annotations between the full sheet views and the duplicated views, but when you are undergoing a full submission, there's a lot of work involved so it would be well worth it at that point.

...good candidate for the "masking" title blocks.... Only problem with this is that the masking title block wouldn't show up as a separate sheet in the Project Browser.

I think circumventing the Project Browser is a huge prob

...then name that view such as "ASI 1 - View Name", and use the Title On Sheet parameter to give the view a shorter name if needed when placed on the sheet. That way all your sketch views would be grouped in the PB if you have it set to Show All instead of Not On Sheets.

You should definitely look into adding project parameter to your views like "View Type" or "View Use" and then reorganizing your Project Browser with that in mind. We starting make really effective use of this since we often have a whole set of drawings just for the model shop. We can have working drawings and printing drawings, especially for plans, so people don't go messing with the plans that will show on sheets and the we have to reprint because they forgot to turn off the underlay or turn on all the walls again.

So, from all this discussion, I'm going to take the following away:
1) Revision bubbles go on sheets.
2) Duplicate with Detailing to create ASIs/sketches and use a "View Type" project parameter to organize the project browser (and a "Sheet Type" one for the sheet organization).

This has been a really helpful conversation. Thank you everybody.

[patricks]

I think what would really help would be a "Duplicate as Snapshot" or something like that, where you could duplicate a view that is dependent on the original, and change the crop region, but not alter anything from that view. It's tied directly to the "parent" view, and you would make whatever changes you need in that "parent" view, but then the snapshot view could be cropped accordingly and placed on a small sheet.

I know Duplicate as Dependent basically does this, but the problem is that certain annotations will disappear completely (such as a dimension string) if part of that annotation is cut off by the crop region in the dependent view. A "snapshot" view would have it's crop region just be a straight crop, with annotations getting cut off by the crop but not disappearing completely. That way your main sheets would still stay fully coordinated from an annotation perspective.

*edit* Damon can you go into more detail about how you're organizing your PB with additional project parameters?

[dkoch]

An alternate method would be to make an image of the revised area, and put that on a drafting view, which then goes on the sketch sheet. Either way, I would make a PDF and file that in the project directory on the network to have an archival copy of the sketch, as it was issued.

...As for an image on a drafting view, that seems like you'd end up A) redrawing the entire view and B) not keeping the model coordinated, which kind of defeats the purpose, no?

I am not certain any method is ideal, but there is no redrawing/uncoordination with the "image" method. You would make the changes to the model & annotation, and then create the image. The image does remain static at that point; if there were future changes to the same area, you would have to make those and make a new image. I a few that way, but mostly duplicated views. One other issue with the duplicated views, beyond browser clutter, is that duplicated elevations and sections generate additional elevation and section marks, which then have to be hidden so that the original marks do not get covered over.

We avoided the problems in any method for the most part by reissuing entire sheets. The CM on the project was not enamored of small sketches, as these tended to either not make it to the field, or would quickly become separated from the main sheet and lost.

[antman]

Patrick, I think that is a great idea! Part of me wants to also wish for the ability to convert that to a static independent view (after issuance), but I guess that's what DWF is for. .-)

As for the PB organization, just create a new Project Parameter, and assign it to Views (another one for Sheets while you're at it). Go to View-->User Interface--Project Browser Organization and make a new entry, and group by the parameter you just created. With the view selected in PB, go to the Properties and type the value you want it to have. Once a value is placed in that parameter, it becomes available in the drop-down list so you don't have to type it all the time. If you want to make a large list available before they are actually assigned to any views, add them to your View Templates. Any view that doesn't have a value for the parameter will be sorted under ???. I have my views organized by which sheet series they belong to.

[antman]

One other issue with the duplicated views, beyond browser clutter, is that duplicated elevations and sections generate additional elevation and section marks, which then have to be hidden so that the original marks do not get covered over.

DOH! Good point... What a pain!

[cdatechguy]

Patrick, I think that is a great idea! Part of me wants to also wish for the ability to convert that to a static independent view (after issuance), but I guess that's what DWF is for. .-)

We never "Duplicate Views"....we always use "Duplicate as Dependent" ....because you can make it an independent view later and you don't get the section/elevation duplication error...