We have a highly repetitive series of residential units across a large project including bathrooms, internal partitions, furniture etc. In plain old Microstation we would have used cells to group together these elements and place them throughout the design, enabling them to be quickly updated altogether when needed.
However in ABD if we use cells to group together building elements, such as walls, furniture, doors etc then they cannot be seen by the datagroup explorer without first being dropped. An alternative would to be to put the room elements within a dgn and use references instead of cells but it quickly leads to an unwieldy sets of attachments.
Any suggestions as to how to best to handle repetitive groups of objects rather than just repetitive individual objects?
Thanks,Thomas
ABD SS4 08.11.09.593GB Dataset
Use a compound Cell
Ustn since 1988SS4 - i7-3.45Ghz-16 Gb-250/1Tb/1Tb-Win8.1-64bEric D. MilbergerArchitect + Master Planner + BIMSenior Master Planner NASA - Marshall Space Flight CenterThe Milberger Architectural Group, llc
Would Graphic Groups do what you need?
1. This 'side-effect' should be listed in the help menu. If the BIM components like doors etc are 'hidden' from DGS, will this also skew any quantitative take-off's?
2. Eric suggests using a Compund Cell. What would be the workflow? What Family? If you make a CC that comprises DGS elements like doors etc, will DGS / QTO pick them up? Are there not implications for unification, which can not work across families?
Graphic Groups and Named Groups will not update across the project.
Are there groups and subgroups? Perhaps you can use nested references to get fewer attachments?
regards / Thomas Voghera
Thank you all for your responses.
We have tried compound cells but the datagroup information isn't exposed from within the cell. They're great for individual elements or assemblies but for groups of elements, each their own specific and different datagroup information, it doesn't work.
Graphic groups are good for grouping items but updating a number of them at once, as far as I can see, isn't possible.
I think for the time being we will persist with references and look at nesting them as Thomas suggests.
Thanks,
Thomas
Sounds like a CR....?
Amazing that this hasn't come up as an issue before... or has it?
AecoSim can't very BIM-oriented if a simple Ctrl-G screws up the whole 'Single Source of Truth' thing.
I would say that grouping elements is bad practice, simple as. Grouping should only ever be a temporary fix.
If you are grouping items(such as room/apartment layouts) then these should really be done as references, which then allows you to assign logical names etc to each reference, which then produces very detailed and nicely broken down schedules through the datagroup.
references also are the best for updating on a large scale. with cells or graphic groups you will have to update manually.
Nah... Bentley should fix the problem. After they do you'll be singing a different tune : -)
Dominic, there is no "problem" to fix per se since DataGroup catalog types were designed to define what a thing is. So when grouping disparate elements into a single cell what you have is now a "new" element using whatever Catalog type was applied. For example, I could group together five doors into a cell and assign it the DataGroup catalog type Toilet Fixture. Despite containing five Doors, it's now a (very special) Toilet Fixture. :) The closest thing to something like this would be an assembly such as a Bar Joist, but as Thomas pointed out that's really not what he's looking for.
Thomas, using references is the most common way to approach what you're doing. A Duncan pointed out you can use Logical Name to indentify what's what while still maintaining the unique component instances contained within each file. And whenever any of the components within those references is changed in some fashion, all instances update. Plus it accomplishes the "move everything at once" nature of a graphic group.