I'm in a bit of a pickle.
I am working on a very large project, and we are unfortunately making some major changes "under the hood" to make the project files more lightweight. For example, all of our object families have been rebuilt, and we are poised to replace all the old content with new lightweight content. All of our old content was built in the furniture system category. The decision was made to differentiate our content families into the correct categories (furniture, plumbing fixtures, casework etc.). We have a reliable method for swapping the old content for the new content families, with the new categories.
Here's the problem.
We have by now 100s of views and sheets, complete with annotation. Annotation is specific to family category; ie furniture system annotation tag is only applied to furniture system object families. Therefore, when an object changes from furniture system category to casework family, any attached annotation tags in any view is deleted. 100s of annotated views in about a dozen project files.
I would rather not tell the project team (over 100 architects and engineers) that all the annotation is going to be flushed down the drain.
Three methods i am imagining:
1). Develop a method for changing all the annotation tag categories into multicategory tags before i swap out the content. Multicategory tags are not affected by changes in object category.
2). Develop a add-in for querying the existing annotation tags for parent object, location, view name, leader and then replacing with annotation tags of the correct category in the same place. Deus ex machina.
3). Brute force by slave labor to reapply all annotation tags according to pdfs.
Anyone have any bright ideas?
Solved! Go to Solution.
How about not replacing the families? If you're this far along in production, what benefit are you going to gain by re-categorizing the families? If it's just to reduce the file size, it hardly seems worth the effort.
Also, why in the world would you have built all the families as Furniture?!
As a 4th option, if you're dead-set on replacing all the families, then you could use Tag All Not Tagged, rather than manually tagging each one.
I actually agree with you about that it would be better to not change the family category. And unfortunately our families were provided by a consultant who thought that categories were not important.
That said, I'm on the receiving end of a chain of poor decisions. The families are going to change categories and all our annotation is going bye bye.
Tag-All-Not-Tagged is usable, but is a blunt instrument. Each view needs to be individually retagged. I call this the brute force with slave labor method.
I'm at least glad you share my frustration.
I feel for ya, then. That's a bad mess to inherit.
Step 1: Fire that consultant immediately, and do everything you can to make sure they never work with your firm again. In fact, they should share the cost associated with having to correct their work.
Step 2: Tag-All-Not-Tagged and hope for the best. Then clean up as required.
Step 3: Drink heavily (before, during and after).
...and we have a solution! It took some clever programming, but we have managed to replace all furniture system tags with multicategory tags, in exact placement, in all views. Those searching for a solution to a similar problem can take solace in that it is a fixable issue.
The specifics are a bit complex, but in a nutshell we programmed a macro in C# that searches for annotation tags (furniture system), and captures information related to view name, parent object, leader(y/n), location in view, etc., and then places a new multicategory tag with that same information. It works, although it takes some time to churn through our thousands of view in our project, but it is definately better than doing new tags by hand (i hate doing work twice!).
Start with some of our most frequented solutions to get help installing your software.