View Full Version : One Building, Multiple Tenants
Matt H
2008-01-28, 06:43 PM
I want to thank everyone first and foremost for the help in advanced!
Problem:
I'm currently working on a Retail Center that is going to incorporate about 8 tenants. How do i tackle this project?
I have to treat each tenant space as its OWN project meaning i have to submit each Tenant space for its own permit...
I find that i'm going to run into a problem with sheet number because we all know, sheets can't have the same sheet number.
aaronrumple
2008-01-28, 06:47 PM
A. Use linked files.
B. Adapt a diferent naming sheme. (A.1-101 for retail bay 1)
C. Add your own parameter to the titleblock in lieu of the standard sheet number parameter.
SCShell
2008-01-29, 02:28 PM
Hey there,
Maybe this thread will help.
http://forums.augi.com/showthread.php?t=73357
If you don't want to go through the process mentioned above, you could always just copy/paste the shell building into each individual Tenant Improvement project, do your T.I. and move on the next suite as a completely separate project, but still copy/pasting the shell each time. I do that for most of my retail center work. (Just remember to set your view to "Existing" before pasting the Shell Building" into your T.I. project so that the shell shows as existing vs your new T.I. work.)
Good Luck
Steve
twiceroadsfool
2008-01-29, 03:30 PM
Hey there,
Maybe this thread will help.
http://forums.augi.com/showthread.php?t=73357
If you don't want to go through the process mentioned above, you could always just copy/paste the shell building into each individual Tenant Improvement project, do your T.I. and move on the next suite as a completely separate project, but still copy/pasting the shell each time. I do that for most of my retail center work. (Just remember to set your view to "Existing" before pasting the Shell Building" into your T.I. project so that the shell shows as existing vs your new T.I. work.)
Good Luck
Steve
I would advise that if you want to go a similar route, make good use of the Copy/Monitor tool.
I know that file linking is tedius, as you need to navigate between the different files for tagging, etc. BUT... If you copy and paste, and do not maintain some sort of established link and/or monitor, if anything changes during a revision to your Shell Package (its been my experience Retail ALWAYS has changes...) than youll be chasing those changes around in all of youre suite models.
I would do this:
Build the shell package.
Do a Save As to create the first suite, and delete everything. The only reason i would even make the suite this way, is so you have the appropriate wall types and items in the model already for the Copy/Monitor tool to make use of. Then i would CM the entire shell package, back in to the model. This way, if anything changes in the Shell Package, it will advise you to handle it when you open the Suite package.
Once you have that set up, i would do a Save As for each suite packge that you need.
I would also put the Copy/Monitor'd "Shell package Elements" on their own workset, so that if you decide to link the suites back in to the Shell package for whatever reason, you can Specify Worksets and leave the redundant shell packages out.
Hope this helps, and its not as complicated as it sounds. :)
Matt H
2008-02-15, 04:20 PM
A. Use linked files.
B. Adapt a diferent naming sheme. (A.1-101 for retail bay 1)
C. Add your own parameter to the titleblock in lieu of the standard sheet number parameter.
How does one actaully create a 'Parameter' in the Titleblock. I'm having the hardest time trying to figure out a Label that is editable between sheets. I want to use the Label "Tenant Name" and have it editable like the 'sheet issue date'.
twiceroadsfool
2008-02-16, 02:26 PM
Add the shared parameter to the Titleblock family, then also add it in under Settings > Project parameters, and it will be editable...
I did a similar project in the office where we put different tenants on different work sets. That worked fine for us. The file was only about 100 megs.
we didnt link external files but maybe we should have.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.