Large drawing file of a building with many smaller projects

[Anonymous]

I just upgraded from AC12 to AC14 and the BIM server. I am about to start working for a client with a large (1M SF) building and I will, hopefully, have many small projects within it. How do I keep each project separated so that I can do complete project documents without having a crippling number of layers.

I under stand that I should consider using linked instead of embedded libraries. I don't know if hot linking will let me create floor/ceiling plans, elevations, schedules, etc. for each individual project.

Thanks

[Anonymous]

Well one way could be to treat all sub-project's as single project's and then link them all, as module's, to a main project-file "the mother ship" for coordinating and overview.
Project name MP.pln
Project name SP1.pln
Project name SP2.pln
Project name SP3.pln . . . .
MP= Main Project, SP1=SubProject1 . . .

This could also be TW project files.

As for the layer issue I don't understand why you should end up with a "crippling number of layers". If you use the same template file, With a "complete" layer-list, to start all projects you shouldn't have to worry.

[Anonymous]

Lasse,

I do want to keep each sub project as its own individual project so that I can have Schematic, Design Development and Construction Document set for each one.

Are each of the sub projects a separate .pln file?

What I have tried to do to manage the process was to assign layers to each project. In other words, A-WALLS-INT.Project1, A-WALLS-INT.Project2 and so on for each layer type. If you have 10 projects within the same building envelope then you can see where that is heading.

Maybe there is a tutorial from Graphisoft that explains the module linking process you describe. I will do some research.

Thanks

[Anonymous]

Yes! Each sub project is a .pln.
You can link an entire .pln file as a module or choose floor by floor.
As for the layer management I would strongly advise to keep the same layer-list through the hole project.

I recommend keeping Schematics, Design Development and Construction Document's inside each sub-project. At least schematics and construction documents. This will keep them apart and there will be no need for sub-project specific layers.

But!

As you "link" these sub-project's to the "mother-ship-file" you will be able to keep them apart as they belong to a module. Each module can be assigned to a specific master layer ( Module-Project1, Module-Project2 . . . ) which controls the entire module. So you can choose to show/hide, lock/unlock whatever sub-project you wish.

[Anonymous]

Lasse,

One final question. Does each sub-project.pln contain the base drawing elements of the entire main project? All the exterior walls, other existing tenants at the time, etc. Or do you cut only the area that sub-project in located in from the main file and paste it to the sub-project.pln?

[Anonymous]

That depends on the project and as I don't know the project it's hard to give a good answer.
I have experience of residential projects where main project have been divided in eg:
-Exterior walls module (all )
-Apartment module ( area )
-Bathroom module ( area )
-Kitchen module ( area )
etc.

I hope this gives you an idea of what to do and how to divide the project into smaller pieces.

[Link]

npacella wrote:
Lasse,

One final question. Does each sub-project.pln contain the base drawing elements of the entire main project? All the exterior walls, other existing tenants at the time, etc. Or do you cut only the area that sub-project in located in from the main file and paste it to the sub-project.pln?

We often do this. We hotlink the main file back into the module file(s). We put in on a master layer called 'MODULES: BACK REFERENCE'. Just be sure to break nested hotlinks.

An alternative to hotlinking the solo projects or teamwork projects directly, is to set up a publisher set to save each story as a module file. (.MOD) and hotlink those. This method gives you more control over what is hotlinked, since you assign layer combos to what is published, is much easier to manage hotlinks and is more user friendly as you can always see exactly what each specific placed module is, simply by hovering over it and reading the element information tag.

This is the method we use to do exactly what you want to do. The difference with us is that our policy is to publish documentation only from the main project. Consequently we only have TWO files. One 'Master' (the main one) and one 'Module' file. The module file has all of the sub-projects, as you put it, on thoughtfully structured stories. These are both teamworked, so it means that all of our users only ever have to join two projects, not six or seven.

And since every project is set up like this, including high rise projects, multi-res projects etc, it's very consistent and intuitive.

It's a big step for anyone new to hotlink moduling, but well worth learning IMHO. If it's too confusing, let me know and if there's enough demand I may create a screencast of the process.

Cheers,
Link.

[Anonymous]

Thank you Link. I will let you know if I need you to create a screencast.

[Laszlo Nagy]

npacella wrote:
Maybe there is a tutorial from Graphisoft that explains the module linking process you describe. I will do some research.

In Part 2 of the Collaboration ITG, in Step 5 of Chapter 6 you can see examples of using PLN files and TW2 shared projects as modules:

You can download the ITG and watch only Step 5 of Chapter 6.

http://www.graphisoft.com/education/training_guides/#COL2

[KenMcN]

Link wrote:
The module file has all of the sub-projects, as you put it, on thoughtfully structured stories. These are both teamworked, so it means that all of our users only ever have to join two projects, not six or seven.

Link
This sounds better than our system of using separate files for each building hotlinked into a 'context' model (not least as it makes it much easier to keep attributes consistent).

Can you give some more detail about the storey setup? This seems to be the area most likely to cause confusion, but overall it could be a very good way to work.

Thanks
Kenny