KenMcN wrote:
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
Please find below an image showing an example list of our story structure and how we create our Module Publisher Set (using AC15).
We use spare stories ( that remain spare until the user needs one) because inserting new stories breaks existing HLMs, as listed as a downside below. And we generally don't publish any of the spares. New stories can be added above and below the existing structure, just not in-between.
The 'EXPORT: MODULES' viewset is a clone of the Stories in the Project Map. All views have their ID set to 'None' and all have the same 'EXPORT: MODULES' layer combo, scale, PSD, penset, 'EXPORT: MODULES' MVO, dimension standard and zooming. The 'EXPORT: MODULES' publisher set is simply a shortcut of the viewset. When I modify the company template and share it on the BIM Server, I typically set up all stories as spares (eg. 'FLOOR PLATE: SPARE'). Then all the users need to do is rename the story, and the publisher set updates accordingly, using my
marker referencing philosophy.
The Master file has module 'master layers' that match the names of the stories/views/modules. Eg. MODULES: CORES, MODULES: FLOOR PLATES, etc so we have full control over each module type. Phasing requires a more complicated moduling approach.
We use 'OPTION' stories for optioning. We never actually publish the option stories. It's just a simple copy/paste between those stories and the ones above, and a republish.
This file is simply a 'construction area' and no drawings or 3D views come from it - only the published module files, which are 'assembled' in the Master file.
As I mentioned
here this works very well.
The upsides:
-In the 'module' file you can trace reference between plans nicely.
-We don't experience any issues with multi-story library parts (as we export the current story only).
-Publishing is very simple.
-MOD files are tiny.
-Updating is very quick.
-Relinking is easy & intuitive.
-Hovering over a hotlinked MOD file reveals the exact name of the MOD (not just the file it comes from), assuming your naming conventions are descriptive.
-Attribute Management is very simple.
The downsides:
-Inter-story SEOs don't actually hold their relationships and can't be re-SEO'd in the Master file. (You can use Trim to Roof instead in some cases, or an intermediate module file according to GS).
-If new stories are inserted into the 'module file', all the links will break (this is a technical limitation to date, and is why we have more than enough stories preset in the module file, and add to the top/bottom if we must.
-If new stories are inserted into the 'module file', the cloned view name does not automatically acquire an ID set to None, so must be set manually.
-A dimensioned structural grid needs to be re-dimensioned on each story once it is placed in the Master file (the grid remains visible on all stories, but not the dims).
The publishing path/location of the MOD files is not on the BIM Server as such, so can cause problem if teamworking remotely, with a VPN into the folder too.
- Whilst the name of the MOD file is traceable in the hotlink manager, the (name of the) source file isn't.
It looks like an equal argument, but from a practical point of view, there's no way we would go back to hotlinking entire projects anymore. It's really slick. I bet if you try it once, you'll never go back.
I often have my users comment how much easier it is this way - especially when they have to revisit an older project set up 'the old way'!
Cheers,
Link.