Reporting from Item Types in Cells

I have a cell library in which I have defined Item Types and attached them to an element in the cells so that when they are placed, they will have the Item Types already attached. My aim is to produce a report that contains all the Item Type values along with the X,Y,Z coordinates of the cell origin. My report runs on 'Cells + related items.' which are Item Types. I have added all the columns for cell coordinates & Item Types. When I run the report though my table only populates results related to cell property values & not Item Types. The Item Type values do not come through. In the course of testing I have found that my report will work if I place a cell without an Item Type already attached, and then attach the Item Type after it has been placed. This seem like an unnecessary step, & will not work for me anyway as I am also displaying the Item Types in text field built into the cells. So I can’t add them later. I suspect that I can get it to work if ‘Add related Item’ the correct way. However, when I look at doing this I find myself in an endless loop going through an Item Type into a cel into an Item Type into a cell and so on. The screen capture below hopefully demonstrates this. Hoping for some feedback on how to get this to work.

Parents
  • Hi Jovan,

    I know I am jmping into old discussion, but I was not in office for a few days ;-)

    My aim is to produce a report that contains all the Item Type values along with the X,Y,Z coordinates of the cell origin.

    Something similar to this report?

    When I run the report though my table only populates results related to cell property values & not Item Types.

    It is expected result, because the reported object are cells, whereas you attached Items somewhere inside cells, so they are hidden for the report engine.

    I suspect that I can get it to work if ‘Add related Item’ the correct way.

    I think not, because when you attach Item to an element, there is no simple (direct) relation between cell (represented by cell header) and Item, attached to an element inside cell.

    But I want all this to work with an Item Type already attached within a cell.

    You cannot solve your request with Item, attached to "some element" inside cell. In fact, you can, as demonstrated by Jon, using Expressions, but it has some consequences and limitations.

    & will not work for me anyway as I am also displaying the Item Types in text field built into the cells.

    This assumption is incorrect: To use Items in Text element does not require the data must exist (be attached) inside cell.

    Hoping for some feedback on how to get this to work.

    When you want to report cell properties and Item(s) properties, they must be "on the same level", because there is no way, how to specify relationship "from cell to specific element, with particular Item attached". To be precise, in EC representation such relation exists for sure, it is: cell header > one-to-many relationship to child elements > Item is attached particular child element. But it cannot be queried without code, analyzing to what element the specific Item data is attached.

    The solution is to attach Item not to element inside cell, but to the cell itself. It is similar to what you tried manually: To attach Item to cell header. In terms of a cell in cell library, it requires to attach Item to cell (model), not to an element. When such cell, with Item(s) attached to model, is placed, the definition is converted automatically from "attached to model" to "attached to cell header". It's mentioned also in MicroStation help too. When there is any text, using Item as Field, inside such cell, it works fine too: Filed definition is taken from model, and maintained properly after the cell definition is placed to DGN model.

    At the end, because Item data exist "at cell level", they can be included in report simply.

    With regards,

       Jan

Reply
  • Hi Jovan,

    I know I am jmping into old discussion, but I was not in office for a few days ;-)

    My aim is to produce a report that contains all the Item Type values along with the X,Y,Z coordinates of the cell origin.

    Something similar to this report?

    When I run the report though my table only populates results related to cell property values & not Item Types.

    It is expected result, because the reported object are cells, whereas you attached Items somewhere inside cells, so they are hidden for the report engine.

    I suspect that I can get it to work if ‘Add related Item’ the correct way.

    I think not, because when you attach Item to an element, there is no simple (direct) relation between cell (represented by cell header) and Item, attached to an element inside cell.

    But I want all this to work with an Item Type already attached within a cell.

    You cannot solve your request with Item, attached to "some element" inside cell. In fact, you can, as demonstrated by Jon, using Expressions, but it has some consequences and limitations.

    & will not work for me anyway as I am also displaying the Item Types in text field built into the cells.

    This assumption is incorrect: To use Items in Text element does not require the data must exist (be attached) inside cell.

    Hoping for some feedback on how to get this to work.

    When you want to report cell properties and Item(s) properties, they must be "on the same level", because there is no way, how to specify relationship "from cell to specific element, with particular Item attached". To be precise, in EC representation such relation exists for sure, it is: cell header > one-to-many relationship to child elements > Item is attached particular child element. But it cannot be queried without code, analyzing to what element the specific Item data is attached.

    The solution is to attach Item not to element inside cell, but to the cell itself. It is similar to what you tried manually: To attach Item to cell header. In terms of a cell in cell library, it requires to attach Item to cell (model), not to an element. When such cell, with Item(s) attached to model, is placed, the definition is converted automatically from "attached to model" to "attached to cell header". It's mentioned also in MicroStation help too. When there is any text, using Item as Field, inside such cell, it works fine too: Filed definition is taken from model, and maintained properly after the cell definition is placed to DGN model.

    At the end, because Item data exist "at cell level", they can be included in report simply.

    With regards,

       Jan

Children
  • Sounds like another item on Mangesh's to do list.

    If Bentley allows users to attach Item Types to elements, then it needs to also provide the means to access those Item Types when they are nested in a Cell. Not having this will play havoc with quantification and other reporting workflows.

  • Sounds like another item on Mangesh's to do list.

    Did you create Idea, so we can vote? ;-)

    If Bentley allows users to attach Item Types to elements, then it needs to also provide the means to access those Item Types when they are nested in a Cell.

    It would be nice to extend your idea with an explanation, how it should work (both logic and GUI). On general level, it's quite complex topic with many scenarios (there can be many elements with the same Items attached, nested cells etc.), so to highlight what approach covers "typical need" can help to start the discussion about implementation.

    Not having this will play havoc with quantification and other reporting workflows.

    I agree that such functionality would help. And unlike what I usually say (making Item Types functionality leads to too much complexity and performance drop down), in the case of Reports, I do not expect this threat exists.

    But, at the same time, it should be discussed that often item Types are used in a wrong way (because no best practices exist): When project data model is created (because in relation to BIM, Digital Twins etc. it's not about drawings and 3D models anymore), data quality is crucial, but there concepts have not been established in engineering yet (at least what I see in building and civil ;-). So when, like in the discussed case, data belongs to an object, represented by a cell, Item cannot be attached inside cell, but to the cell itself. But it's the topic for another discussion... ;-)

    Regards,

      Jan

  • Did you create Idea, so we can vote? ;-)

    Sure. I can add a new one... based on this discussion. I see that there a number of Ideas related to Cells and ITs.

    1. Persistance of ITs when a Cell is placed. MS-I-409
    2. Propagation poliy when an element is edited MS-I-381. I suppose that this would apply to the Cells that are dropped, mainly.
    3. Dynamic Report Tables. MS-I-268. Having a bi-directional link between the Item values attached to an element nested in a Cell in a Report that is placed as a table in a drawing is pretty useful. This would need the nested Items to be extracted by the Report tool.
    4. ??

    How would this look like to the user?

    I think that this the easy part: as mentioned previously, the Reports generated shoud contain the Items that are attached to the nested elements. I think that there should be a means to indicate the nesting in the Report, grid, table. The Report tool needs to be able to group rows like Excel to show that some of the Items are nested. Excel has the level buttons to allow the user to expand to all levels etc. Too complicated? Probably. Why not start with a 'nest depth' column that the user can use to sort or filter?

    One:many, many:one, many:many relationships are going to the norm, especially over time. The user usually will be looking for something specific. The Report Definition tool already has some nice query-based filtering tools. Hopefully, this is all straight forward at API level and programmers don't have to get too low-level to navigate the Items 'data model' for the own purposes... like rules-based checks or error trapping. The API should have some pseudo-recursive algos to extract all the nested Items in the Cells.

    What should not happen is that only the top level Items data is available... and the user is 'advised' to not to attach Items to the Cell components. Your problem, Mr user... we devs can't be asked, it's them other b*ggers who still haven't fixed my TR or the dumb PM didn't include this in the outsourcing spec so now they are holding us to ransom :-)

    Drawings v Models: It's problems like this that make drawings still legal tender, mate! When the cost guys extract their info from a model they won't be able to pick up if some quants or objects are missing because they are nested. Most firms (and lawyers) still prefer drawings and paper because the 'data' is more visible and checkable. All this digital voodoo is a black box that will always need manual checks. Can't sue a guy who had no reasonable or reliable way of 'seeing' what his contractual obligations are.

    Not sure why you think using Cells only will help. Its all about dealing with scalability at the end of the day. A lot of BIM is based on replacing loose elements like lines into smart objects like doors, walls etc; but these objects in turn have to grouped into assemblies, containers etc. Same applies in the MCAD world. You don't hear about them insisting on everything flattened for performance reasons etc. There should be no differentiating between a Line and a Cell. The 'funny' outcome would be Mr User just making all his Lines into Cells and you are back where you started.

    I think that the question is about at what level do we need to 'flatten' the data model, on demand? What happens when the dgn is exported as an i.dgn or imodel? I suspect you would be able to report the nested info OOTB? If so, maybe there should be a temp imodel lite generated when the Report tool is used? And Bentley shoud spill the beans and publish the relevant API calls.

  • Not sure why you think using Cells only will help

    I never wrote anything like this

    Honestly, I do not want to steal this thread with what-if and nice-to-have philosophy discussion. When you want to add anything to MicroStation, creates individual Idea for every missing feature or tool, and motivate other users to vote for the Idea.

    Regards,

      Jan

  • ??

    So when, like in the discussed case, data belongs to an object, represented by a cell, Item cannot be attached inside cell, but to the cell itself.

    Maybe I misunderstood the 'cannot be attached inside cell, but to the cell itself' here? Sounds like you are suggesting that Items should only be attached to the Cell only.

    But it's the topic for another discussion... ;-)

    Agreed.