Accessing Element information - GC

Afternoon,

i'm trying to access the element information via GC and then export the information to excel in a structured way.

does anyone know how to get the element information?

Thanks 

Parents
  • All output properties that are available on a GC node can be written to Excel using the ExcelRange node. The ExcelRange node is available after loading the Bentley Product Assembly Bentley.GenerativeComponents.Office.dll.

       

  • thanks for that, i'm aware that this allows me to read/write data to excel however i'm struggling to get the information out of the element specifically the Element ID and Cell name. do you know what cell i can use to access this information? Thanks in advance
  • Wow! What else can you do by accessing the assemblies provided by GC?
  • With appropriate hyperbole: anything is possible!

    By design, the extensibility of GenerativeComponents is one of its intended strengths. There are so many things that can be done that even I cannot comprehensively enumerate them all.

    Here is a list of how extensibility in GC works:
    By modeling assemblies of nodes and encapsulating them as Generated Node Types (GNT). No coding required. Note that these assemblies of nodes may include nodes using the ByFunction technique.
    By using expressions in input properties of nodes (e.g. Length entry for line02.ByStartPointDirectionLength could be "line01.Length + 5.0"). Minimal "coding" from basic math expressions and calling built-in or scripted functions to more advanced one-line logical, search, and lambda expressions.
    By writing Script Transactions using C-language control flow (if, while, for, foreach, etc.). A step up in scripting/coding.
    By writing/scripting functions (C/C# syntax) and adding them to the available built-in functions. Another step up in scripting/coding.
    By using those or anonymous functions to generate nodes using their ByFunction technique.
    Any coding/scripting is supported by GC's built-in development environment, the Script Editor, with Statement Builder and auto-completion lowering the coding threshold.

    Access to assemblies that do not expose function libraries to GC's list of functions is available by unpacking the sample solution (C#) and then coding extensions to GenerativeComponents using a bona fide development environment, e.g. Visual Studio. Note that assemblies' APIs may need proper wrapping as shown in the coding example in order to expose them to GC application users.

    I hope I did not miss something...

       

  • Unknown said:
    Here is a list of how extensibility in GC works:
    1. By modeling assemblies of nodes and encapsulating them as Generated Node Types (GNT). No coding required. Note that these assemblies of nodes may include nodes using the ByFunction technique.
    2. By using expressions in input properties of nodes (e.g. Length entry for line02.ByStartPointDirectionLength could be "line01.Length + 5.0"). Minimal "coding" from basic math expressions and calling built-in or scripted functions to more advanced one-line logical, search, and lambda expressions.
    3. By writing Script Transactions using C-language control flow (if, while, for, foreach, etc.). A step up in scripting/coding.
    4. By writing/scripting functions (C/C# syntax) and adding them to the available built-in functions. Another step up in scripting/coding.
    5. By using those or anonymous functions to generate nodes using their ByFunction technique.


    Any coding/scripting is supported by GC's built-in development environment, the Script Editor, with Statement Builder and auto-completion lowering the coding threshold.

    Unknown said:
    Access to assemblies that do not expose function libraries to GC's list of functions is available by unpacking the sample solution (C#) and then coding extensions to GenerativeComponents using a bona fide development environment, e.g. Visual Studio. Note that assemblies' APIs may need proper wrapping as shown in the coding example in order to expose them to GC application users.

    Not sure what you mean here... do you mean that say if Mstn or ABD has dotNET dll's in their Assemblies folders, the user can use Visual Studio to access the functions in them? When you say 'coding extensions' is this the same as 'writing wrappers'?

    It would be good to see some examples of how this can be done... in the GC CE SDK?

    Also, it would be good to be able to access Mstn and ABD tools, like Dynamo can directly access Revit elements.

    1. Selection- A node that selects all Elements at a specified level, of a Category, Element type (ABD Wall, Beam, Slab etc), by Name, bounding box, Item , Element Template info or vertical-specific info like ABD's Datagroup / Family and Parts info... sub-element entities like vertex, edge, face etc using Mstn/ABD's inbuilt scanning tools.

    2. Access and use Mstn and ABD commands, functions. So, after selecting say a bunch of ABD Walls, GC should be able to use ABD's tools to make modifications to the geometry (not just the attached DGS or F+P info.

    Once GC has access to the 'raw' or foreign element's info, it can use its own extensive tools to generate geometric info and insert the information back into the foreign element. In this example, the Revit element's vertex info was extracted and passed to the Dynamo node, when then passed to a Curve.Offset technique to generate a second curve, whose vertex info was re-inserted into the Revit element.

    Mstn and I assume ABD eventually will have published schemas. Will this information be used to help the 'extension' or 'wrapper' writing process easier?

    3. What about accessing and modifiying Mstn's Sheet Index or Saved View names? This is a standard Dynamo party trick. I suppose a lot of the methods are now exposed in the new NET API in Connect? Hopefully, no wrappers or whatever in Visual Studio is not required. Hopefully, ABD will follow suit with its Floor Manager and Grid tools.

  • Hi Dominic,

    (1) One way to achieve this is with a Query expression. To select all Point nodes in a GC model, you'd use the Expression
    from n in Nodes() where n.Type == typeof(Point)
    This type of expression can be expanded by checking for values of properties, etc.
    (2) ABD node types can be generated based on ABD elements (e.g. Walls), then modified in the way typical for GC and written back as ABD elements. This is aligned with the divide-and-conquer approach of Bentley applications using the ease of DGN-file referencing.
    (3) We have started working on documentation workflows; however, I think, we will stay away from mere party tricks and rather focus on supporting workflows in a manner that make party tricks unnecessary.

    Regards,

    Volker

       

  • Unknown said:
    (1) One way to achieve this is with a Query expression. To select all Point nodes in a GC model, you'd use the Expression
    from n in Nodes() where n.Type == typeof(Point)

    This type of expression can be expanded by checking for values of properties, etc.

    I thought that you might say that. It would be good to see some scripts for this and maybe even nodes per Dynamo included in GC. The nodes should include the ability to take a selection set made using Mstn tools like Select, Fence, SelectByCriteria and the new Query tools.

    Unknown said:
    (2) ABD node types can be generated based on ABD elements (e.g. Walls), then modified in the way typical for GC and written back as ABD elements. This is aligned with the divide-and-conquer approach of Bentley applications using the ease of DGN-file referencing.

    I think that you are describing the old 'GC is an island' way of doing things, where anything that is manipulated by GC has to be promoted. The approach Dynamo offers is far more flexible. By selecting and processing the element using the elements own functions; and subsequently saving the results, Dynamo allows the element's original tools to further manipulate the element freely. This allows Dynamo to be a lot more surgical and useful... as a geometry manipulation-savvy VBA-type automation tool. VBA and the other macro generating tools are pretty bad at geometry-manipulation processing.

    Unknown said:
    (3) We have started working on documentation workflows; however, I think, we will stay away from mere party tricks and rather focus on supporting workflows in a manner that make party tricks unnecessary.

    I wouldn't dismiss the ability to access data structures / tools in the base app too quickly. The Sheet Index is only one type of data. Mstn CE has taken a big step to recognising that in the BIM world, 'modeling' non-geometric data is increasingly as important as modeling geometry. You may be right in thinking that there is VBA, Named Expressions, i-model transformer / Items stuff for that already, but I can see those tools benefiting from GC's graph, visual programming interface.

    Even if GC does not merge with say i-model Transformer, It would be good to explore/show how GC would be able to interop with these other datastructures / tools. Can GC call the Mstn's Named Expressions? Or the new Items SQL Query tool?

    I know the answer is probably yes, but if past performance is any clue, there will be a lot of stumbling blocks for the guys in the field and low discoverability.

    You know, I noiticed that the ABD crew (Mary Chib, Paul Wagner etc) have been quite good at doing SIG meetings every month. Maybe GC should start a monthly SIG as well? There seems to be lots to show...?

Reply
  • Unknown said:
    (1) One way to achieve this is with a Query expression. To select all Point nodes in a GC model, you'd use the Expression
    from n in Nodes() where n.Type == typeof(Point)

    This type of expression can be expanded by checking for values of properties, etc.

    I thought that you might say that. It would be good to see some scripts for this and maybe even nodes per Dynamo included in GC. The nodes should include the ability to take a selection set made using Mstn tools like Select, Fence, SelectByCriteria and the new Query tools.

    Unknown said:
    (2) ABD node types can be generated based on ABD elements (e.g. Walls), then modified in the way typical for GC and written back as ABD elements. This is aligned with the divide-and-conquer approach of Bentley applications using the ease of DGN-file referencing.

    I think that you are describing the old 'GC is an island' way of doing things, where anything that is manipulated by GC has to be promoted. The approach Dynamo offers is far more flexible. By selecting and processing the element using the elements own functions; and subsequently saving the results, Dynamo allows the element's original tools to further manipulate the element freely. This allows Dynamo to be a lot more surgical and useful... as a geometry manipulation-savvy VBA-type automation tool. VBA and the other macro generating tools are pretty bad at geometry-manipulation processing.

    Unknown said:
    (3) We have started working on documentation workflows; however, I think, we will stay away from mere party tricks and rather focus on supporting workflows in a manner that make party tricks unnecessary.

    I wouldn't dismiss the ability to access data structures / tools in the base app too quickly. The Sheet Index is only one type of data. Mstn CE has taken a big step to recognising that in the BIM world, 'modeling' non-geometric data is increasingly as important as modeling geometry. You may be right in thinking that there is VBA, Named Expressions, i-model transformer / Items stuff for that already, but I can see those tools benefiting from GC's graph, visual programming interface.

    Even if GC does not merge with say i-model Transformer, It would be good to explore/show how GC would be able to interop with these other datastructures / tools. Can GC call the Mstn's Named Expressions? Or the new Items SQL Query tool?

    I know the answer is probably yes, but if past performance is any clue, there will be a lot of stumbling blocks for the guys in the field and low discoverability.

    You know, I noiticed that the ABD crew (Mary Chib, Paul Wagner etc) have been quite good at doing SIG meetings every month. Maybe GC should start a monthly SIG as well? There seems to be lots to show...?

Children
No Data