Layout book PLN/s receiving drawings from site PLN, building PLNs, units PLN, component modules PLN/s . It will probably make sense to publish PMKs from the model files and create the layout drawings from those.

One PLN for the site/master. Published story modules from individual buildings are placed on it; site-level construction elements and annotations reside on it; produces site-level views (plans, sections/elevations, perspectives, movies, schedules). I strongly prefer keeping all elements (walls, roofs, windows, etc.) symbolic, and use 'projected' only for those funky elements (skewed walls, clerestory or attic walls and roofs, whatever) that need it —it is much easier to set up, manage, avoid, trace and correct mistakes, and it is less demanding on the processor. It is best to use this file (alternatively, a project 'attribute management' file, but for most typical-sized projects this adds complexity without any benefit) to create all new attributes —materials, fills, layers, layer combinations, line types, etc., and take them from here to the other files using Attribute Manager. At any point in the process you should be able to just overwrite all attributes in the other files if there has been some screwup there.

One PLN for each building. Published unit and building component modules are placed on it; building-level construction elements and annotations reside on it; produces building-level views; publishes building-level story modules containing only the information that needs to go to the site file (if you don't want/need the WCs in your site views, you don't include the layer in the 'Building-to-Site module' layer combination; you can always change this combo at any time if you find you need them; this way not only the site plan doesn't get cluttered with elements you don't need there, but also you can use the same layer to contain different information in each file, especially neat for dimensions, annotation layers).
[If you have repetitive stories you might have an additional layer of module publishing within the same building, using one story as a master and publishing modules placed in the other stories.] Typically structure, mechanical shafts, demising walls, lobbies and lower stories want to reside in this file, and unit plans, core plans, envelope&balcony are modules generated somewhere else and placed here.

One PLN for generating unit infill plans (partitions, finishes, furnishing, equipment; unit-level annotations and dimensions). Produces unit-plan-level modules (Unit module layer combo-view-publisher set) and views. Building or room components may be placed on them (envelope panels and balconies, bathroom and kitchen modules, etc.), unit-plan elements reside on them. One unit plan is modeled in each story, so that the file is actually a stack of unit plans. In the module publishing combo you include what you want to send to the building pln. Even if you have little or no repetition in the unit plans and there is no advantages from moduling in that respect, individual unit plan drawings are needed for client review and marketing purposes. This makes working on the unit plans very easy and fast —you can find-select the toilets/partitions/tiled floorings/whatever for all the unit plans in the 3D window and with a single command change all instances in the project. Creating new units is a snap, and making changes across all units works very fast -story up, story down.

One PLN 'module factory' file for each of the component types over which you want to have central control across all the project (envelope panels and balconies, core modules, kitchen modules, bathroom modules, etc.), stacking them just like the unit plans. Produces component-level modules placed in the unit plan and building files, and component-level views (balcony drawings, etc.). Because you are publishing components from here and placing them in the unit plans and building files, this is the only way of easily and manageably modifying say all windows across all the project. Not only that —if at some point you want to try out new unit plan criteria, like say smaller kitchens + no walk-in closets + larger bedrooms, you just make a duplicate of the factory file, rename it, and publish modules from there; if you want to go back to the previous unit plans you publish modules from your first file.
+
One PLN 'module depot' file for each of the component types you are producing from module factories. Here you place in a single story, neatly arranged in grids or whatever, once in each module's lifetime, one instance of each of your envelope modules (or bathroom modules, etc.), so that from then on you just copy-paste your modules from here to your building or unit plan files, without having to touch Hotlink Manager or having to care about the name of each module (which you'd better be systematic about anyway, but you only care when you create them).


This makes all files very light, manageable for the user, the computer and the network, and the file structure makes it easy to split up the work without having to touch Teamwork, which is nice to have but it is nicer to avoid. Of course, in the unlikely event that at some point you need two guys working simultaneously on the unit plans (or site plan, or layout book, or whatever) you can always teamwork that file.

There is a diagram showing how the system works in a single-building project at http://www.ignacioazpiazu.com/samples/Wyndham_file_structure.pdf —I'll put something together for multi-building projects, but the concept is the same.

WARNING: as far as I know, the disappearing-elements-in-mirrored-modules bug hasn't been solved in AC 12 yet.

Ignacio,

Nice! I do still question the need to "recreate" each building in the SITE pln. I think I'd still prefer to create an object and place it on the site. I'm thinking of the times when I'll need to move a 20 story building on the site... You'll have to do it story by story, yes? You can't use MULTI-STORY modules as all the STORY to STORY heights might be different?

So instead of PUBLISHING modules, I'll have to keep updating (or versioning) a few BUILDING objects. Might be nice as a way to study alternate building solutions in the context of a CAMPUS Plan, tho. If I KEEP versions of the same building as "design alternatives" I can easily swap one object for another... Bldg1a > Bldg1b > Bldg1c, etc.

Now if we could only create 2d HOTLINES from the 2d symbol portion of my building objects, that would be great! I do currently have to place a bunch of HOTSPOTS at the corners to be able to "register" them on the site plan.

Also note that when Campus plans get big, you can Save the OBJECTS in BINARY format which will help rendering times when you need to visual the entire project.

vfrontiers wrote:
II do still question the need to "recreate" each building in the SITE pln. I think I'd still prefer to create an object and place it on the site. I'm thinking of the times when I'll need to move a 20 story building on the site... You'll have to do it story by story, yes? You can't use MULTI-STORY modules as all the STORY to STORY heights might be different?

If a building needs to move, you drag it around *in the building file* either in the 3D window or 2D with thick marquee, and republish. It is a single operation.

[Building files should keep the site origin (so that at any point you can cut-paste stuff between site and building files, and things fall into place), unless you are talking of some more equipment-like pavilion which is not really attached to the site and that can move around, or of which there are many instances--but those are typically 1 story, 3 stories in the wildest cases.]

With objects you don't have control over layers, model display options, etc., and you can't generate site plans or diagrams, sections, elevations, perspectives, animations, schedules, from the site model without any extra work, live. You don't have a 'BIM' site-level model.

And creating and updating objects, even forgetting that they don't allow you to filter data for the documents mentioned above, is actually *a lot more work*. Once you hotlinked the stories (placing each story module once in the site file, at the start of the project—it takes a few minutes), you don't need any more work over the project's lifetime.