Hans-Olav Posted March 22, 2018 Share Posted March 22, 2018 Hi We have for many years worked with "old style" layer referencing from a model file or set of model files into files for each phase of the project. The target files have typically plan and section viewports with annotations and the same data can be presented in different style and resolution depending on each phase's requirements. When Project Sharing was introduced we could reduce the number of files and had less recourse conflicts, but a set of new Project Sharing problems occurred. A lot of the bugs are now solved. The improved publish command is a timesaver when you can produce a complete drawing set with pdfs and dwg's from one file. When Project Sharing was new we tried to share two files in the row, the model file and the construction document file. We had a LOT of trouble. Since then we have only shared the Model file. In one of the current projects we need more people to have access to the construction document file. I wonder if it is a recommended workflow to share two documents in a row, and what happens if two people are updating the reference and committing changes to the same file. anyone here using the same workflow? or is it better to somehow split up the files to give more people access? Kind regards Hans-Olav Quote Link to comment
Christiaan Posted March 22, 2018 Share Posted March 22, 2018 Hans, it's not clear to me how splitting the files would give more access under Project Sharing? From my experience the longer you can keep everything together in one file the better. Quote Link to comment
Hans-Olav Posted March 22, 2018 Author Share Posted March 22, 2018 Agree - but if project sharing of the target file is dangerous I could split it into several files. Plans in one, sections in another and so on. Quote Link to comment
Christiaan Posted March 23, 2018 Share Posted March 23, 2018 (edited) We used that workflow initially but there are problems: More file management, including increased potential for screw-ups related to more complicated file management. It makes many things more complicated, even just exporting files. (I hatesess file management!) More bugs. Workgroup Referencing is another vector for bugs and there have been some long-standing ones that we never got to the bottom of, especially relating to Section Viewports. And the straw that broke the camels back: Edit Section In-Place doesn't work with referenced files. Since moving to a one-file policy we haven't had to split any files up yet. But it's a lot easier to split them up than it is to merge them. I have a project coming down the line in April that we'll need to split up simply because it involves multiple buildings. I'm not particularly looking forward to that because having everything in one file has made life a lot easier (apart from some hugely aggravating PS bugs causing data loss, but that's another story!) How do you mean dangerous? Edited March 23, 2018 by Christiaan Quote Link to comment
Hans-Olav Posted March 23, 2018 Author Share Posted March 23, 2018 Thanks a lot for the input @Christiaan I haven't yet dared to put a whole project in one file. Our current setup keeps the size of each phase-file smaller, we are referencing just the layers needed for each phase. Typically prelim face is less than ten sheets A1, building permit 20-30 sheets and construction phase is 60-100+ A1sheets. Section viewports are working fine when using old style layer referencing, and I believe we have a more manageable model file when we have less rendered viewports in the file. We have some temporary sections and elevation viewports in the model file to use the edit in place function, but the final rendered viewports are all in the target files. I guess its all about balancing file size versus file management in a project. My main question is if it is sound or dangerous to use project sharing on two files in a layer referenced row, like in my fig.1. Theoretically each user are have both files open and are committing changes to both and updating the reference without talking to each other. Maybe @Gunther can answer? Quote Link to comment
Hans-Olav Posted March 24, 2018 Author Share Posted March 24, 2018 @_c_ do you have an opinion? Quote Link to comment
_c_ Posted March 24, 2018 Share Posted March 24, 2018 (edited) Ciao Hans-Olav, I find it impossible to have a singular file. No idea how to archive and manage the obsolescence of the Viewports in that structure. The file size! We have this structure below, which is close to your one. It is very flexible and stable. We don't use project sharing where we issue (Sheet layers). What you call Target files. So the answer is: no, I'd advise you not to use PS in target files. Our structure: Folder 0 1 or more project files (.vwxp) containing everything excluding sheet layers 0 or more normal files (.vwx) containing 2D details, variants, etc. excluding sheet layers reference across these mainly old style, no automatic update Folder 1-5 (data collection, preliminary, project, permits, construction drawing) plot files, data etc. thematically sorted, all references old style to folder 0, no automatic update Archive of the issued files above: as soon as we issue a set, we archive the whole file. On top of the folders remains the last used file set Worgroup: 3 Workgroup folders for the office, project specific resources are never there. No problem with Project Sharing and referencing in this workflow, as far as I am aware. Edited March 24, 2018 by _c_ split better Quote Link to comment
_c_ Posted March 24, 2018 Share Posted March 24, 2018 Ciao Christiaan, I am of the opinion that live sections are just an edit tool. No need to have that also published, they also require a different set of attributes. BTW, only now, by the released SP3, am I able to use the sections as live tool, they were simply too crashy and had an ugly performance making them unusable. Quote Link to comment
Hans-Olav Posted March 24, 2018 Author Share Posted March 24, 2018 Thanks for the input @_c_ Quote Link to comment
Chad Hamilton HAArchs Posted March 26, 2018 Share Posted March 26, 2018 We keep the building model in one shared file, which tends to approach 200 mb as a file. We keep the title block in a separate, referenced file, and 2d details in individual files. We keep alll sections, elevations and schedules derived from the model in the model file. Due to sheet size (typically we stick with 30 x 42 inch sheets), we will frequently split our models to follow what fits on a standard sheet - this also tends to keep our models within the same storage size range. For publishing, we link related files, so we can publish the entire project from the model file. Other than periodic file sharing bugs in the conversion from VW 2017 to VW 2018, this system works well with minimal problems. Quote Link to comment
Hans-Olav Posted March 28, 2018 Author Share Posted March 28, 2018 Thanks for the info Quote Link to comment
Recommended Posts
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.