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.
Maybe start a list of the end products needed. I think if we solve this we develop the solution.
Room Finish Schedule
Door Schedule
Window Schedule
Property Inventory (customizable of items associated to an element)
Editable outside Microstation (ie access)
Can use something like a database to work the data as that is more powerful than a spreadsheet
Table of Contents
Index of drawings
Ustn since 1988SS4 - i7-3.45Ghz-16 Gb-250/1Tb/1Tb-Win8.1-64bEric D. MilbergerArchitect + Master Planner + BIMSenior Master Planner NASA - Marshall Space Flight CenterThe Milberger Architectural Group, llc
Eric is right on this
Storing in dgn with elements, be it a door or a text element like a drawing number.
Editing in Excel/Acess/OO Calc+Base
I have said it before: drag and drop a bunch of dgns on Excel and see the elements with their attached data, edit and push back to dgn as well as use in drawing lists, schedules etcetc.
regards / Thomas Voghera
David,
Thank you for the responce.
You have it correct on how things have worked over time.
From my standpoint this all appears to be being built backwards. From the top down. AECoSim develops their data set, builds a framework and then may add some code to MS to handle it. OpenPlant does the same. OpenRoads, etc. All the data structure comes from the verticals and gets tacked on to MS in the end.
This is because over time acquisitions have happened and developed on what they had in the past.
We are continuing to make great strides on the various items that are mentioned in this thread. As those of you who have talked to me over the past years will know this exact topix is very near and dear to may heart and something I am striving to make better. Please watch for the upcoming EAP (Early Access/Adopter Preview/Program) to see more of our direction on this topic.
Thank you everyone for the great discussion.
John
Unknown said: Please watch for the upcoming EAP to see more of or direction on this topic.
Please watch for the upcoming EAP to see more of or direction on this topic.
EAP?
stuartw said:EAP?
Seventy-five possibilities found here. Most likely Early Adopter Program. HTH.
Regards, Jon Summers LA Solutions
Controlled rumour-mongering coming thick and fast now - promising, exciting - time to resume my Select sub?
Unknown said: EAP? Seventy-five possibilities found here. Most likely Early Adopter Program. HTH. [/quote] John, I would say that you are in the wrong job. You should be on a stage as I haven't stopped laughing yet!!
[/quote]
John,
I would say that you are in the wrong job. You should be on a stage as I haven't stopped laughing yet!!
Some food for thought regarding the need for scheduling muscle inside Mstn.
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?