There are lots of things to consider when starting a project. Doing so with Revit is no different. Here's a couple comments that will save you some trouble later.
Number One - Forget about True North!
Revit has a bias or assumption that you are going to ignore True North when you start out, probably because you don't have a survey yet. Sustainable design demands that you think about True North for proper sun orientation but let's just pretend for a moment that you are more interested in making it easy to document the building than its sun orientation. This means that Revit has assigned every plan oriented view (stock templates) to Project North. Model your building so that it is easy, horizontal or vertical as opposed to at 45 degrees. Don't worry about True North because you can define the True North orientation quite easily later, using a couple different approaches.
Number Two - Model separate buildings in separate files!
It is quite literally a major pain in the back side to move a building in a project after a significant amount of work has been done. There are some things that are unavoidable but changing the position of an entire building is a trivial matter when they are separate and linked into a master site file. Use the site file to organize separate building relationships. If they change, move the building, update the building's shared coordinates and move on.
The poor sap who didn't do this is now spending several hours trying to select every last little thing in a multitude of views to reposition their building while you are sipping a drink at happy hour at the Marriott with a few dozen friends. Here's a video that summarize these two points.
Forewarned is at happy hour...or soccer practice...or the archery range...
9 comments:
I'm curious to know your views in this case of how would you document your project if you had to document it in one drawing set package? Assuming that no buildings would share common details. You have a site-central, a bldg1-central, a bldg2-central, would you create a master-central and link all other models into it and cut sections, details, elevations and other views and sheets needed in the master-central? or would you document seperately in each building model? What if the buildings shared some or quite a few common details?
I plan to post more on this subject later. I'll take a stab a quick pat answers for now.
For a single building and site - Documentation is done in the building. The site can be linked into the building (a round trip of linking) for context if necessary.
Multi-buildings - Documentation in each building file as if they were separate projects with separate contractors as often ends up actually happening. Composite views for site coordination can be done in a primary building or in the site file.
Faux Multi-buildings - meaning those that are really one building, documented together as a coherent whole. These are usually better as a single model unless model size is just too unruly. The reason is that a majority of views are showing nearly all the building and the motivation for separation is internal process not necessary project scope or documentation.
If there is significant elevation difference between "wings" then a scope box can help manage the levels/grids of each unique wing. This way the project is treated like the whole building it really is.
Separate buildings shared design and resulting details - Project Shared details are created in a master project file. These details are shared with the other buildings using the Insert from File tool. The copies in the other files are only coordinated for sheet number and detail number, not actually changed. The details are printed from the master project only.
There are always building specific details too. These are in each building. A careful sheet numbering scheme for detail sheets can minimize any overlap of Common and Unique details, such a DC-100 and DS-100.
Except for buildings that need both real coordinates and correct orientation. Your link to the shared coordinates method is backward and will generally cause problems downstream with applications that do not understand Revit shared coordinates and rotation.
You should set the north rotation and locate the project correctly even if you later need to move relative to a survey. Any client requesting geolocation will be suprised when the shared coordinates move their building to 100'-0" and rotate it 90.000002 degrees.
Such as? I know there was an issue where Navisworks didn't work properly with shared coordinates but that has been fixed recently. I certainly haven't encountered every situation but the strategy has held for anything that can work with a dwg file created by exporting using the shared coordinates instead of project coordinates.
Any Bentley product, Solibri, Terramodel, ArchiCAD, and any IFC application. There is more to this world that AutoDesk products
Is IFC the common interpreter for each of the products you mentioned? Are you speaking from personal experience with each? I've only used Bentley products in years past and support for Bentley has not evolved past Microstation/J.
It should go without saying...that this is a Revit blog and everything I write here has that bias. As much as I'd like to I can't imagine every permutation let alone write about them. Thanks for the info.
Actually the common thread is the shared parameters vs. true location. This is a big problem for Revit and users have gotten lazy because it's not so coordinate crazy. The updates in 2010 to the coordinates are trying to deal with this exact problem, and users who do not locate their building properly will have more problems than just sun settings.
And since you pointed out this is a Revit blog I will mention that in my opinion this is a Revit problem not any translation from the other applications.
There are a number of owners who are not using Revit because of the percieved geolocation problem, when it is easliy solvable by properly locating the model in space.
Steve, from our experience working on school projects, the buildings on a campus are NOT done by separate contractors as the buildings are typically similar (if not the same).
For us, the solution is to select one building to handle all the details and create dummy sheets (with duplicate details) in each project so we can use call outs that reference the final detail sheet.
It's like your method but all detail sheets would be the same but we only need to develop one set for CDs. If there are changes, we only need to make them once.
It's messy but until Revit lets you detail linked files, it's the best solution that works for us.
The method you describe means duplicate details which multiplies the risk of errors (similar details don't end up similar after all)
My method is the same as yours. The dummy sheets are created for my by using Insert from File. I only worry about detail numbers and sheet numbers. The actual detail drawings don't really need to be there but it is more work to delete them.
I've always heard about the mythical project where all the details are the same and there a no building specific subtleties but I've never met one in person. Some specific nuance always seems to creep into the projects I've been around.
I do realize that many projects are built entirely by one prime contractor but again more times than not I've been around projects that started out that way but end up another. The separate files just makes that transition easier...if it happens. Lucky when things stay manageable!
Post a Comment