Generic Forms - Walls, Wall Assemblies and DG Walls

There are people using DG Walls currently, and I will offer these benefits to using them now (and knowing there are more coming).

• DG Annotation
  • Create a wall annotation tag and a rule to automatically place Wall tags on plans
• Automatic Family/Part Assignment
  • This prevents users from not changing the Family/Part and placing walls with the wrong Part.
• Changing from a single leaf wall to a compound wall (or vice versa) 
• Easy create a DG Catalog of "standard" walls that already have all of the data entered that is typically shown in a partition schedule.  
• DG data is easy to harvest from I-Models using Item Sets for analysis of the model, isolation of elements, model checking, etc.

I am not sure if I completely understand your requests for functionality, but I would recommend a workflow where you start out placing a "generic" wall through the DG based Wall Tool.  Then as you develop the project you can 'modify' that wall and exchange it for a more specific wall or compound wall with the data attached that matches the project (or corporate) partition schedule. 

 I have made the conversion of walls from Family/Part based to DG walls for 2 different companies now, and can attest to it is not nearly as much work as it may seem before you start.  If you are comfortable working with the .xml's directly it is even easier. 

 -Travis

OK - Too many issues

1. Datagroup Annotations only works on plans and NOT section
   This negates the use of an annotation Leaf Tag as I rarely see a plan annotated beyond a wall Tag but always see sections annotated fully to part
2. When Placing a Wall Tag it does not show a line to the wall I've just Tagged.
   This is confusing in tight situations
3. I cannot Place a Wall tag on a Wall that is made of multiple parts or leafs. Only a Wall Leaf Tag
   So with this I cannot tag my Walls as mine are more presice than a two line wall and I don't want to Leaf Tag my Plans
4. When a Leaf Tag is used it does not draw a line to the Leaf being drawn
   Hard to tell what you are describing without a Line and alot of notes
5. Do the Datagroup Infomration Tag Variables have any specific meaning or can you use them as you see fit.
   I was looking for a "Spec" and "Spec Description Variable"
6. Can we add our own Variables?
7. Should we not be able to select our Datagroup Tag???
   I might have a Tag for simple descriptions and one more complicated and large data
8. Should I not:
   Select the Place Datagroup Tag Command
   Select the Type of Wall Tag - "Wall" or "Leaf"
   Then Select the Type of Wall or Leaf Tag as I might have more than one
9. Should I not be able to tag in any type of file whether Section, Elevation or Plan
10. How do I Tag something that is just a Part of Piece - (i.e. Coffee Maker)

These Questions were posed to support today and now I am waiting for an answer

"These Questions were posed to support today and now I am waiting for an answer"

Many of these might qualify as CRs, so in those cases that CR# may be "the answer".

But specifically for # 3, if you select the Wall Assembly "centerline" then you should get the Wall annotation, while selecting any of the leafs should result in the Wall Leaf annotation.   I guess this also applies to # 8 since the DG Annotation placement is more or less "context senstive" based on what you're selecting.

Also, regarding # 1 and 9...   I'm pretty sure I've placed DG Annotation in sections and elevations before and don't ever recall seeing any problems to speak of.   Maybe there's some setting coming into play...

Our walls don't have centerlines since a contractor cannot build by a centerline - he buids by an edge.  Many of your parts also don't ahve a centerline.

So is there some switch I need to show a centerline to select.?

Also I cannot find out what some of thsi data refers to??  See Picture 50199???  Compound Parent???

?Part Definition?  Could not be 0'-0"

And Wall Function - that is not listed in the Part definition

The Section does work now - why I don't know.

However as you can see I need better Data - where does this data come from

Attached is the section and you cannot tell where the data goes to and even if it did fill in family

And I need a line to the Data

I also want to ANNOTATE other than walls and Assemblies.  What about everything else that does have a part assigned.

Any HELP????  Tech Support does not know.

Any HELP????  Tech Support does not know.

Well, as you mentioned below there are really too many items outlined in this thread.  Not to mention that the topics continue to morph slightly from post to post, making it difficult to know what the issues actually are.

I would suggest picking whichever issue is the most important, describe that as succintly as possible, and go from there.   Because if the ticket submitted to support resembles this thread, I don't think that's going to get very far either!

A.  The most important is that BA must follow standards for us to work in the world.

      For this be compatible with MasterSpec, Uniformat, Sweets, AIA, CSI, Timberline, COBie, IFC, etc.

B.    For this we need good Parts List and Good Assemblies

C.    It must be quick and easy to use.  In other words - be transparent to use and never impose on production.

1.  We need a Parts list based upon MasterSpec.  We can all share and it is compatable with the industry.  It must include the standard place ti write spec anme and description.

2.  We need and assembly based upon Uniformat.  Only estimators will recognize the assemblies.  But Uniformat gathers it's stuff for MasterFormat to begin with.

3.  Then we need an automatic way to create a DG Wall from the Assembly without any input except the Instance Data..

This all needs to be brought out of the 1980's and into 2010 with quality and userfriendly dialogs and controls.  NO MORE XML SPREADHSEETS.  they can be in the background for power user stuff but not for one-to-one work.

THEN IT NEEDS TO WORK. - KEYNOTES, PLAN NOTES, SECTIONS NOTES, RENDERING, PLANS AND SECTIONS THAT LOOK RIGHT, ETC.

This entire peice was started to show there is no direction and you CANNOT even develop a solution with weeks upon weeks of discussionn.

Steve,

Getting out of the 80's:

Can I suggest that the BA dev team look at B-Processor..... or something like it. B-Processor is an open-source app currently being developed in Denmark. Maybe Bentley could join in? The short presentation and video tutorial links are worth looking at.

B-Processor is designed from the ground up to address a lot of the data-centric problems and aspirations that we would recognise as 'BIM' today. And, it does this from the architect's view, to boot.

In comparison, BA's addition of DGS in 2004, and now the SpacePlanner database seems to be a more fragmented and tentative approach to BIM.  

B-Processor provides a more holistic modelling experience, based on a simple way of aggregating building objects around spaces and nested 'Chinese boxes' as a way of handling BIM objects, which intrinsically integrates BIM requirements like building product classification.

A lot of inter-element dependency and propagation functionality is becoming available. PowerCivils has its Civil Geometry, the GIS guys have XML-based feature modelling, the plant guys have OpenPlant etc, and building has GC.

I think GC is great at what it does, but it will need to change a bit before it will be able to do 'BIM modelling'. OTOH, GC's parametric spreadsheet-type propagation is a powerful tool. To participate in BIM modelling, GC features have to function within a BIM data model / data base. Is DGS's xml store really suited to keeping up with and maybe even managing GC features?

GC BIM features seems to be a tool that is 'looking for job' at the moment. I think that the idea is that the GC designer is going to script some walls (because it's too complex to be done manually, presumably) and throw it 'over the wall' to the BA user. But, the moment the wall is modified, the propagation chain is broken (BA has no history mode) and any revisions on the GC side will be pretty problematic. This kind of interoperability disconnect makes GC more trouble than it's worth in most professional situations. Users should be able to script and iterate the GC construct in its 'BIM' context.