• Concerning the local vs central, if more than one person is using the Revit file then always central.  The general practice should always to be using central workshared files.  The Hong Kong Disneyland project I'm currently on is using Buzzsaw to share the central files.  GTeam could be used in the same fashion.  The reason they can share the central files is because their teams' workdays do not overlap.  

   

  If you have a distributed team who needs to work on a Revit file simultaneously then it has to be Revit Server.  As you know GTeam does not support Revit worksharing.  It just supports the file type. And there are no plans for GTeam to support Revit worksharing.  So the only workable solution for sharing a central workshared file on GTeam is if the team is distributed but working at different hours from each other.  They would need to define a schedule and know when they could and couldn't work on the Revit central file. The schedule would need to include time for sync up and down to GTeam.

  • worksharing revit gteam

• Revit to Excel Link

• I have played around with ODBC and it can be difficult to setup and is not very user friendly for manipulating data.

   

  The tool below is being used on the Disney Castle to adjust parameters and has worked quite well and is super cheap.

   

  http://www.davidrushforth.com/RushforthProjects/Home.html

   

  The other plugin i have tried is quite nice but more expensive.

   

  http://www.ideatebimlink.com/
• Ideate's BIMLink is one option to look at.  There's a free trial you can download.

1 more annotation...

• Managing Large Revit Projects

   
   
  • Posted by Eric Anderson
• The fundamental logic of Revit wants to keep each disciplines project data within one file.  However, as projects become larger, the need to divide the date becomes necessary.  Dividing the data can be achieved by directly moving geometry into two separate files or a more subtle way through the use of worksets.  When to use these methods is a delicate balance between managing users, data and processes. In either case, I recommend using as few of each as possible.  Managing Revit links tends to slow down the workflow and multiple worksets are good but use sparingly as each object is set manually.
• As you break a project into more and more files, it becomes difficult to produce drawings and link geometry.  Dimensioning geometry from a linked file is often dangerous and subject to deletion if the linked file changes significantly or has errors.  Smart notes like room, wall, window and door tags are also subject to the same issues.  When these objects are in the same file, Revit will warn you these things are happening as updates progress.  When the linked file is updated with major changes, you will receive all errors together and there are often limited ways to find what dimensions or tags have been deleted.  Keynoting geometry in a linked file also has its workflow issues.  If no keynote has been assigned to geometry in a linked file and a keynote tag needs to be placed, a user will need to open the linked file, add the keynote and reload the file before placing the tag on the sheet.  Ideally the data is placed all at once in the linked file but inevitably objects will be missed and the reloading of links significantly slows down drawing production.  In addition to drafting elements, system families like walls, floors and roofs cannot be joined to any linked files geometry causing graphic issues.
• Worksets allow data to stay in the same file but be loaded independently.  In order to only load the needed worksets, Open the File save Options and set the “Open workset default” to “Specify”. This will require users to always specify what worksets they want to see when opening the file.  It is important to note, that once a workset is open, it will not reduce the memory footprint much by closing it.  Only open the worksets you need for that session to reduce load and save times.
• Another use for worksets is to prevent linked files from loading.  Workshared projects save the state of linked files (loaded/unloaded).  For example, if I load the Mechanical model and sync to central, the next user to create a new local from my sync will have that model loaded.  As projects get more developed, each disciplines file becomes longer to load.  Creating a discipline workset in the file with only the linked file on it will give users the option to only load relevant models regardless of the last person to load or unload the model.  Putting this data on worksets also gives the option to “always hide” the workset on new view creation.

• 1- Do not link geometry files directly , put it in a ghost file first first:

   

  They define a ghost file as a empty REVIT file which include a single link to a single discipline file. Loading ghost files in a project results in a much smaller file size in comparison to linking project files directly.

   

  So instead of : Master Model -> Links to a discipline model.  

   

  They arrange models as : Master Model --> Link to an empty file --> which has a link to a discipline model.

  • exactly what we are doing

• 2-Create a dedicated workset to hold each Ghost file:

   

  You must have a workset to hold each ghost file link.This is useful especially when opening a project file because you can specify which worksets (thus links) to load in open time. It also gives you more flexibility in setting visibility of worksets and links per view. This is similar to how we create framing products in DP.

  • good suggestion

• 3-Create dedicated drawing files:

   

  Drawing sheets are created in separate dedicated files. Model files do not include sheets. There should be one sheet file per floor. This has many benefits like: reduced file size because you won't need to load modeling families, only related drawing and annotation families are loaded.  It also reduces traffic on files in general. The third benefit is team structuring. By breaking files this way, you can have team members working on drawing annotations for a level while others are focusing on modeling other levels in the same file. Additionally, it also helps ensure QC QA over the whole process because it enforces team communication by reporting issues to one another and by requests to sync, update, etc.

  • verify usefulness. on the first approach it seems like a good idea in terms of speed. But we're talking small teams for the time being.

• Nest Families and Annotations Issues

   

  One of the problem they keep running into is losing annotations and tags from drawing sheets when updating nested families.

   

  They have a lot of nested families and they often receive change requests. When an element (a family) that is nested inside a family is changed, tags data get lost. This is because tags are referencing an element which does not exist anymore. This actually happens on a regular basis during the project.

   

  As a solution to this problem, I suggested a different method to set up the families. It has not been implemented yet, but I think it  makes sense. At least in theory.

   

  I suggested to assemble nested families as follows: 

   

  -A family of skeleton + reference planes and reference geometry objects (points or lines) which can be set to not show on printing. These elements will include the parameters values that will show in the annotation tags. 

   

  -Add a family for each geometric element. 

   

   

  This way, if a request comes to change geometry, tags won't be lost because they actually being hosted on the skeleton family. So changing geometry does not have an effect. Also, if we had to change the product type (parameter value), we can do so easily and tags update smoothly by loading the family in the project and overriding existing parameter values.

   

  Please let me know what you think.

  • experimental
• Are you aware of any drawbacks on using "Drawing Files" (separate from the 3D geometry files)?  We've disuccsed something like this before I think. In concept it makes a lot of sense but in practice I wonder if any effeciency is lost.
•  Having separate model and drawing files is, as you have said, is a recipe to loose dimensions and smart tags frequently.  It is also time consuming to change geometry in the "model file", save, reload in the "drawing file", and then finally document. It does keep file size down but at the price of workflow and data loss.  
• Interesting idea of keeping the data in a skeleton family.  I think tags need visible geometry to show in the drawing. You might not even be able to tag planes, lines or points.

10 more annotations...