Jump to content

Single File vs. Referenced File Workflows - Landscape Architecture


ericjhberg

Recommended Posts

Since the introduction of Project Sharing in VW2016 and many other features in VW, it seems like the company has made a decision of steering users to single file workflows. With that said, we haven't found a way yet to consolidate our complex and memory intensive referenced file workflow into a single file system...at least not practically. I'm curious to what credit VW gives to differing workflows when developing tools or looking at the big picture.

 

While I love the idea of doing everything in one file, we face two large hurdles to practically implement this practice on some of our larger sites. These roadblocks are:

  1. File Size - Our work is often broken out into 3 different segments (layout/grading, planting, and irrigation); thus, we have created a separate file for each. We have created a referenced file workflow that combines each of the various files together to generate our documents (schematic, design development, construction document). On large projects it is not uncommon for any one file to top out at 1+ GB, and individually, this already puts a strain on our machines. I cannot imagine combining our files together will result in smaller or more manageable file sizes, so we really haven't even considered it.
  2. Layer Management - With our multiple files, each with their respective design and sheet layers, it is also equally hard to imagine combining all of this organization into one file without a better way to organize it. Take our irrigation files alone. Our practice is to put each individual irrigation design zone/station into its own respective design layer. We do this for a myriad of reasons, but mainly, it is just easier to track and document complex systems. That said, it isn't unheard of that some of our irrigation files will contain almost 100 design layers! Similarly, we have worked on projects that have 20 irrigation sheets, 20 hardscape/grading sheets, 20 detail sheets, and 20 planting sheets. If I put all of that information together in one file, there is no way to organize it. I imagine a simple hierarchical or folder system similar to how classes currently sort would help this exponentially.

 

The main reason I bring this topic up is that I have noticed that many of the new features VW has pushed in the past few years are solely intended to function in a single file workflow, but immediately run into difficulties when using a referenced file approach that we currently employ. Take the new Titleblocks for example, or even the old Sheet Borders...how do I use the same titleblock in 3-4 different files while keeping the Project specific data constant and maintaining individual control of the Sheet specific data? Referenced symbol? Referenced Titleblock Style? This works great in theory, but you quickly realize that the Project based data, when changed in one referenced file, does not transfer to other referenced files.

 

I would love to hear more about peoples experiences/struggles with their single file or referenced file workflows. How is it working for you? Cumbersome? Have it all worked out? What else needs to be done to make this practical?

  • Like 2
Link to comment
On 9/29/2017 at 9:21 PM, ericjhberg said:

This works great in theory, but you quickly realize that the Project based data, when changed in one referenced file, does not transfer to other referenced files.

 

I would love to hear more about peoples experiences/struggles with their single file or referenced file workflows. How is it working for you? Cumbersome? Have it all worked out? What else needs to be done to make this practical?

I'll respond in more detail later as I have somewhat similar issues to deal with, but regarding the project data... can't you put that in a referenced worksheet in a single file, i.e. to have it somewhat act like a central database with e.g. the drawing number as the unique ID? Then you could update the data for all sheets in the various drawings. Maybe not the most elegant option and perhaps it won't work at all but just something that came to mind as worksheets can essentially also function as a database containing your records/field values.

Link to comment

Too bad, as many cad programs can link to e.g. Excel files for extracting data. Vectorworks should preferably get this as well, even if it is just linking the contents from an external spreadsheet (i.e. "copy" the external spreadsheet into an Excel worksheet).

 

Now, maybe I'm too optimistic again, what if you create a design layer with the worksheet on it, then create in the other file a viewport referencing the file's layer with the worksheet and have that on a design layer in your working file for just that of having the worksheet in your work file, would it then be possible to access the data? Then when the reference updates the title block might then update its information from that worksheet.

 

Link to comment
  • 10 months later...

We set up a title block file for each project, and use a viewport reference of that title block in each other file we set up for the project.  We usually have a separate model file for each building (of a campus, for instance), and with some larger buildings, we may split the building into multiple files.  We separate 2d details into separate files, also referencing the same title block file.  

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.

Guest
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...