Revision Clouds: Sheets vs. Views

[arb]

We have an internal debate regarding where is the best place to locate our revision clouds (in views or on sheets). For our larger projects for which construction may take years we may end up issuing quite a few permit revisions, addenda, ASI's, and construction change directives. So, does anyone have any strong opinions one way or another?

This may not apply to everyone, but we've been typically issuing revisions on fullsize sheets versus smaller sketch sized sheets.

Thanks.

- Alex

[david_peterson]

The issue of putting them in views can have unwanted impact on consultants. If I have a view set-up with a linked model and that view is set to "By linked view" when you place that cloud it now shows up on my view and I have to go turn them all.
We don't do 8.5x11 or anything like that anymore for a couple of reasons. One, Revit doesn't do them so well, two they take up much more time, and three, if I give you a full size sheet anyone can print only the portion they need to a 8.5x11 inside adobe.
I'm starting a 1.2million sqft project, construction starts in Sept of this year and finishes sometime in 2017. I couldn't imagine the number of "Sketches" I'd have to do since our foundations go out before the Arch DD's. Should be lots of fun.

[arb]

It looks like most people would agree with you. Thanks for the response.

- Alex

[ttiefenbach]

We debated the same and when the smoke cleared we all agreed to go with on sheets because you can't always put it in a view, like a schedule. So you don't want clouds in views AND sheets so your left with on the sheet.

[arb]

Don't get me started regarding clouding schedules... We've set up a door revision schedule that is populated with doors with certain instance parameter properties to avoid trying to cloud a schedule that may shrink or grow as we make revisions.

If anyone knows a way to select and poche individual rows in a schedule we would prefer to go that route.

- Alex

[LP Design]

I just had this discussion in the office this morning! We are currently muddling through a construction project which is coming close to 700 RFIs. Unlike Dave's method, we DO use 8.5x11 sketches, and it is getting nasty. For us the problem is less about where the revision cloud goes, and more about how the change is documented.

Since you can't reference the same view onto multiple sheets, we end up duplicating views for every sketch we send out. The model is revised so any changes occur both on the original sheet and the sketch, but only the sketch gets a revision cloud. The main reason for this workflow is that we have a *ahem* somewhat difficult client who required us to print full progress sets withOUT revision clouds every now and again.

I'm not really sure if placing the revision cloud on the sheet rather than the view would actually affect us at all.
-LP

[david_peterson]

As for you issue of progress sets with no clouds, wouldn't it be easier to simply go into the revisions dialog box and just set all the revision to no cloud or tag?
As you said the 8.5x11 sketch thing is the one that kills me. One of the other work arounds was to change the drawing/detail on the sheet it's one (don't duplicate) and print to a jpg or a blank pdf. Then use pdf editing tool to add the border or insert the pdf into a cad drawing, add your title block and done. no duplicate views. Just another thought.

[LP Design]

wouldn't it be easier to simply go into the revisions dialog box and just set all the revision to no cloud or tag?

:-| Meh... With multiple buildings/models with anywhere from 15 to 30 revisions each, add in that you have to use a drop down to manually turn off each off one at a time. Then do the same process over again once you are done printing... Pick your poison i guess.

As for manually exporting pdfs, I guess that could work as well but there's just something about adding an extra series of steps through a different software that makes me nervous. If I have to go back to a previous sketch and revise it or whatever I want to be able to go back to the model where everything else is.

[damon.sidel]

Sorry to dredge up an old thread, but we just submitted our office's final deliverable for a project, a DD set. We'll be doing sketches from now on and adding bubbles. So a few questions:

-What would people do before Revit, say in Autocad?
-What would people do before CAD when they were hand drafting? I ask these questions to get a sense of conventional industry practice, because I often go from there when trying to figure these things out.

As for duplicating views, why not just archive a model at significant delivery stages and actually change the drawing? The record of the previous drawing is presumably in a PDF or something, right? And for many changes, I imagine you'll want to change the model, not just annotations or detail elements. What am I missing re: duplicating views for sketches?

[dkoch]

Sorry to dredge up an old thread, but we just submitted our office's final deliverable for a project, a DD set. We'll be doing sketches from now on and adding bubbles. So a few questions:

-What would people do before Revit, say in Autocad?
In AutoCAD, I would typically create a new layout for construction sketches, add the appropriate construction sketch title block, fill in the attributes (title block information for the sketch), create a viewport (possibly by copying/pasting the viewport used for the full sheet, then resizing it if needed to fit on the sketch) and print the sketch. Hard copies may have been sent, or faxed, or, more recently, PDF made and emailed. Original copy (either hard copy or PDF) would be filed/archived.


-What would people do before CAD when they were hand drafting? I ask these questions to get a sense of conventional industry practice, because I often go from there when trying to figure these things out.
Before CAD, get a sheet of velum or mylar with pre-printed sketch title block and tape it to the drawing board. Fill in title block information. Create sketch by some combination of drafting and/or copy/paste. Drafting could be all on the sketch, or the original mylars might be updated and a composite print made (we used overlay drafting), cut to fit sketch and taped up. A composite photocopy would then be made and reproduced for distribution or faxed to the appropriate parties.


As for duplicating views, why not just archive a model at significant delivery stages and actually change the drawing? The record of the previous drawing is presumably in a PDF or something, right? And for many changes, I imagine you'll want to change the model, not just annotations or detail elements. What am I missing re: duplicating views for sketches?
In Revit, I would update the model (after archiving, if appropriate). 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. 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.

[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...

[antman]

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...

I just tested this. I did a Duplicate as Dependent on an interior elevation and it created a new marker to represent the view.

Thanks for the tip about converting to an independent view - didn't know that was a function.

[cdatechguy]

Ah...yes...it does do that... We create a new elevation and section type that can be filtered out on all the views...

[antman]

And I just remembered another thing - keynote numbers are not maintained through to the dependent view. Arg!