Non-graphic attribute toolsets

This was split from this thread:

There are too many non-graphic attribute types with incomplete toolsets to fill a niche. Templates, Tags, Items, Fields, Data Fields, Display sets, Graphic Groups, Marks, Links, Text Nodes, MS Links....

These need to be unified into a cohesive database environment with a functional set of tools than can query, display and be edited either graphically or in a Table (Querry View) and as a Text Label. Additionally the need to to joins on data tables across multiple DGN files.

Parents Reply Children
  • Some food for thought regarding the need for scheduling muscle inside Mstn.

    " Is Exporting the Solution?   

    Once a schedule is exported the link between drawings and the schedule is lost. Any changes made in the spreadsheet or database software will not be reflected in drawings. And any changes in drawings made after the export will not appear in the schedule.

    So what, you might say,  that is how we have always done it. If someone makes a change they have to "talk" to others so they can do what is necessary to keep the two aligned (see my views on this in the comments of this epicBIM post).
    But this where errors creep in. Even if this talking happens, there may be a misunderstanding, it may get forgotten, other priorities may mean it does not get done in a timely manner.

    In my experience all but the very small and simplest schedules done this way are full of errors.

    Which is why owners and contractors are increasingly insisting schedules be directly generated from BIM models.

    So exporting schedules is not a solution. Either the schedules need to be fully managed in the BIM authoring software, or there needs to be a two way link between the BIM software and the spreadsheet and /or database software."

    "Relying on external software is a valid strategy, but my concern is it removes responsibility from the BIM software houses to provide workable solutions. Instead of one group spending thousands of hours coming up with solutions many groups spend millions of hours on multiple solutions to the same problems."

  • Please remember that Excel / spreadsheets are used by engineers as well as draftsmen as a design as well as an annotation tool.

    Mstn needs something like iLogic or maybe even GC to manage the updating between Excel and Mstn's internal parameters.

    Parameters should be avalaibe to be referenced from othre dgn's as well as Excel. Interesting 'side-feature' of Inventor is that an excel range 'referenced' from an external file (excel) can be added to locally. Another example of 'data-centric' handling or 'referencing' of info that anyone who has used Mstn's Ref tools would immediately recognise.

    ILogic seems to be able to manage bi-directional updates... I think you could get GC to do something similar with a timer function? It's important to remember that spreadsheets and Mstn need to be closely and dynamically linked to yield design productivity and contribute to the engineering process.... by providing immediate feedback. The old skool uni-directional stuff is still valid but needs to be a subset of something smarter.

    Scia's DesignForms are a good example of how smart spreadsheet integration needs to be in order to secure those productivity gains. There are plenty of structural engineers who are pretty fly with spreadsheets, but are pretty cut-off from the actual 3d model. DesignForms provide a means to allow engineers to author and generate their own calculation steps in a form that allows automation of repetitive tasks ... i.e productivity.

    I think Mstn should follow the MCAD world and integrate parameter managment / spreadshet tools, and provide the graphic and scripting backup to make this accessible to users. An example of graphic presentation of parameters. Seems like a lot of this is already in GC... and maybe in PCM?