Jump to content

Referencing/federating buildings in BIM. Is there a workflow?

Recommended Posts

Hallo All!
I'm currently involved in a rather big project with several buildings that together make a block. We are thinking of splitting it into several files and federating them together in a master file, and I wonder if there is already a concrete workflow for this as, after my first attempts, I've hit some thick walls and I don't know if I'm doing something wrong. Let me explain...

I make a file with all the correct storeys with the corresponding design layers attached to the correct reference heights.
I open a new empty file with the same design layers and reference heights and reference the 1st file (is that right?).
1st problem is that the "reference object" is in the DL where I placed it and I can't control the reference visibility from the main file (yes from the object Layervisibility)... BUT I can configurate the reference so that it uses the same classes visibility as the host file. Is it possible to do something similar with the layers?
My solution is to copy the reference in each design layer and adjust the reference layer visibility accordingly (i.e. copy the reference from GF to 1stF and turn off GF). This is painstaking!
I get a "legoed" result. 2-3-4 references on top of each other... it "looks" right but it is horrible... you understand the problem as when I make a section of the frankensteined building, it must cut through several references and VW becomes crazy!
Is there a correct way to do what I want to?
Next question would be how to proceed when the references have different reference heights, but first things first...

Thanks in advance!!!

  • Like 1
Link to comment


We are using a workflow without stories and  with old layer referencing like described her below:


Currently we are doing the opposite as you ar asking for, a file with four buildings distributed on several layers, and referencing each one to drawing sets with sections and elevations for printing. 





  • Like 1
Link to comment


When using layer referencing its important to make a good system for layer names to avoid conflicts 

We use typically 6 layers for each floor and named by building, floor, purpose 

every floor have layers for slabs, walls and furniture, spaces for calculations, ceilings annotations for scale 1:100 and 1:50

Link to comment
8 hours ago, Hans-Olav said:


We are using a workflow without stories and  with old layer referencing like described her below:


Currently we are doing the opposite as you ar asking for, a file with four buildings distributed on several layers, and referencing each one to drawing sets with sections and elevations for printing. 









I went through this Thread and found @zeno example Setup.

As at first I did not understood his concept at all,

so I shared some thoughts there.

(Which doesn't mean that I really understood him though)

Link to comment
19 hours ago, zeno said:

I switched from DLVP to “all in place”

I thought about this rather drastic measure. A reknown competitor software package uses this method that could be "translatable" by having just one DL and all the needed reference heights. This would have some advantages. E.g.  we would achieve walls spanning several storeys...

In any case, my concrete problem is with the referencing.
When I place a complete model in the host file, the cross-DL system does not allow me to have the same control as I have with classes, right? IMHO this would solve ALL problems as we could manage the referenced file AS IF it were in the host file...

Link to comment
  • 2 weeks later...



there unfortunately (at least to my knowledge) isn't any whitepaper that would probably help you. Having said that, I've dealt with several very large buildings and was able to make it work. Here are a few recommendations i have done. I can also tell you what i plan to do better in the future


1. Referencing files into one master file is very important. One problem you will come across are stories - and your workflow needs to be be similar in every file.

2. Tagging wall objects/ floor objects/  window objects need to be done in the original reference file - not the master file. This is very important.

3. When working with worksheets, notes, etc... consider each portion of the set of buildings - as a separate building. Worksheets will not be able to be combined, nor will takeoffs. I still need to verify for myself whether or not worksheets can make take-offs for multiple reference files - not just the file it is in. Try this for yourself

4. Experimentation is key. If you have an idea, test it out on a test file to see if it works. You can start with the idea above. Create two different files with two different wall types, roof types etc... Then reference the two in a third "master" file and create a worksheet. Do both wall types show up in the schedule?

5. The master file should be able to have sheet layers. Be careful not to overdo it with the amount of sheet layers in the master file. If you can, split it into various sections. I for one split it into a. plans / rcps (000, 100 series), sections / elevations (200, 300 series), detail sections (400 series) and details overall (500 series) --- each with their own set of worksheets. Think about how you will create the set for each building on the block before you integrate it. This is very important if multiple people will work on the project as a whole.

6. Try to have a file that has all the wall types to be used between all the files separately - that way multiple users can access it. This will be useful when making takeoffs, needing to change wall types, floor types in different files with appropriate descriptions, UL #'s, R / U values, etc...

7. Create a master pdf set of documents in a separate directory for each sheet separately. This is important because rendering elevations and sections take a while. Doing each separately and combining them all (already pdf's) when needed will create a much quicker workflow.

8. If you have additional filing's to do like builder's pavement plans, site plans, do those in separate files as well - as a whole. They are much simpler, but with more complex mechanics when figuring out cut / fill, sidewalk elevations and slope percentages, curb cut depths, and grade / flood plane elevations.


there some features that might not work in referenced files like :

1. if a file is reference with a column grid - I do not know if the column grid will show up in the section if the master file is referenced.

2. schedules / takeoffs in referenced files - still unknown.

3. do not tag wall types in reference files. It doesn't work. Its a major flaw in VW


I'll add some more if i remember anything else. Hope this helps.


As for your question above, classes and design layers are easily manageable in reference files. Just be consistent in the way you assign classes to wall styles, floor styles, window styles etc...If it is consistent, using the eye tool, you can eliminate or turn on elements in a drawing if you have to.


Edited by Samuel Derenboim
  • Like 1
Link to comment
  • 3 weeks later...

Thanks for the advice @Samuel Derenboim. Those are indeed advanced issues that should be regarded.
My point is still how to handle the basic floorplan layouting...
Do you work by referencing layers (old way) or by generating DLVP? If by DLVP how do you layout the different levels? Do you use different "master" files? Otherwise we'd have to copy the refenreces' DLVP as many times as wanted floorplan levels, right? Am I missing something there?
Thanks in advance!

Link to comment
4 minutes ago, arquitextonica said:

Otherwise we'd have to copy the refenreces' DLVP as many times as wanted floorplan levels, right?


I am a beginner at this but yes, on advice from others, this is how I have done it: duplicate the referenced DLVP each time I want to show different class/layer visibilities in the target file. Each DLVP is on its own layer so it's a case of making the relevant layer visible in the viewport depending on what I want to see. I might have four separate models referenced into the main site model file + perhaps three different DLVPs for each model so that makes 12 DLVP design layers in total...


But I have dropped using Referenced DLVPs for the time being because I was having issues with Roofs + Doors getting messed up (not displaying properly in the DLVP). Tech Support are looking into it. So in the meantime I am switching over to using Layer Import Referencing instead because much as I like Referenced DLVPs if the model is getting seriously messed up in translation it's useless.

  • Like 2
Link to comment

Thanks @Wes Gardner. I´ve arrived to the same conclussion. I mistakedly advocated DLVP as I thought that the LIR was "outdated" or going to be deprecated, but the thing that in order to layout the different levels we have to "multicopy" the references is a no-no... so Layer Import it is. Thanks!!

PS: DLVP have the option of using the current class state, so a single DLVP can be layouted with different Class-States. Everything would be all right if the Layer-State could be inherited in the same way. Actually I don´t understand why it isn´t already...

Edited by arquitextonica
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...