• State Not Answered
  • +1 person also asked this people also asked this
  • Replies 16 replies
  • Subscribers 92 subscribers
  • Views 8255 views
  • Users 0 members are here

Refresh Auto Annotations Per Selection Set : ABD 593

Jeff D
Offline

"Fear of the Refresh Button"

I'm finding on larger projects, where each floor breaks into multiple sheets, that refreshing auto annotations can/will undo much more work than it updates.

Workflow, as standard, is create ductwork/piping/plumbing, then dynamic view, then drawing model and sheets.  (Presently the only auto annos employed in drawing-model are Top, Bottom, Centerline, and Invert-Level start/stop elevations).  After the drawing model is created, It's necessary to do some custodial work for presentation and re-arrange auto-annos, delete unnecessary auto-annos, and add DG anno cells.  Now if a small group of components change elevation in the design model (e.g. a 15' run of 8x6 duct lowered 2" toward the floor), refresh auto annotations will reflect that change in the drawing model, but will also undo 60-70% of the custodial work throughout the whole floor.  Depending on the size of the floor, redoing the custodial stuff can be extremely time consuming.

The items that are undone are all the deleted auto-annos, some of the re-arranged auto-annos, and the DG anno cells that were placed that indicate vertical components (like duct that passes thru to the floor above or below). The later just disappear, the former reappear.  (Oddly, only 40% of the re-arranged items are reset to default locations, the rest stay where I put them).

The only workaround I've discovered applies only to the DG anno cells mentioned above. If I drop them once then they will survive a refresh, but the drop forces them to lose their association with the component.

...and here's the request:

1. Please allow the Drawing Composition Task "Refresh Automatic Annotations" to present a tool-settings option: "Refresh Per Selection Set".


This would actually eliminate two issues I've experienced with "Refresh":  ...As noted above, and the "Visibility Calculator took longer than expected!" thingy.

Thanks,

Jeff

Parents
  • 0

    Cutodial work being overwritten....

    communities.bentley.com/.../81233.aspx

    communities.bentley.com/.../68191.aspx

    communities.bentley.com/.../192412.aspx

    communities.bentley.com/.../91409.aspx

    .... I think that the moved annotations only retain their 'custodial' manipulations when they are generated with rules then manipulated.

    It would be good if Bentley would address how to 'persist' custodial work more effectively/easily, soon.

  • 0 Offline in reply to dominic SEAH

    The more I think about it, the more I see that "refresh per Selection Set" is The way.  Very logical.   It's similar to changing properties;  If you need to "change level" of a single line amongst 10,000, you can select that single line and do it without affecting the other lines.  Why is there a Selection Window?  Why is there a Fence??

    Well here's my work-around (as copied from my personal notes):

     Select and Group everything desired to be untouched by "refresh".  "Locking" the Selected will not work.  Perform the refresh.  As well as the area that needed the Refresh, everything will be regenerated to default (as defined by drawing Rules).  The grouped items will remain as they were (unaffected), and you'll now have tons of duplicates that need to be deleted; Just don't use a crossing window to select stuff to delete, cause you don't want to delete the big "group".  Also be sure to not delete the new stuff that even made you do the refresh.  Now, after the delete step, ungroup the big "group", and you'll have effected a localized refresh with annos retaining associations.

    Again, ...must see function for localized refresh: "Refresh Per Selection Set".

  • 0 in reply to Jeff D

    Unknown said:
    The more I think about it, the more I see that "refresh per Selection Set" is The way.  Very logical.

    The work flow you describe is just one use case. Persisting changes to the 'custodial work' or tons of 'embellishment' that is required to make what DV/BV outputs usable has been discussed many times in the past.

    The other way you could do things is to 'smart copy' the Drawing Model content that is generated by BV / Drawing Rules. If the Drawing Model is Ref'd as a CVE, you have the option to Copy/Hide elements. Why not use the Copy/Hide process to convert the annotation elements into slightly smarter annotation elements. The smarter annotation element would allow the user to 'lock' whatever he wanted. Maybe, the annotation text would be automatically converted to Fields that point at the original (hidden) BV/DR-produced text.

    You could even use Mstn's Named Group logic to make each bit of information either active (any changes made to the info automatically propagates to the other members of the group) or passive (any changes from other members of the group will update the local info, but any local changes will not propage to the rest of the group).

    Converting the 'graphic-centric' Text into 'data-centric' Fields allows the user to re-arrange the way the information is presented while retaining the vital links and dependencies that are needed to keep the information synchronised. Mstn's DV's and, by extension, BV's already work a bit like this by generating 'proxy graphics'/Element Handlers that provide different representations or re-symbolisations of the same element.  A beam is represented one way in 3d, another when its cut, another way when its resymbolised as single lines in a structural layout etc etc.

    What you are experiencing and want to do is not new. I think you will find that it is the tip of the iceberg in a BIM environment, where you will need to synch with others across disciplines / silos.

  • 0 Offline in reply to dominic SEAH

    Tip of the iceberg for sure.  Thanks for all the reading.  ...lot to digest.

    Nice to know I wasn't first to think "selective refresh(updating)", (CVE or auto-anno) ...while we wait. :)

  • 0 in reply to Jeff D

    No probs. You may also want to have a look at this thread. As with your use case, a lot of 'annotation' will increasingly be extracted from 'non-graphic' attributes that are attached to the graphic elements. The old days where the CAD graphics are done first and 'dressed up' manually, relying on the user to match door tags to the right door for example, are beccoming something to avoid... in the BIM world.

    It seems to me that AecoSim is over-reliant on Drawing Rules / BV processing to update 'data' that is presented as annotation, at the moment. When BV updates a BV, it updates the graphics and the data. It runs its Visibility Calculator and resymbolises / re-generates all those Annotation Cells, Text elements etc as graphics. What seems to be missing is a way to bypass all of that heavy lifting, and maybe there should be an option to start with the annotation cells in the model and harvest the non-graphic attributes that the annotation cell is associated with, so that we can update/synch just the 'data' and not the 'graphic' as a whole... ie using BV to get the 'data' as a byproduct of the the 'graphics' when all we want is the 'data'.

    Harvesting from the generated annotation elements will catch the modified and deleted info, but won't catch any new elements requiring annotations. I suppose the 'Update Annotation' tool could scan the model based on the Drawing Rules used to generate intial annotation and generate the newcomers.

Reply
  • 0 in reply to Jeff D

    No probs. You may also want to have a look at this thread. As with your use case, a lot of 'annotation' will increasingly be extracted from 'non-graphic' attributes that are attached to the graphic elements. The old days where the CAD graphics are done first and 'dressed up' manually, relying on the user to match door tags to the right door for example, are beccoming something to avoid... in the BIM world.

    It seems to me that AecoSim is over-reliant on Drawing Rules / BV processing to update 'data' that is presented as annotation, at the moment. When BV updates a BV, it updates the graphics and the data. It runs its Visibility Calculator and resymbolises / re-generates all those Annotation Cells, Text elements etc as graphics. What seems to be missing is a way to bypass all of that heavy lifting, and maybe there should be an option to start with the annotation cells in the model and harvest the non-graphic attributes that the annotation cell is associated with, so that we can update/synch just the 'data' and not the 'graphic' as a whole... ie using BV to get the 'data' as a byproduct of the the 'graphics' when all we want is the 'data'.

    Harvesting from the generated annotation elements will catch the modified and deleted info, but won't catch any new elements requiring annotations. I suppose the 'Update Annotation' tool could scan the model based on the Drawing Rules used to generate intial annotation and generate the newcomers.

Children
Communities
Support and Services
Training and Learning
Social Media