There are some good points here and agree with much of what has been said. My original question was primarily motivated by the desire to access the data as Robert describes and not be restricted to either having assemblies of elements treated as either: 1. a compound cell or PCS type element with just one set of overall attached data but easily moved around and replicated; or 2. as separate elements all with their own relevant data but without the ease of manipulation in terms of copying and then updating. I agree with Duncan that references provide a more robust way of dealing with repeated elements (logical names for analysing the data, doesn't require the updating that shared cells do) but as ckeischar rightly points out I think there could be problems in the long run with potentially hundreds of attachments. I currently have a hotel with approximately fifty rooms per floor so each floor model requires fifty references just to deal with the rooms alone, and if different types have the same bathroom then there's an issue about whether to nest the references so it's modelled once or model it in each type and update in turn. I think this issue occurs at a range of scales: in the past I have had situations such as a window assembly with deep reveals that require a plasterboard return which is easily modelled within a compound cell but then isn't included in quantity takeoffs leading to either those elements having to be modelled outside the cell and therefore managed separately from it, or incorporating them within the cell and writing the desired information into the metadata for use in schedules which is then carries risks of not being updated, not deriving from the model itself etc.
↧