Skip to Main Content
Need Support? Let’s guide you to the right answer or agent.
Status Needs review
Created by Guest
Created on Feb 26, 2022

Item Types for Elements in Ref Attachments

Attaching nongraphic and parametric info to CAD elements is a key part of delivering and supporting data-centric / BIM workflows.


Mstn's hallmark best-in-class Reference Attachment tool is a key differentiator that undepins the use of federated BIM models. Mstn's inbuilt ElementIDs and other versioning mechanisms are also a key prerequisite for the scalability of federated models.


It is currently only possible to attach Item Types to the elements in the active model. In a federated model environment, the users will need to be able to link the Items Types placed in their models to other elements (and Item Types) in external models, typically Ref attached to their Active models. 'Joining' the data this way is a typical database type task that is inherent to BIM modeling that needs to combine CAD and data modeling. The common approach by others is to force both CAD and data into a single model, which is not a federated approach.


The Attach Item tool needs to also work on elements in the Ref attachment files. Maybe in conjunction with Design History, which should be help deal with any orphaned elements?


One example is cost estimating: the geometry will be produced and managed by a different party to the unit rates which will be produced by the cost estimator, who will also have different classification info. In a federated modeling environment, both models will be separate but will also need to be linked at the element (incl nested element) level. Putting the cost estimator's data in the geometry authors model will be extremely difficult to manage and also quickly lead to bloat, given the number of other disciplines who will want to do the same thing. Not scalable.


https://communities.bentley.com/products/microstation/f/microstation-forum/225579/reporting-from-item-types-in-cells/698169#698169




  • Guest
    Reply
    |
    May 18, 2022

    Hi Dominic, what do you envision happening when publishing data to an iTwin and the same element may have different Item Types - potentially with the same name - attached to it in multiple dgn? What if the same model is referenced multiple times in the same dgn model?

  • Guest
    Reply
    |
    Mar 11, 2022

    Right, so you want to add an Item Type to an element in a reference file but this Item Type will be stored in the master file, so tat it will only be available in this specific combination of Master/Ref file, do I understand correctly now? So you will have one master file per discipline - for example - each containing different Item Types for the same elements in the same references?

  • Guest
    Reply
    |
    Mar 5, 2022
    Hi Marco, I haven't tried it but it but that is not what this enhancement is about. Think of the way Mstn handles Ref file elements. As it loads the info, it adds or overrides it by resymbolising, transforming, rescaling annotation and hatch elements etc. Hugely useful. Any associative dimensions, notes etc in the active model linked to elements in the Ref file are also updated. Similarly, the Ref file elements will have their nongraphic, item type info, which will be Ref attached. But there will always be the need to add more info WITHOUT having to add to the info to the referenced file. Forcing all info to be in a single model has already been tried and is retrograde step. Its the bad old days where everyone tried to get the architect or engineer to attach their cost, fm, product, sequencing, env modeling etc info to the base objects in the 3d model. Quickly proved unworkable vindication Bentley's federated approach.
  • Guest
    Reply
    |
    Feb 28, 2022

    Hi, have you tried using the "Activate Reference" tool?

    The Activate Reference workflow allows you to activate an attached reference file for in-place-editing and attach item types to its elements.


    You can find information on this workflow in MicroStation's documentation


    Regards,

    Marco