Jump to content

symbol management best practice resource manager


Recommended Posts

Hi all, 

 

We are looking to revolutionise how my practice currently manages our symbols and i am trying to ascertain the 'best practice' way of organising our files. We have largely taught ourselves vwx, and i think we do a lot of things haphazardly in house.

 

i've found this forum very helpful and I'd like to hear how other practices organise larger projects with multiple repeat components to get the ball rolling 

 

We do a lot of repeat work, i.e we will repeat a building shell several times in different locations. Because of this many of the typical details remain the same (e.g wall build ups, slab details, roof details etc) however internal elements such as kitchens and bathrooms may vary depending on location, client wishes etc 

 

What we would like to build is a symbol library that allows a team to always select from a list of up to date symbols for various building conditions/details. This list would ideally be managed by one person, who makes a revision in the master file, and then all instances of the detail that require the latest info can be selected and replaced. I am assuming the resource manager is the way to do this, however i have several queries on how to best facilitate this

 

-  should you have a separate file with all your symbols drawn in (i.e floating in space) and then import them into the relevant drawing files as needed?  

-  if the master file has been updated, can you replace all instances of the symbol at once, across several drawings? (like a reference)

 

until now, we had all of symbols drawn in a symbol file, and then referenced that file into our site plan file, elevation file, section file etc. Updating the symbol reference then updated all instances of the symbol in the file. Whilst this in theory did work, it doesnt feel like the smart way of doing things, and i feel like our files often got enormously complicated. I also suspect it regularly messed up our user origin, which was a real pain to keep adjusting. 

 

look forward to your thoughts

 

 

 

 

Edited by rexwexford
Link to comment
Guest Wes Gardner

Have you considered "Favorites" file(s) kept on your server?  Between this and a good template file for your building type(s) that you "goto" repeatedly, this could help organize your office.

 

Wes

Link to comment

I’ve gone through the same process as you  . It has taken a fair bit of thought, time and tweaking to get a system that works well, but I’m pleased to report it has definitely been worth the effort.

 

As @Wessuggested using favourite library files along with project template files I think is the way to go. I would also make the following suggestions:

 

Establish a std class structure that works for your office that everyone shld get familiar with. This is absolutely key (I can’t stress that enough).

 

Your library files are only going to get bigger so they need to be well organised..

Establish a folder structure in the RM of your favorites library files so resources can be found easil even by someone who may not be familiar with the library.

 

Establish naming protocols for symbols,  so that they list sensibly in alphabetical order. Again so things can be found easily. I use “backwards” naming so that similar items list together e.g. “Basin -  Generic_Recessed_400x250_Plan” rather than “Generic 400x250 Recessed Basin plan”

 

6 hours ago, rexwexford said:

This list would ideally be managed by one person, who makes a revision in the master file, and then all instances of the detail that require the latest info can be selected and replaced


You can do this by referencing individual symbols from the library rather than importing them. There is a danger here though that tender or construction documents could be inadvertently changed by sometone updating a referenced symbol in a library file. So I would tread very carefully here. 
Ive used symbol referencing but only for current parallel projects which are using the same details which are in the preliminary stage, I.e. they are in a state of flux so really good to have all the files update but as soon as projects move to working drawing stage I stop using symbol referencing.

 

6 hours ago, rexwexford said:

  should you have a separate file with all your symbols drawn in (i.e floating in space) and then import them into the relevant drawing files as needed?

As mentioned a favourite file is exactly this however as the symbols would be accessible via the RM they don’t have to actually be placed on a layer in the favourite file.

Link to comment
12 hours ago, Boh said:

I’ve gone through the same process as you  . It has taken a fair bit of thought, time and tweaking to get a system that works well, but I’m pleased to report it has definitely been worth the effort.

 

As @Wessuggested using favourite library files along with project template files I think is the way to go. I would also make the following suggestions:

 

Establish a std class structure that works for your office that everyone shld get familiar with. This is absolutely key (I can’t stress that enough).

 

Your library files are only going to get bigger so they need to be well organised..

Establish a folder structure in the RM of your favorites library files so resources can be found easil even by someone who may not be familiar with the library.

 

Establish naming protocols for symbols,  so that they list sensibly in alphabetical order. Again so things can be found easily. I use “backwards” naming so that similar items list together e.g. “Basin -  Generic_Recessed_400x250_Plan” rather than “Generic 400x250 Recessed Basin plan”

 


You can do this by referencing individual symbols from the library rather than importing them. There is a danger here though that tender or construction documents could be inadvertently changed by sometone updating a referenced symbol in a library file. So I would tread very carefully here. 
Ive used symbol referencing but only for current parallel projects which are using the same details which are in the preliminary stage, I.e. they are in a state of flux so really good to have all the files update but as soon as projects move to working drawing stage I stop using symbol referencing.

 

As mentioned a favourite file is exactly this however as the symbols would be accessible via the RM they don’t have to actually be placed on a layer in the favourite file.

 

Hi Boh, thanks for your detailed response - very helpful. I understand the conundrum with working stage drawings and referencing symbols, as you want to keep previous iterations of issued drawings as a log of design revisions. When you move away from referencing at this stage how do you replace the symbols typically? do you have to replace them all manually? 

 

interested on the class system too, we are also split almost 50.50 using traditional references and design layer viewports in the office. It seems like the class system will be crucial to manage DLVPs as you dont otherwise have a great degree of control of what you are showing when you get to the sheet layer. which do you use? 

 

Link to comment
2 hours ago, rexwexford said:

When you move away from referencing at this stage how do you replace the symbols typically? do you have to replace them all manually? 


Im not sure I understand exactly what you mean here or perhaps we have a slightly different workflow?


Whilst developing drawings many symbols are usually brought into a file. Most will be used as they are. Others may be edited to suit the project. Sometimes new symbols are created or extg symbols will be improved, which in both cases will hopefully be exported back into the library to keep it up date.

 

Occasionally there will be other projects that use these same symbols and so yes they would have to manually be exported into those files too. We don’t do that much repeat work so this is not a scenario we have to deal with too often.

 

We do have repeat clients though and for some of them we can have multiple projects running simultaneously. So we have some library files just for these clients which includes resources particular to them. When we were developing the library files for these clients we did more symbol referencing as we were still developing symbols whilst also doing several design concepts. This made it easy to keep all the files up to date whilst things were rapidly changing.

These library files are now pretty well established and there is not so much updating required anymore.

3 hours ago, rexwexford said:

interested on the class system too, we are also split almost 50.50 using traditional references and design layer viewports in the office. It seems like the class system will be crucial to manage DLVPs as you dont otherwise have a great degree of control of what you are showing when you get to the sheet layer. which do you use? 

 

We also use both traditional referencing and DLVP’s depending on the project. We also use Project sharing , again depending on the project.

 

As well as for referencing, a good office standard class system means files will be be organised in a similar way making it a lot easier for people to work with each other and on each other’s files.


It also means your symbol library can be standardised in terms of classes. Many symbols can be edited to insert directly into the correct class which saves time as well as keeps files tidy.

 

We have developed a pretty comprehensive class system so that wherever possible objects have their geometric attributes defined by class. This has several benefits:

- saves time not having to apply attributes by object

- standardises the drawing presentation throughout a file and between files

- allows viewport overrides to be used. (Vp overrides don’t work on objects whose attributes are not defined by class).

 

The only downside is that you may need a lot of classes! This tho isn’t a major  drawback as there are some easy ways to manage lots of classes.

 

I hope all this is helpful! It felt like a bit of a rant... Let me know if you have any questions. 

Link to comment

Thanks yes very helpful. Yours workflow sounds similar to ours.  We typically continuously improve our 'standard' typology. Therefore if we have a project still on site, and one on the drawing board, it is import to us that although we revise the details  on the drawing board (learning from job on site) we do not over ride the symbols project that is being built. Although these are technically a superseded in the grand scheme of things, they are still relevant to that particular job, if that makes sense. 

 

I think the ambiguity may have arisen from my terminology. When i said 'reference' a symbol, a meant as a file reference to the symbol library file. Perhaps there is a different way of referencing or importing a symbol through the resource manger that I need to look into 

Link to comment

You mentioned referencing via the traditional and DLVP methods which references entire DLs.

Maybe you are not aware of Symbol referencing? The is the referencing of individual symbols instead  of importing them. They appear in Italics in the RM. if you edit a referenced symbol the changes will also be made in the referenced file (any other files that are reference the symbol will need the reference updated).

Edited by Boh
  • Like 1
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...