Mstn has quite a few tools that work by manipulating existing elements when they are loaded or copied whilst leaving the original elements untouched:
1. Reference attachments:
a. the original models are moved, rotated, scaled, clipped + masked, etc when they are loaded.
b. the elements in those models are re-symbolised using Element Templates, Display Styles, Family+Parts assignments.
c. the elements may be filtered by their Named Group (which may be generated by Item Set criteria) attributes.
d. they may even be re-generated (and linked back the original geometry?) if loaded as a CVE attachment.
2. Annotation Scale: the original text, cells, dimension elements, custom linestyles.... within those references are loaded.
3. Compound cells: ABD-vertical 2d 'symbolic' versions loaded in lieu of the 3d version.
4. Feature / Property Based Annotation, Arch/MEP/Structural Drawing Rules.
5. Rendering Materials: the elements material attributes may be assigned/overriden by external look up tables when displayed/rendered.
Mstn has a few tools that work on elements that are copied through from other models:
Materials: there are tools that look at re-assigning or 'transforming' material names when a cell or other element is copied through.
Feature or ECXAttribute-type 'Business Info' tagged to elements:
What happens when the graphic element or 'object' is copied through? Is the schema info 'deep' copied through and synchronised / concatenated with the active file's project dataset? In this BIM-obsessed world, when you copy an element through into the active model, you need its non-graphic info / intelligence baggage as well. Not only for the cost control bean-counters, but also for 'property based annotation', the analytical apps to avoid reconstructing the models all the time, change tracking etc etc
Bentley even has tools that can make far-ranging 'transformations' to the schema info when exported to i-models using scripted rule sets. It is even looking at 'transforming' foreign attribute sets.
But what about the 'internal' schema info? Mstn even as some tools for that. Can the 'Find and Replace' tools be scripted using the same rule set and graph-based intreface as i-model transformer?
I-model transformer (and maybe the Item panel in future) workflow looks very similar to the way Ideate's BIMLink works... especially if Mstn's Items: Detail panel's grid of attribute cells can be synchronised with Excel. The Items panel can already export to Excel (no need for i-ware ODBC driver). Maybe one day it will be able to synch the changes in the Excel sheet back to Mstn like Ideate can with R***t.
Ideate becomes very interesting when combined with R***t's Copy Monitor functionality. Ideate uses Excel as a 'bridging space' where multiple 'schemas' can be exported to separate tabs and linked in order to allow changes to parameters/attributes in one file to be monitored, transformed and propagated to the monitoring file.
Mstn's Ref file functionality continues to be great, but this kind of 'referencing' at a more granular level will be more and more important in the BIM info-modeling world. I suspect that this is nothing new to the DataManager or Promis-e etc guys pushing/pulling data between electrical and plant databases... but the Copy Monitor workflow seems a lot more flexible as it does not rely on a central DB and leverages the fact that Excel is a pretty prevalent skill.
Maybe, i-model Transformer tool should be part of the Ref attachment loading process? Taking the example above, say you are the MEP engineer and have to label your drawings with room tags defined by the architect, but the tags will need to be pushed around because you need to accomodate other annotation. The existing Mstn Ref attachment process is no help. An i-model Transformer-enhanced workflow would load the architect's floor plan drawing model with the annotation levels off, but extract the room name/number info into an Excel worksheet, which is then propagates to your worksheet, which is then used to update your annotation cells. You can move the annotation cells as you need to and avoid having to re-type the text info everytime the architect makes a change. You could also have annotation that is dependent on the architect's room naming/numbering. The graphic info is de-coupled from the non-graphic info ... in a data-centric way, not just the old skool graphic-overlay way of working.
Maybe the Excel table could be saved as a 'schema' internally?
Maybe this can be an outgrowth of the CVE attachment functionality, where the cached geometric elements are still linked to their originators. Compare commit time stamps in the incoming model to index those attributes that have changed? Using the same tools under the hood power Design History?
CVE has a nice Copy + Hide option that is granular enough to hide individual elements. This could be used to selectively replace or 'transform' some if not all elements on a common level. You could move some elements by Copy + Hiding those Room tags for example, while leaving the bulk untouched. Always good to minimise overheads.
i-model Transformer could even provide multiple 'transformations' based on a DAG of rules-based search and replace nodes... when a Ref/Active model is loaded or something is copied through.
GC already has tools to read and write to Excel files. Maybe GC scripts should be able to be called as part of i-model Transformer's scripts... saved with the dgn like GC's scripts.
GC already has tools to load and align Ref attachments to defined ACS'. This would be one way to lend the Ref attachment process a bit more intelligence.
Maybe i-model Transformer should also be the scriptable 'head end' to manage anything that is currrently tagged with the 'Annotation Scale' attribute? Mstn already has a performant way of doing the scaling transforms 'under the hood'. You could then have different scalings in the same model.
I wonder if the other transforms like move, rotate or mirror or non-uniform scaling can be just as quick. And how granular could you go? Can this be combined with Design History?
Design History can already store the transformation info at a granular level. Maybe a 'moonlighting' variation of DH could be used to make an associative copy of an element in a Ref or even in the active model. Say you have the Associative Lock on and copy an element. The element gets tagged with 'Annotation Scale''Associative' tag, and DH would record the modifications and keep track of the preceding element so that any subsequent changes would be tracked.. and propagated... using the same powerful rules that the Named Groups' Active/Passive, to/from other member propagation control uses. All Mstn manipulation tools would need to call the DH tool to check if the element has its 'association' tag set and update those values appropriately. If an associated element has its Rotation value set to 'Change Propagation: To other members: 'Always' or 'Group Lock''... then the DH tool would update the associated member fields accordingly. If one of the associated elements has its member fields set to 'From other members: 'Never''... then that particular element would be excluded from any updates from from its associated elements. Pro/E has a similar two-way propagation control.... to allow components to be 'derived' as variations of a original, not just clones.
I can see this being very helpful when combined with the new CVE Hide+Copy tool. For example, there a lot of times where the CVE linework symbology will need to be modified, but the geometry kept 'live' / Ref'd. Say a roof outline needs to be always needs to be thickened up in terms of line weights, or a joint always removed or re-symbolised with another line style. DH already records the changes in symbology...
The elements would be copied into the active model and the changed member fields modified and its Change Propagation bit set to 'From other members: 'Never''. DH keeps a link between the modfied element and hidden CVE element (presumably still stored in the active model). And CVE keeps a link between its proxy geometry / Element Handlers to the original geometry... so that changes in the original element propagates selectively/correctly downstream.
What if the user 'associatively' copies an element from a normal Ref attachment and not a CVE? The Ref may even be under active manipulation by another user. Maybe DH can push a request to the remote file to tag the associatively copied element(s). The DH session on the receiving end would need to queue the tagging in at the appropriate moment. If the file is not loaded, the pushed request would just be processed the next time the file was loaded.
When the user reloads his file, Mstn would load each Ref and compile a list of changed associated elements, skipping over those DH knows haven't changed, and sort them for updating super fast.... like Annotation Scale does currently?