I am busy creating a schedule for an area plan. I need to get the number of trees that I need to cut down, can keep and plant new. For this I created a Planting family with a few type parametes that change the appearance of the tree (e.g. the Yes/No parameter kappen (which means to cut down in Dutch) is linked to the visibility of a cross across the tree symbol).

So far so good.

I can then create a schedule with my familty types and totals. Cool.

But now I want to only see the trees left at the end of the project.

One option would be to phase the trees (set the phase demolished parameter of all trees to be cut down to the phase of the new construction), but for other reasons I did not want to go that way.

So I figured I would simply set the filter of the schedule and filter out the appropriate family type. But, lo and behold, I don't get that option!

A quick Google-search reveals that this is not a bug but a feature (or something like that).

So for a workaround I am now using the Type Mark parameter, setting it to different values for the different family types. (The other option would have been to create my own shared parameter and attach it to both the project and the family, but I'm just lazy. Plus I can now use this to tag the trees as well.)


But I don't get why I cannot filter based on family type. What would have been the trouble with this? Can someone explain?

Once you know how the whole central file / local file business works (see my earlier post), it is time to see it in action and check out the advantages en the pitfalls of this system.

Some of the advantages of worksharing are clear:

• several people can work on the same project
• no need to shuffle multiple files
• always work on the most up-to-date version of the project

But working together on the same file also demands good commuunitcation between the users. For a smooth workflow it is important that you make clear guidlines and rules for such things as:

• who is working on what
• importing of families
• use of families
• family type naming conventions
• where to switch from 3D to 2D

In the past I have noticed that despite office standards each user is going about working with Revit and setting up their projects in a slightly different manner. This is a limited problem as long as only one person works on the project from start to finish, but once more draughtsmen get involved, the error ratio and the frustration levels grow exponentially.

This is why I find it imperative that one person is designated to "guard" the drawing. He or she will be responsible for the consistency of the file and will spend time on checking the work of others. In the beginning there will be a lot of checking and correcting, but as time goes on, this should diminish - as long as the errors are communicated with the rest of the group!

Unfortunately, Autodesk does not offer an easy tool for communication between the different users working on a project. Yes, there is the Worksharing Monitor (see post here), which I recommend to use always. But there is no quick communication tool built into this (think chat-client).

What I have done in the past is to introduce a Jabber server and client (an internal chat program that relies on a local server instead of ICQ, MSN, etc). This made work a lot easier and faster, especially when the different users don't share the same office space. Give it a try.

Working on projects with several people at the same time can be a challenge, especially if the projects get fairly big and involved. Coordination and project consitency suddenly become very important.

To make this scenario managable, Autodesk introduced Worksharing & Worksets into Revit. I will cover the basic setup in this post and go into the nitty gritty of creating and managing worksets in the second.

So, first off, what is Worksharing? Worksharing means what is says: multiple users working together on one project, in one file.

Wait! What? One file? That's not possible! Just look at any other software out there! You cannot open one file more than once.

That is (sort of) correct. Windows will only grant one person write access to any file at any one time. So it would be almost impossible to open one file from multiple computers and expect everything to go smoothly.

Revit solves this by introducing the concept of a central file (residing on the server) as a sort of overseer and multiple local files (residing on the workstations of the users) as the actual files people work in.

The central file is located on a central location (hence the name), for example the office servers. It contains the model information and is in charge of allowing (or disallowing) users to make changes to objects, views, layouts etc. It does so by "lending" out objects to a specific user, thus allowing him or her to edit said object and denying everyone else access. Once that user is done with the object he or she reliquishes the hold on the object and returns it to the pool of editable objects.

For example: UserA wants to move an interior wall 50cm to the right. He grabs the wall and moves it. Revit as now determined that UserA wants to edit this wall and assigns the wall to UserA. UserA now has full control over the wall. UseressB now wants to move the wall 75cm the other way. She cannot do that, because Revit has locked the wall. Only after UserA relinquishes his hold on the wall will UseressB be able to do the change she wants.

The central file is responsible for this sort of rights management.

The local file(s) is located on the local harddisk of the user and is there to facilitate the rights management as much as enable quick working. It also contains a copy of all model information which has to manually be updated. This is to prevent data-loss should the connection to the central file be severed. The local file has the same name as the central file, but with _username added to the end.